RFC 5522

Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks

📅 published October 2009, from ietf

RFC 5522, Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks 🛫🚀

Okay bestie, this one's written by W. Eddy (Verizon), W. Ivancic (NASA), and T. Davis (Boeing) 🫶 It's Informational (so it's not a standard, just really good info for the community) and it came out in October 2009. The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Abstract ✨

Okay so this doc lays out the requirements and the properties we want from Network Mobility (NEMO) Route Optimization techniques 🛰️ It's for global networked communication systems in aeronautics and space exploration, so planes and spacecraft, basically. 💅

It also got a ton of input from aeronautical communications experts outside the IETF, including folks from the International Civil Aviation Organization (ICAO) and other aeronautical communications standards bodies. Very collab, very iconic 🎀

Status of This Memo

Real talk, this memo is just for info. It is not an Internet standard of any kind 🙈 Distribution is unlimited, so share it with your whole group chat 💜

Copyright Notice

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info, as they were on the publication date. Read those carefully, bestie, because they explain your rights and restrictions. If you pull Code Components out of this doc, they have to include the Simplified BSD License text (see Section 4.e of the Trust Legal Provisions), and they come with no warranty, per the BSD License ⚖️✨

1. Introduction ....................................................2
2. NEMO RO Scenarios ...............................................5
   2.1. Aeronautical Communications Scenarios ......................5
        2.1.1. Air Traffic Services Domain .........................6
        2.1.2. Airline Operational Services Domain .................8
        2.1.3. Passenger Services Domain ...........................9
   2.2. Space Exploration Scenarios ...............................10
3. Required Characteristics .......................................12
   3.1. Req1 - Separability .......................................13
   3.2. Req2 - Multihoming ........................................14
   3.3. Req3 - Latency ............................................15
   3.4. Req4 - Availability .......................................16
   3.5. Req5 - Packet Loss ........................................17
   3.6. Req6 - Scalability ........................................18
   3.7. Req7 - Efficient Signaling ................................19
   3.8. Req8 - Security ...........................................20
   3.9. Req9 - Adaptability .......................................22
4. Desirable Characteristics ......................................22
   4.1. Des1 - Configuration ......................................22
   4.2. Des2 - Nesting ............................................23
   4.3. Des3 - System Impact ......................................23
   4.4. Des4 - VMN Support ........................................23
   4.5. Des5 - Generality .........................................24
5. Security Considerations ........................................24
6. Acknowledgments ................................................24
7. References .....................................................25
   7.1. Normative References ......................................25
   7.2. Informative References ....................................25
Appendix A.  Basics of IP-Based Aeronautical Networking  ........28
Appendix B.  Basics of IP-based Space Networking ................30

1. Introduction 🌈

First things first, the NEMO terminology doc and the NEMO goals and requirements doc are suggested reading for this one ([4], [5]) 📚

Now the base NEMO standard [1] takes Mobile IPv6 [2], which was built for single mobile hosts, and extends it so Mobile Routers (MRs) can carry whole mobile networks around 🚐 NEMO lets those networks stay reachable through fixed IP address prefixes no matter where they end up in the topology. How? A bidirectional tunnel gets maintained between a NEMO MR and a NEMO-supporting Home Agent (HA) that sits somewhere relatively stable in the network 🏠

Here's the catch: NEMO doesn't give Mobile IPv6's Route Optimization (RO) features to Mobile Network Nodes (MNNs) except for the NEMO MR itself 😤 So Corresponding Nodes (CNs) talking to MNNs behind an MR have to go through the HA and the bidirectional Mobile Router - Home Agent (MRHA) tunnel. That tunnel can have some serious drawbacks [6], so RO techniques that let CN and MR use a more direct path are highly desirable 💅✨

Next, mobile networks of some kind have been used for ages to talk to people and avionics equipment on aircraft and spacecraft ✈️🛸 Those systems usually weren't running IP, but both the aeronautics and space exploration crowds are now designing and deploying IP-based architectures (see Appendix A and Appendix B for the details) 🫶 A craft usually has tons of computing nodes, sensors, and other devices that you can address one by one with IPv6, which is super useful for network-centric operations concepts 🧚 But a craft only has a small number of access links, so it makes total sense to use NEMO MRs to handle the work of keeping that big onboard network reachable over those few dynamic access links 🌸

On an aircraft in particular, the nodes sit in multiple independent networks based on what they do. Regulations require these networks to get different treatment for their air-ground traffic, and they often have to use separate air-ground links and service providers. Major main-character stuff 👑

For aeronautics, the big problem with NEMO bidirectional tunnels is that airlines fly routes across multiple continents, and one plane can circle the whole planet in a couple of days 🌍💀 If that plane uses a static HA on one continent, then for a huge chunk of the time, when it's not on the same continent as the HA, the MRHA tunnel adds a ton of delay. Avoiding that delay from pushing packets across multiple continents for no reason is the main goal of chasing NEMO RO for aeronautics 🎯

Other stuff about aeronautics and space makes the known MRHA tunnel issues [6] even worse 😭

Longer routes leading to increased delay and additional infrastructure load: In aeronautical networks (for example, "Plain Old" Aircraft Communication Addressing and Reporting System (ACARS) or ACARS over VHF Data Link (VDL) mode 2), queueing delays are often long because of Automatic Repeat Request (ARQ) mechanisms and underprovisioned radio links. Also, for space exploration and for aeronautical communications systems that go through geosynchronous satellites, propagation delays are long too. These delays, plus the extra need to cross continents to carry packets between ground stations and CNs, mean delays are already pretty high in aeronautical and space networks before you even add an MRHA tunnel. The extra delay from MRHA tunnels may be unacceptable when it comes to meeting Required Communication Performance [7] 🥺

Increased packet overhead: Link bandwidth is constrained, even in future communication systems for aeronautics and space exploration, so planners really hate header overhead 🙅‍♀️ Any spare link capacity can go toward extra situational awareness, science data, and so on, so every byte of header or tunnel overhead takes away a byte of useful data 💔
Increased chances of packet fragmentation: RFC 4888 [6] names fragmentation caused by encapsulation as an artifact of tunneling. Links in aeronautics and space are error-prone and might lose fragments on the initial or final hop(s), but fragmentation considerations along the whole tunneled path are the same as on the terrestrial side 🧩
Increased susceptibility to failure: Using MRHA tunnels for command and control applications that need high availability for safety-of-life or safety-of-mission is risky 😬 A single link failure could take down all communications, and so could an HA failure, which makes these tunnels a real problem.

So yeah, an RO extension to NEMO is highly desirable for aeronautical and space networking 🔥 In fact, some planners may not seriously consider moving NEMO from experimental demos into operational use until there's a standard RO mechanism. Without an RO solution, it's hard to justify NEMO for realistic operational use at all 😤✨

In Section 2 we cover the main features of the access and onboard networks envisioned for aeronautics and space exploration, because they shape which NEMO RO solutions can actually work 🗺️ Section 3 lists the technical and functional characteristics that a NEMO RO solution absolutely needs for these environments. Section 4 lists extra characteristics that are desired but not necessarily required 🎀 Appendix A and Appendix B are brief primers on the specific operational concepts used in aeronautics and space exploration, for IP-based network architectures 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3] 🔑 This doc doesn't specify an actual protocol, just the requirements for one, but it still uses RFC 2119 language so the requirements are crystal clear 💖

2. NEMO RO Scenarios 🛰️

To motivate and drive the requirements and desirable features for NEMO RO solutions, this section walks through some operational characteristics. It shows how access networks, HAs, and CNs are set up and spread out, both geographically and topologically, in aeronautical and space network architectures 🌏 This helps figure out which classes of RO techniques from the known solution space [8] are feasible 🦋

2.1. Aeronautical Communications Scenarios ✈️

okay so aircraft can be connected to several ground access networks at once, using different technologies with different coverage, so it's really hard to make big general claims about how often active access links and care-of addresses (CoAs) change 🫠. as one data point, for VDL mode 2 data links, how long a plane stays on one access channel depends on what stage of flight it's in. on the airport surface, VDL mode 2 access stays stable while the plane is unloaded, loaded, refueled, etc., but other wired and wireless LAN links (like local networks available at a gate) can come and go 📶. right after takeoff and before landing, planes are in the terminal maneuvering area for about 10 minutes and stably use another VDL mode 2 channel 🛫. during en route flight, handovers between VDL mode 2 channels may happen every 30 to 60 minutes, depending on the exact flight plan and the layout of towers, cells, and sectors that a service provider uses 🗼. these handovers can give you a different access router and a change in CoA, though local mobility management (e.g., [9]) may limit CoA changes to only handovers between different providers or types of data links 🎀

the characteristics of a data flow between a CN and an MNN vary depending on the data flow's domain and on the particular application within that domain 💅. even inside the three aeronautical domains described below, there are different classes of service that get regulated differently (e.g., for emergencies versus nominal operations), but this level of detail has been abstracted out for the purposes of this document 🙈. it is assumed that any viable NEMO RO solution will be able to support a granularity of configuration with many sub-classes of traffic within each of the specific domains listed here 🔥

2.1.1. Air Traffic Services Domain

the MNNs involved in Air Traffic Services (ATS) are pieces of avionics hardware on board an aircraft that are used for navigation, control, and situational awareness ✨. the applications these MNNs run are mostly critical to the safety of the passengers and crew, so no pressure 😭. the MNN equipment can range from typical laptop computers to very specialized avionics devices 💻. these MNNs will mostly be Local Fixed Nodes (LFNs), with a few Local Mobile Nodes (LMNs) to support Electronic Flight Bags, for instance 🧚. it can be assumed that Visiting Mobile Nodes (VMNs) are never used within the ATS domain 🚫

an MR used for ATS will be capable of using multiple data links (at least VHF-based, satellite, HF-based, and wired), and will likely be backed up by a backup unit in case of failure 🛟. that makes it a multihomed MR that is at least multi-interfaced and possibly multi-prefixed as well, in NEMO terminology 👑

the existing ATS link technologies may be too anemic for a complete IP-based ATS communications architecture (link technologies and acronyms are briefly defined in Appendix A) 🥲. at the time of this writing, the ICAO is pursuing future data link standards that support higher data rates 🚀. part of the problem is limited spectrum, which is being pursued under ICAO ACP-WG-F, "Spectrum Management", and part of the problem is the data link protocols themselves, which are being pursued under ICAO ACP-WG-T, "Future Communications Technology" 📡. ACP-WG-T has received inputs from studies on a number of potential data link protocols, including B-AMC, AMACS, P34, LDL, WCDMA, and others 🧠. different link technologies may be used at different stages of flight, for instance 802.16 on the surface and in the terminal area, P34 or LDL en route, and satcom in oceanic flight 🌊. both current and planned data links used for Passenger Information and Entertainment Services (PIES) and/or Airline Operational Services (AOS), such as the satcom links used by passenger Internet-access systems, support much higher data rates than current ATS links 🍓

since, for ATS, the MRs and MNNs are under regulatory control and are actively tested and maintained, it is not completely unreasonable to assume that special patches or software could be run on these devices to enable NEMO RO 🛠️. since these devices are accessed by skilled technicians and professionals, some special configuration may be required for NEMO RO 🧑‍✈️. simplicity in setup and configuration is still highly preferable, though 🥰, and the desirable feature labeled "Des1" later in this document prefers solutions with lower configuration state and overhead 💜. to minimize costs of ownership and operations, it is also highly desirable for only widely available, off-the-shelf operating systems or network stacks to be required, but this is not a full requirement 💖

data flows from the ATS domain can be assumed to consist mainly of short transactional exchanges, such as clearance requests and grants 📝. future ATS communications are likely to include longer messages and higher message frequencies for positional awareness and trajectory intent of all vehicles in motion at the airport and all aircraft within a thirty-mile range during flight ✈️💫. many of these may be aircraft-to-aircraft, but the majority of current exchanges are between the MNNs and a very small set of CNs within a control facility, and they happen at any time due to the full transfer of control as a plane moves across sectors of airspace 🗂️. the set of CNs can be assumed to be topologically close to one another 🤝. these CNs are also involved in other data flows over the same access network that the MR is attached to, managing other flights within the sector 🌐. these CNs are often geographically and topologically much closer to the MR than a single fixed HA is 🏠

the MNNs and CNs used for ATS will support IP services, since IP is the basis of the new Aeronautical Telecommunications Network (ATN) architecture being defined by ICAO 🌈. some current ATS ground systems run typical operating systems, like Solaris, Linux, and Windows, on typical workstation computer hardware 🖥️. there is some possibility that an RO solution could require minor changes to these CNs, though it is much more desirable if completely off-the-shelf CN machines and operating systems can be used 🙏. later in this document, the security requirements suggest that RO might be performed with mobility anchors that are topologically close to the CNs, rather than directly with the CNs themselves 🛡️. this could possibly mean that CN modifications are not required 🎉

during the course of a flight, there are several events for which an RO solution should consider the performance implications 👀:

Initial session creation with an ATS CN (called "Data Link Logon" in the aeronautical jargon) 🔑
Transfer of control between ATS CNs, resulting in regional differences in where the controlling CN is located 🗺️
Aircraft-initiated contact with a non-controlling ATS CN, which may be located anywhere, without relation to the controlling CN 📞
Non-controlling, ATS, CN-initiated contact with the aircraft 📲
Aircraft transition between one access link to another, resulting in change of CoA 🔄
Concurrent use of multiple access links with different care-of addresses 🫶

2.1.2. Airline Operational Services Domain

data flows for Airline Operational Services (AOS) are not critical to the safety of passengers or the aircraft 🙌, but they are needed for the business operations of airlines running flights, and they may affect the profitability of an airline's flights 💸. most of these data flows are sourced by MNNs that are part of the flight management system or sensor nodes on an aircraft, and they terminate at CNs located near an airline's headquarters or operations center 🏢. AOS traffic may include detailed electronic passenger manifests, passenger ticketing and rebooking traffic, and complete electronic baggage manifests 🧳. when suitable bandwidth is available (currently on the surface when connected to a wired link at a gate), "airplane health information" data transfers of between 10 and several hundred megabytes of data are likely 🔧. in the future, it is expected that In-Flight Entertainment (IFE) systems may receive movie refreshes of data (e.g., television programming or recent news updates) running into the multi-gigabyte range 🍿

currently, these flows are often short messages that record the timing of events of a flight, engine performance data, and so on, but they may be longer flows that upload weather or other supplementary data to an aircraft 🌦️. in addition, email-like interactive messaging may be used at any time during a flight 💌. for instance, messages can be exchanged before landing to arrange arrival-gate services for handicapped passengers, refueling, food and beverage stocking, and other needs 🛬. this messaging is not limited to landing preparation, though, and it may occur at any stage of flight 🥳

the equipment comprising these MNNs and CNs has similar considerations to the equipment used for the ATS domain 🔍. a key difference between ATS and AOS is that AOS data flows are routed to CNs that may be much more geographically remote from the aircraft than the CNs used by ATS flows, since AOS CNs will probably be located at an airline's corporate data center or headquarters 🌍. the AOS CNs will also probably be static for the lifetime of the flight, rather than dynamic like the ATS CNs 📌. an HA used for AOS may be fairly close topologically to the CNs, and RO may not be as big of a benefit for AOS, since simple event logging is more typical than time-critical interactive messaging 😌. for the small number of messaging flows, however, the CNs are geographically (but not necessarily topologically) very close to the aircraft 📬, though this depends on how applications are written, namely whether they use centralized servers or exchange messages directly 🤓. additionally, since AOS communication is more advisory in nature than ATS, rather than safety-critical, AOS flows are less sensitive to tunnel inefficiencies than ATS flows 🫧. for these reasons, in this document, AOS data flow concerns with RO mechanisms are not considered full requirements; instead, they are considered desirable properties, which are discussed in Section 4 💅✨

future AOS MNNs and CNs can be expected to implement IPv6 and conform to the new IPv6-based ATN Standards and Recommended Practices (SARPS) that ICAO is defining 🌟. AOS CNs have similar hardware and software properties to those described for ATS above 💖

2.1.3. Passenger Services Domain ✈️🎬

okay so the MNNs in the Passenger Information and Entertainment Services (PIES) domain are mostly NOT under the control of any single authority 💅 most of them are VMNs and personal stuff passengers bring on board for the flight, so it's totally unreasonable to assume they've been preloaded with special software or operating systems 🙈 these MNNs run regular internet apps like web browsing, email, and file transfer, often through VPN tunnels 🫶 they're portable electronics like laptops and smartphones that can connect to an onboard wireless access network (e.g., using 802.11) ✨ and honestly? to the devices and the users, connecting to the plane's network is the exact same as joining any other terrestrial "hotspot" or typical wireless LAN 📶 the MNNs are completely oblivious that the network is on an airplane and maybe zooming around the globe 🌍 and the users aren't always super technical, so they may not be able to do any special configuration on their MNNs or apps at all 😭

the biggest group of PIES CNs is typical web servers and other nodes on the public Internet 🌸 it's not reasonable to assume these can be modified specifically to support a NEMO RO scheme 💀 right now these CNs are mostly IPv4-based, but more and more IPv6 PIES CNs are expected in the future 🌈 this document doesn't dig into the IPv4-IPv6 transition problem, beyond assuming that either the MNNs and CNs are running IPv6 or some transition mechanism exists somewhere in the network 🦋

a small number of PIES MNNs might be LFNs that store and distribute cached media (like movies and music) or provide gaming services to passengers 🎮 the data on these LFNs is HUGE compared to the anemic bandwidth available air-to-ground, so these LFNs will probably not try to communicate off-board at all during a flight 🙅‍♀️ instead they'll wait to update their content over high-speed links on the ground or through removable media inserted by the flight crew 🧚 if a higher bandwidth link were affordably available, it might get used in-flight for these purposes, but supporting that is not a requirement 💜 the data flows needed for billing passengers for content access are relatively low bandwidth and are currently done in-flight 💅 their requirements are less strict than ATS, though, so they aren't specifically considered here 🫶

the PIES domain is not critical to safety-of-life 🌷 it's just an added comfort or business service for passengers ✨ since PIES apps can eat up way more bandwidth than the links used in other domains, the PIES MNNs may have their packets routed through a separate high-bandwidth link that the ATS data flows don't use 🛜 for instance, several service providers are planning to offer passenger Internet access during flight at DSL-like rates, just like the former Connexion by Boeing system did 🎀 several airlines also plan to offer onboard cellular service to passengers, possibly using Voice-over-IP for transport 📞 because PIES isn't critical and will probably be treated independently, this document does NOT consider PIES MNN concerns as input to the requirements in Section 3 🙃 the RO solution should be optimized for ATS and AOS needs and treat PIES as a secondary concern 🥹

with all that in mind, the PIES domain is also the most likely to use NEMO for communications in the near term 🚀 there's relatively little regulation and bureaucracy involved in deploying new tech here, and IP-based PIES systems have already been developed and deployed (just not using NEMO) [10] 💖 so PIES concerns factor heavily into the desirable properties in Section 4, outside of the mandatory requirements 🔥

some PIES nodes are currently using 2.5G/3G links for mobile data services, and these may be able to migrate to an IP-based onboard mobile network once it's available 📱✨

2.2. Space Exploration Scenarios 🚀🌌

this section describes some features of the network environments in space exploration that matter when picking an appropriate NEMO RO mechanism 🛰️ it's worth noting that IPv4-based mobile routing has been demonstrated on board the UK-DMC satellite, and the documentation on that is a useful reference for understanding some of the goals and configuration issues for certain types of space use of NEMO [11] 🇬🇧✨ this section assumes space use of NEMO within the "near-Earth" range of space (i.e., NOT for communications between Earth and Mars or other "deep space" locations) 🌙 also, NEMO is currently being considered for use out to lunar distances 🌕 no strong distinction is made between civilian and military use, or between exploration missions and Earth-observing or other mission types 👀 our focus is on civilian exploration missions, but we think a lot of the same basic concerns apply to those other mission types too 💜

in space communications there's often a HUGE bandwidth asymmetry 😳 the uplink from the ground to a craft is typically multiple orders of magnitude slower than the downlink from the craft to the ground 📉 which means the RO overhead might be negligible on the downlink but significant on the uplink 🙊 an RO scheme that minimizes signaling from CNs to an MN is desirable, since these uplinks may be low-bandwidth to begin with (possibly only several kilobits per second) 🐢 and since the uplink is used for sending commands, it should not be blocked for long periods while serializing long RO signaling packets 🚫 any RO signaling from the CN to MNNs must not involve large packets 📦

for unmanned space flight, the MNNs on board a spacecraft are almost entirely LFN-sensing devices and processing devices that send telemetry and science data to CNs on the ground, plus actuator devices that get commanded from the ground to control the craft 🤖 robotic lunar rovers may act as VMNs behind an MR located on a lander or orbiter, but these rovers contain many independent instruments and could probably be configured as an MR and LFNs instead of using a single VMN address 🧑‍🚀🌟

it can be assumed that for manned spaceflight, at least multiple MRs will be present and online simultaneously for fast failover 🫠 these will usually be multihomed over space links in diverse frequency bands, so multiple access network prefixes can be expected to be in use at the same time 🌈 this is especially true since some links go direct to ground stations while others may be bent-pipe repeated through satellite relays like the Tracking and Data Relay Satellite System (TDRSS) 🛰️✨ this conforms to the (n,1,1) or (n,n,1) NEMO multihoming scenarios [12] 💅 for unmanned missions, if low weight and power are more critical, it's likely that only a single MR and single link/prefix will be present, conforming to the (1,1,1) or (1,n,1) NEMO multihoming scenarios [12] 🪐

in some modes of spacecraft operation, ALL communications may go through a single onboard computer (or a Command and Data Handling system, like on the International Space Station) instead of going directly to the MNNs themselves 🖥️ so there's only ever one MNN behind an MR that's in direct contact with off-board CNs 👑 in this case, removing the MR and using simple host-based Mobile IPv6 rather than NEMO is possible 🧚‍♀️ however, an MR is more desirable because it could be part of a modular communications adapter used across multiple diverse missions to bridge onboard buses and intelligently manage space links 🔧 that's cheaper and leads to faster development time than re-creating these capabilities per-mission with simple Mobile IPv6 and a single Command and Data Handling node that varies widely between spacecraft 💸 also, all visions for the future involve network-centric operations, where the direct addressability and accessibility of end devices and data is crucial 🌐 as network-centric operations become more common, applying NEMO is likely to be needed to increase the flexibility of data flow 🦋

the MRs and MNNs on a spacecraft are highly customized computing platforms, and adding custom code or complex configurations to get NEMO RO capabilities is feasible 🛠️ although, it should not be assumed that any amount of code or configuration maintenance is possible after launch 😬 the RO scheme as initially configured should keep working throughout the lifetime of an asset 💖🔒

for manned space flight, there may also be additional MNNs on spacesuits and on astronauts, used for things like two-way voice conversation or video downlink 🎙️👩‍🚀 these MNNs could be reusable and reconfigured per flight for different craft or mission network designs, but it's still desirable for them to autoconfigure themselves 🙌 and they may move between nested or non-nested MRs during a mission 🌀 for instance, if astronauts move between two docked spacecraft, each craft may have its own local MR and wireless coverage that the suit MNNs will have to reconfigure for 🚪✨ it's desirable if an RO solution can respond appropriately to this change in locality and not cause high levels of packet loss during the transitional period 😤💜 it's also likely that these MNNs will be part of Personal Area Networks (PANs), so they may appear either directly as MNNs behind the main MR on board, or have their own MR within the PAN and thus create a nested (or even multi-level nested) NEMO configuration 🪆🌟

3. Required Characteristics ✨

okay bestie, this section is the shopping list 🛍️ it lists the absolute minimum technical and functional properties a NEMO RO mechanism needs to have before it's usable for aeronautical and space communications 💅

The International Civil Aviation Organization (ICAO) did a bunch of work figuring out which mobility technologies could give IP services to aircraft, and they came up with a set of technical criteria ([13], [14]) 🧚 The nine required characteristics in this document are basically descended from those ICAO criteria, but here they've been made way more specific and focused on NEMO and the RO problem within NEMO 💖

The original ICAO criteria were more general. They were for comparing different mobility solutions (routing protocols vs. transport protocols vs. Mobile IP, and so on) 🦋 Each requirement below says which high-level ICAO criterion it grew out of 🫶

Aeronautics requirements are basically the same as, or stricter than, the ones for space exploration, so no extra space-only requirements got added 🚀 Also, space exploration doesn't have a standards body regulating performance and safety, so the aviation requirements are much easier to agree on and fit into existing frameworks 🌈 The authors think the aviation set fully covers space exploration too ⭐

Different domains might need different solutions 🎀 That could mean different NEMO RO solutions, or totally different mobility solutions. Divergent solutions across domains are acceptable, but preferably avoided if possible 🙈

Here's an underlying requirement, and it's a big one 👑 If you use Mobile IP for mobility management (instead of a higher-layer approach), the IP addresses used inside the mobile network, and the addresses CNs use to start new sessions with nodes inside it, must stay constant for the whole flight and all operations 🔥 For ATS and AOS, that lets the Home Addresses (HoAs) act as node identifiers, not just locators 💜 For PIES, it means persistent apps (like Voice over IP (VoIP) clients and VPN clients) can stay connected the whole flight 🦋 Earlier aeronautical systems, like the OSI-based ATN and Connexion by Boeing, already set the precedent of keeping a fixed Mobile Network Prefix (MNP) 🌸 They did it with interdomain routing protocols (IDRP and BGP) though, not NEMO 🙃 This requirement covers choosing a mobility management technology in general, not just an RO solution once NEMO is picked 💅

3.1. Req1 - Separability 🎀

Since RO might be inappropriate for some flows, an RO scheme MUST support configuration by a per-domain, dynamic RO policy database. Entries in this database can be similar to those in IPsec security policy databases, so they can specify either bypassing or using RO for specific flows 💖

3.1.1. Rationale for Aeronautics - Separability 🦋

Even when RO is available to boost a mobile network's traffic, it might not be right for every flow ✨

Sometimes you want certain flows to go through the MRHA path instead of doing RO, so a central service can record them easily 📼

So an RO scheme has to let applications bypass it when they want bidirectional tunnels through an HA 🫶 That desire could be expressed through a policy database similar to IPsec's security policy database, but how applications signal or configure that desire is left to the specific RO specifications 🌈

Also, the use of NEMO technology is expected to be decided per domain. So for some domains, separate MRs or even non-NEMO mobility techniques might be used 🧚 This RO policy database requirement only applies to domains that use NEMO 💅

This requirement comes from ICAO's TC-1 [15]: "The approach should provide a means to define data communications that can be carried only over authorized paths for the traffic type and category specified by the user." 🔐

One suggested approach to traffic separation is multi-addressing of the onboard networks, where a traffic domain is determined by the packet addresses used 🏷️ But there are other ways to meet this, so multi-addressing isn't a requirement itself 🙅‍♀️ Req1 is meant for separating traffic within a NEMO domain based on flow properties, like short messaging flows vs. longer file transfers or voice flows 🌸

3.2. Req2 - Multihoming 🌐

An RO solution MUST support an MR having multiple interfaces and MUST allow a given domain to be bound to a specific interface. It MUST be possible to use different MNPs for different domains.

3.2.1. Rationale for Aeronautics - Multihoming 🛰️

Multiple factors push for multihoming 💜 ATS safety-of-life critical traffic needs high availability, which suggests a basic multihoming requirement 🚨 Regulations and operations make it hard to deploy new systems and move off old ones, so a mix of access technologies may be in use at any time, and they may need to be used at the same time 🔁 Also, the multiple application domains on board may be restricted in which data links they're allowed to use, based on regulations and policy 📜 So at certain times or places, PIES data flows may have to use different access links than ATS data flows 🛫

That means an RO solution MUST allow an MR to be connected to multiple access networks at once and have multiple CoAs in use at once 👑 Choosing the right CoA and access link per packet might be inside or outside the RO solution's scope 🤷‍♀️ At a minimum, if an RO solution can be integrated with the MONAMI6 basic extensions (registering multiple CoAs and flow bindings) and doesn't rule them out, this requirement counts as satisfied 🎉

To be clear, this requirement doesn't mean the RO scheme itself has to provide multihoming 🙅‍♀️ It just excludes RO techniques that can't work in multihomed scenarios 🧹

For NEMO multihoming scenarios [12], an RO solution MUST be able to support at least the (n,1,n) and (n,n,n) scenarios 💅

This requirement comes from ICAO's TC-2: "The approach should enable an aircraft to both roam between and to be simultaneously connected to multiple independent air-ground networks." ✈️

3.3. Req3 - Latency ⏱️

While an RO solution is setting up or reconfiguring itself, packets of specified flows MUST be able to use the MRHA tunnel 💨

3.3.1. Rationale for Aeronautics - Latency ⚡

An RO scheme might take longer to set up, or involve more signaling, than the basic NEMO MRHA tunnel maintenance that happens when the MR's active CoAs change because the set of usable access links changed 🐢 During this flux, it can matter a lot that apps can get packets onto the ground network right away 🙏 That's especially true because connectivity may have been blocked for a while while link-layer and NEMO procedures handled the transition 😭 Also, when an application starts for the first time, the RO scheme may not know anything about the CN yet and may need some setup before an optimized path is ready 🧩 If the RO scheme blocks packets, either by queueing or dropping them while it configures itself, the delays could be unacceptable 😬

So when the MR's set of active access links changes, the RO scheme MUST NOT block packets from using the MRHA tunnel if the RO scheme needs more time to set up or configure itself than the basic NEMO tunnel maintenance takes 🚫🛑 And when an application flow starts, the RO scheme MUST let packets go out immediately, maybe without the full benefit of RO, if the RO scheme needs extra time to configure a more optimal path to the CN ⏩

This requirement comes from ICAO's TC-3: "The approach should minimize latency during establishment of initial paths to an aircraft, during handoff, and during transfer of individual data packets." 🛬

3.4. Req4 - Availability 🛡️

An RO solution MUST be compatible with network redundancy mechanisms, and MUST NOT prevent fallback to the MRHA tunnel if an element in an optimized path fails.

An RO mechanism MUST NOT add any new single point of failure for communications in general.

3.4.1. Rationale for Aeronautics - Availability 🔐

High availability of connectivity to ground networks is needed because IP networking is carrying safety-of-life critical traffic 🚑 So single points of failure have to be avoided 💔 If an RO solution assumes a single onboard MR, a single HA, or some similar vulnerable point, and doesn't work when the network uses standard router reliability mechanisms, then that RO technique won't be acceptable 🙅‍♀️ An RO solution also MUST NOT itself imply a single point of failure 🌟

This requirement makes sure the RO solution doesn't add any big new fragility 🧱 In basic Mobile IPv6 and NEMO deployments, a single HA means a single point of failure, but there are ways to make HAs redundant (for example, [16]) 🔁 It's assumed that some HA-redundancy techniques would be used to make things sturdier in an aeronautical setting 💪 RO also decreases dependence on HAs in the infrastructure, and it gives some robustness to HA failures: established sessions using RO may keep working based on Binding Cache entries even after an HA fails 🦋 With RO, an HA failure mainly hurts the ability to connect new application flows to a mobile network 😤

If a failure happens in a path that an RO technique selected, that RO technique MUST NOT prevent fallback to the MRHA path for the affected traffic 🔙

This requirement doesn't name specific redundancy mechanisms for MRs, HAs, or other networking elements. So as long as some reasonable way to make each component redundant fits within the RO mechanism's assumptions, this requirement counts as satisfied 🎀

Please note, this requirement is NOT about supporting "Internet-less" operation 🙅‍♀️ When an MR is totally cut off from most of the network it's meant to talk to, including its HA, there's no requirement that it keep communications with parties outside the mobile networks it manages itself 🌙

This requirement comes from ICAO's TC-4: "The approach should have high availability which includes not having a single point of failure." 💖

3.5. Req5 - Packet Loss 💅

okay bestie, Req5 is all about not dropping or duplicating packets 🫶 An RO scheme SHOULD NOT cause either loss or duplication of data packets during RO path establishment, usage, or transition, beyond whatever NEMO basic support already causes. An RO scheme MUST NOT itself create non-transient losses and duplications within a packet stream.

3.5.1. Rationale for Aeronautics - Packet Loss ✨

some RO schemes could cause packets to get lost during transitions in RO state, or because of unforeseen packet filters on the RO-selected path 😬 That's hard for an app to notice and respond to in time, ngl. So an RO scheme SHOULD NOT cause packets to be dropped at any point in operation when they would not normally have been dropped in a non-RO configuration.

some techniques might duplicate packets over both the MRHA tunnel and the optimized path for a while, as an attempt to fight packet loss. If that results in duplicate packets being delivered to the application, that's also unacceptable 🙈

this requirement doesn't necessarily imply make-before-break when switching between links. The point is that during the handoff period, the RO scheme itself shouldn't produce losses (or duplicates) that wouldn't have happened if RO had been disabled 🦋

this requirement came from ICAO's TC-5 - "The approach should not negatively impact end-to-end data integrity, for example, by introducing packet loss during path establishment, handoff, or data transfer."

it's understood that this may be a requirement that's not easily implementable with regards to RO. Also, Req1, Separability, might be enough to let loss-sensitive and duplicate-sensitive flows take the MRHA path 🌸

3.6. Req6 - Scalability 🌈

An RO scheme MUST be simultaneously usable by the MNNs on hundreds of thousands of craft without overloading the ground network or routing system. This explicitly forbids injection of BGP routes into the global Internet for purposes of RO.

3.6.1. Rationale for Aeronautics - Scalability 🛫

okay so there could be several thousand aircraft in operation at a time, each with perhaps several hundred MNNs onboard 😭 The number of active spacecraft using IP will be multiple orders of magnitude smaller than that over at least the next decade, so the aeronautical needs are way more stringent for scaling to large numbers of MRs. It would be a total non-starter if all the MRs using an RO technique together overloaded ground networks provisioned like typical long-haul private telecom networks (like the FAA's Telecommunications Infrastructure (FTI) or the NASA Integrated Services Network (NISN)). Melting down under the RO signaling load or the amount of rapid path changes for multiple data flows is not it 💀

thus, an RO scheme MUST be simultaneously usable by the MNNs on hundreds of thousands of craft without overloading the ground network or routing system. The scheme must also be tolerant to the delay and/or loss of initial packets, which may become more pervasive in future Internet routing and addressing architectures [17].

since at least one traffic domain (PIES) needs connectivity to the Internet, and the Internet might transport other domains at some distant point in the future, this requirement explicitly forbids techniques known to scale poorly in their global effects, like BGP, for the purposes of RO 👑 The previous OSI-based ATN used IDRP and an "island" concept to maintain connectivity to the mobile network, but it wasn't tested on a large scale deployment. The Connexion by Boeing system used BGP announces and withdrawals as a plane moved across the globe to maintain connectivity [10]. That caused a significant amount of churn in the global Internet routing tables, which is undesirable for a number of reasons and must be avoided in the future 🙅‍♀️

this requirement came from ICAO's TC-6 - "The approach should be scalable to accommodate anticipated levels of aircraft equipage."

the scaling factor for the number of aircraft in our version of the requirement is an order of magnitude larger than the estimated equipage cited in an ICAO draft letter-of-intent to ARIN for an IPv6 prefix allocation request. Other groups had several other estimates, and the IETF felt that using a larger estimate was more conservative 🧚 Even with that order-of-magnitude difference, the raw number is still several orders of magnitude lower than estimated cellular telephone users, who might use the same protocol enhancements since the cellular industry has also adopted Mobile IP standards 📱

3.7. Req7 - Efficient Signaling 🎀

An RO scheme MUST be capable of efficient signaling in terms of both size and number of individual signaling messages and the ensemble of signaling messages that may simultaneously be triggered by concurrent flows.

3.7.1. Rationale for Aeronautics - Efficient Signaling 📡

the amount of bandwidth for aeronautical and space communications has historically been pretty tiny compared to what's desired (like, VDL links are 8 kbps of shared resources, bestie 😭), and that's expected to persist for at least several more years. Links tend to get provisioned based on estimates of application needs (which could totally prove wrong if demand or the apps themselves don't follow expectations), so there isn't much room for extra protocol overhead. Every byte of available air-ground link capacity that gets used by NEMO RO signaling is likely to delay application bytes and reduce application throughput. So it's important that the NEMO RO scheme's signaling overhead scales up way more slowly than the throughput of the flows RO is being performed on 🔥 That way, as higher-rate data links get deployed along with more bandwidth-hungry apps, the NEMO RO scheme can safely be discounted in capacity planning 💖

note that to meet this requirement, an RO technique must be efficient in both the size and number of individual messages it sends, as well as in the ensemble of messages sent at one time (for instance, to give RO to multiple ongoing flows following a handover), so it doesn't cause storms of packets related to RO ⛈️

this requirement came from ICAO's TC-7 - "The approach should result in throughput which accommodates anticipated levels of aircraft equipage."

3.8. Req8 - Security 🔒

For the ATS/AOS domains, there are three security sub-requirements:

The RO scheme MUST NOT further expose MNPs on the wireless link than already is the case for NEMO basic support.
The RO scheme MUST permit the receiver of a binding update (BU) to validate an MR's ownership of the CoAs claimed by an MR.
The RO scheme MUST ensure that only explicitly authorized MRs are able to perform a binding update for a specific MNP.

For the PIES domain, there are no additional requirements beyond those of normal Internet services, and the same requirements for normal Mobile IPv6 RO apply 🌈

3.8.1. Rationale for Aeronautics - Security 🛡️

the security needs are fairly similar between ATS and AOS, but they vary widely between the ATS/AOS domains and PIES. For PIES, the traffic flows are typical of terrestrial Internet use, and the security requirements for RO are identical to those of conventional Mobile IPv6 RO. For ATS/AOS, though, there are somewhat stricter requirements, along with some safe assumptions that RO scheme designers can make. Below, we describe each of these ATS/AOS issues, but we won't further discuss PIES RO security 🙌

the first security requirement is driven by concerns expressed by ATS communications engineers. The concern comes from current air-ground links to a craft and their lack of security, which has let eavesdroppers track individual flights in detail 👀 Protecting the MNP from exposure has been expressed as a requirement by this community, though the security of the RO system should not depend on secrecy of the MNP. The RO scheme should use some reasonable security mechanisms to both protect RO signaling via strong authentication and encrypt the MNP so it isn't visible over air-ground links 🔐

the second security requirement is driven by the risk of flooding attacks, which start when an attacker redirects an MNP's traffic to some target victim CoA. To protect bindings to bogus CoAs from being sent, the RO scheme must somehow validate that an MR actually possesses any CoAs that it claims. For the purposes of aeronautics, it is safe to assume ingress filtering is in place in the access networks 🚧

to protect against "rogue" MRs or abuse of compromised MRs, the RO scheme MUST be capable of checking that an MR is actually authorized to perform a binding update for a specific MNP. To meet this requirement, it can be assumed that some aeronautical organization authority exists who can provide the required authorization, possibly in the form of a certificate that the MR possesses, signed by the aeronautical authority 📜

it's also reasonable to assume trust relationships between each MR and a number of mobility anchor points topologically near to its CNs (these anchor points may be owned by the service providers). But it's not reasonable to assume that trust relationships can be established between an MR and any given CN itself. Within the onboard networks for ATS and AOS, it is reasonable to assume that the LFNs and MRs have some trust relationship 🤝

many individuals feel that by the time the IP-based ATN grows into production use, there will be a global ATN-specific Public Key Infrastructure (PKI) usable for ATS. It's agreed, though, that such a PKI does not currently exist and will take time to develop both technically and politically 🐢 This PKI could permit the establishment of trust relationships among any pair of ATS MNNs, MRs, or CNs through certificate paths, unlike the more limited trust relationships described in the previous paragraph. While it has been suggested that early test and demonstration deployments with a more limited-scale PKI can be used in the near-term, some parties still feel that, as a global PKI is developed, assuming one may be overly bold compared to assuming trust relationships with anchor points 😅 It's always possible to scale the anchor point assumption up if a PKI develops that allows the CNs themselves to become the anchor points. It is not possible to go back down in the other direction if a global PKI never emerges 💜

this requirement was extrapolated from ICAO's TC-8 - "The approach should be secure" and made more specific with help from the MEXT working group.

3.9. Req9 - Adaptability 🦋

Applications using new transport protocols, IPsec, or new IP options MUST be possible within an RO scheme ✨

3.9.1. Rationale for Aeronautics - Adaptability 🦋

okay so the concepts of operations for network-centric command and control, and for other IP-based networks in aeronautical and space environments, are not fully developed yet 🫠 the exact application protocols, data flow characteristics, and even transport protocols for both the transitional and final operational concepts are not completely defined, and they may even change with deployment experience. so the RO solution itself should allow all higher-layer protocols, ports, and options to be used ✨ it's giving "we don't know what's coming, so don't lock anything out" energy 💅

this requirement came from ICAO's TC-9: "The approach should be scalable to accommodate anticipated transition to new IP-based communication protocols." 🌸

4. Desirable Characteristics ✨

in this section we look at some properties of the system that are not strict requirements 💖 either they're hard to put a number on, or they're features nobody needs right away. still, they could add real benefits and help people actually adopt the thing 🫶

4.1. Des1 - Configuration 🎀

for ATS systems, complicated configurations are known to make the context more uncertain, make humans more likely to mess up, and raise the chance of reaching undesirable (unsafe) states [18] 😬 since RO changes the communications context between an MNN and a CN, a NEMO RO solution should be as simple to configure as possible. it should also be easy to turn off automatically if an undesirable state is reached 🙈

for CNs at big airports, the Binding Cache state management functions might be juggling hundreds of airplanes at once, with multiple service providers, plus a huge pile of mobility events from arrivals and departures 🛫 so it's desirable to have simple interfaces that humans can use to look at the Binding Cache configuration and change it when there are errors, as long as that doesn't get in the way of the RO protocol mechanisms themselves 🧚

4.2. Des2 - Nesting 🪆

it's desirable if the RO mechanism supports RO for nested MRs, because for PIES and astronaut spacesuits, PANs with MRs might need support 🧑‍🚀 for oceanic flights, ATS and AOS could also benefit from nesting MRs between multiple planes. that gives a "reachback" to terrestrial ground stations, so they aren't stuck relying only on lower-rate HF or satellite systems 📡 either way, this mode of operation is beyond the current strict requirements and is merely desirable. also, other ways to support these communications scenarios exist, using routing protocols or other means outside of NEMO 🌈

loop-detection, which supports nesting, is specifically not a requirement at this stage of ATN and space network designs 🔁 the reasons are that the operational environments are expected to be carefully controlled and to inherently avoid loops, and that scenarios involving nesting aren't envisioned in the near future ✨

4.3. Des3 - System Impact 🛠️

low complexity in systems engineering and configuration management is desirable when building and maintaining systems that use the RO mechanism 💜 this one is hard to quantify, judge, and compare across different RO techniques. still, a mechanism that's perceived to have lower impact on the complexity of the network communications system should be favored over an otherwise equivalent mechanism (with regards to the requirements listed above) 👑 this is kind of different from Des1 (Configuration). Des1 is about operating and maintaining the system once it's deployed, while Des3 is about the initial design, deployment, transition, and later upgrade path of the system 🦋

4.4. Des4 - VMN Support 🌷

at least LFNs MUST be supported by a viable RO solution for aeronautics, since these local nodes are within the ATS and AOS domains 🫶 if Mobile IPv6 becomes popular with portable consumer devices, VMNs within the PIES domain are expected to be numerous. it's strongly desirable for them to be supported by the RO technique, but not strictly required 📱 and LMNs are potentially present in future space exploration scenarios, like manned missions to the moon and Mars 🌙🔴

4.5. Des5 - Generality 🌍

an RO mechanism that is "general purpose", meaning it's also readily usable outside of aeronautics and space exploration, is desirable 🌈 for example, an RO solution that works within Vehicular ad hoc Networks (VANETs) [19] or consumer electronics equipment [20] could count. the goal is for the technology to be more widely used and maintained outside the fairly small aeronautical networking community and its vendors. that makes acquisitions and training faster, easier, and cheaper 💸 it could also let aeronautical networking benefit from future RO scheme optimizations and developments, which industry and academic communities would research and fund on their own 🧠✨

5. Security Considerations 🔐

this document does not create any security concerns in and of itself 🙌 but the security properties of any NEMO RO scheme used in aeronautics and space exploration are probably much more stringent than for general NEMO use. that's because safety-of-life and/or national security issues are involved 🚨 the required security properties are described under Req8 of Section 3 within this document 🔒

under an assumption of closed and secure backbone networks, the air-ground link is the weakest part of the network 😭 it's the most susceptible to injection of packets, flooding, and other attacks ⚠️ future air-ground data links that will use IP are being developed with link-layer security as a concern, which is great news 💖 this development can help meet one of this document's listed security requirements (that MNPs not be exposed on the wireless link). the other requirements affect the RO technology more directly, regardless of whether air-ground link-layer security is present or absent 🫠

when deploying in operational networks where network-layer security may be mandated (e.g., virtual private networks), the interaction between that and NEMO RO techniques should be carefully considered. the goal is to make sure the security mechanisms don't undo the route optimization by forcing packets through a less optimal overlay or underlay 🚫

for instance, when IPsec tunnel use is required, the locations of the tunnel endpoints can force sub-optimal end-to-end paths to be taken 🐢

6. Acknowledgments 🫶

input from several parties is indirectly included in this document 💕 participants in the Mobile Platform Internet (MPI) mailing list and BoF efforts helped shape it, and the early content was borrowed from the MPI problem statement and proposed requirements documents ([21], [13]) 📝 the NEMO and MONAMI6 working group participants were instrumental in completing it. the participants in the MEXT interim meeting on February 7th and 8th of 2008 in Madrid were critical in solidifying these requirements 🇪🇸 specific suggestions from Steve Bretmersky, Thierry Ernst, Tony Li, Jari Arkko, Phillip Watson, Roberto Baldessari, Carlos Jesus Bernardos Cano, Eivan Cerasi, Marcelo Bagnulo, Serkan Ayaz, Christian Bauer, Fred Templin, Alexandru Petrescu, Tom Henderson, and Tony Whyman were incorporated into this document 🌟

Wesley Eddy's work on this document was performed at NASA's Glenn Research Center 🚀 it was mainly in support of NASA's Advanced Communications Navigations and Surveillance Architectures and System Technologies (ACAST) project, and the NASA Space Communications Architecture Working Group (SCAWG) in 2005 and 2006 🧡

7. References 📚

7.1. Normative References

[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2. Informative References 💜

[4] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[5] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007.
[6] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007.
[7] ICAO Asia/Pacific Regional Office, "Required Communication Performance (RCP) Concepts - An Introduction", Informal South Pacific ATS Coordinating Group 20th meeting, Agenda Item 7, January 2006.
[8] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July 2007.
[9] Kempf, J., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007.
[10] Dul, A., "Global IP Network Mobility", Presentation at IETF 62 Plenary, March 2005.
[11] Ivancic, W., Paulsen, P., Stewart, D., Shell, D., Wood, L., Jackson, C., Hodgson, D., Northam, J., Bean, N., Miller, E., Graves, M., and L. Kurisaki, "Secure, Network-centric Operations of a Space-based Asset: Cisco Router in Low Earth Orbit (CLEO) and Virtual Mission Operations Center (VMOC)", NASA Technical Memorandum TM-2005-213556, May 2005.
[12] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", RFC 4980, October 2007.
[13] Davis, T., "Mobile Internet Platform Aviation Requirements", Work in Progress, September 2006.
[14] ICAO WG-N SWG1, "Analysis of Candidate ATN IPS Mobility Solutions", Meeting #12, Working Paper 6, Bangkok, Thailand, January 2007.
[15] Davis, T., "Aviation Global Internet Operations Requirements", ICAO WG-N, Sub-Working-Group N1, Information Paper #4 (IP4), September 2006.
[16] Wakikawa, R., "Home Agent Reliability Protocol", Work in Progress, July 2009.
[17] Zhang, L. and S. Brim, "A Taxonomy for New Routing and Addressing Architecture Designs", Work in Progress, March 2008.
[18] ICAO, "Threat and Error Management (TEM) in Air Traffic Control", ICAO Preliminary Edition, October 2005.
[19] Baldessari, R., "C2C-C Consortium Requirements for NEMO Route Optimization", Work in Progress, July 2007.
[20] Ng, C., "Consumer Electronics Requirements for Network Mobility Route Optimization", Work in Progress, February 2008.
[21] Ivancic, W., "Multi-Domained, Multi-Homed Mobile Networks", Work in Progress, September 2006.
[22] CCSDS, "Cislunar Space Internetworking: Architecture", CCCSDS 000.0-G-1 Draft Green Book, December 2006.
[23] NASA Space Communication Architecture Working Group, "NASA Space Communication and Navigation Architecture Recommendations for 2005-2030", SCAWG Final Report, May 2006.

Appendix A. Basics of IP-Based Aeronautical Networking 🛫✨

Okay so the current standards for aeronautical networking are built on the ISO OSI networking stack, and they're called the Aeronautical Telecommunications Network (ATN) 🛩️. It's standardized, but the ATN hasn't been fully deployed and it's only in limited use compared to its full vision and potential 😭. The International Civil Aviation Organization (ICAO) is a part of the United Nations that produces standards for aeronautical communications 🌍. ICAO noticed that an OSI-based ATN lacks the widespread commercial network support needed for new, more bandwidth-intensive ATN applications to deploy successfully, so it has recently been working towards a new IPv6-based version of the ATN 💖.

Supporting mobility in an IP-based network can be totally different from doing it in the OSI-based ATN 🔄. The ATN uses the Inter-Domain Routing Protocol (IDRP) to recompute routing tables as mobile networks change their topological points of attachment. ICAO knows this and has studied various mobility techniques based on link, network, transport, routing, and application protocols [14] 🧠.

Work done within ICAO has identified NEMO technology as a promising candidate for supporting global, IP-based mobile networking 🌐. The main concerns with NEMO are its current lack of route optimization support and its potentially complex configuration requirements in a large airport environment, with multiple service providers and 25 or more airlines sharing the same infrastructure 😬.

A big challenge for getting networking technologies to aeronautical users is how low the capability of existing air-ground data links is for carrying IP-based (or other) network traffic 🐢. Because of barriers of spectrum and certification, making new standards and equipment for the lower layers below IP is slow 🙃. Currently operating technologies may have data rates measured in the several kbps range, so it's clear that supporting advanced IP-based applications will require new link technologies to be developed at the same time as networking technologies suited to aeronautics 🚀.

Some well-known commercial data links can be adapted for aeronautical use, such as Wideband Code-Division Multiple Access (WCDMA) standards or the IEEE 802.16 standard 📶. On top of those, several more specialized technologies either exist or have been proposed for air-ground use 👀:

VHF Data Link (VDL) specifies four modes of operation in the 117.975 - 137 MHz range that can support different mixes of digital voice and data at fairly low rates 📻. The low rates come from needing to operate within 25 kHz channels that are internationally allocated for aeronautical use. VDL mode 2 is somewhat widely deployed on aircraft, and two global service providers support VDL access networks ✈️. Experience with VDL mode 2 shows that several kbps of capacity delivered to a craft can be expected in practice 😅. The use of long timers and a collision avoidance algorithm over a large physical space (designed to operate at 200 nautical miles) limits the performance of IP-based transport protocols and applications 🐌.
Aircraft Communications and Reporting System (ACARS) is a messaging system that can be used over several types of underlying RF data links (e.g., VHF, HF, and satellite relay) 📨. ACARS automates the sending and processing of several types of event notifications over the course of a flight 🛬. ACARS in general is a higher-level messaging system, whereas the more specific "Plain Old ACARS" (POA) refers to a particular legacy RF interface that the ACARS system used before the adoption of VDL and other data links 🕰️. Support for IP-based networking and advanced applications over POA is not feasible 💀.
Broadband Aeronautical Multi-carrier Communications (B-AMC) is a hybrid cellular system that uses multi-carrier CDMA from ground-to-air and Orthogonal Frequency Division Multiplexing (OFDM) in the air-to-ground direction 📡. B-AMC runs in the L-band of spectrum and is adapted from the Broadband-VHF (B-VHF) technology that was originally developed to operate in the VHF spectrum 🔁. L-band use is meant to occupy the space formerly allocated for Distance Measuring Equipment (DME), using channels with greater bandwidth than are available in the VHF band, where analog voice use will continue to be supported 🎶. B-AMC may permit substantially higher data rates than existing deployed air-ground links 🔥.
All-Purpose Multi-Channel Aviation Communications System (AMACS) is an adaptation of the Global System for Mobile Communications (GSM) physical layer that operates in the L-band with 50 - 400 kHz channels and uses VDL mode 4's media access technique 🧩. AMACS may permit data rates in the several hundred kbps range, depending on the specific channelization policies deployed 📊.
Project 34 (P34) is a wideband public-safety radio system that can be used in the L-band 🚨. P34 is designed to offer several hundred kbps of capacity specifically for IP-based packet networking 💜. It uses OFDM in 50, 100, or 150 kHz channels, and the exact performance depends on the particular operating band, range (guard time), and channelization plan configured in deployment 🎛️.
L-Band Data Link (LDL) is another L-band proposal based on existing technologies 🌈. LDL adapts the VDL mode 3 access technique and is expected to be capable of up to 100 kbps ⭐.

Appendix B. Basics of IP-based Space Networking 🌌

IP itself is only in limited operational use for talking to spacecraft right now, for example with the Surry Satellite Technology Limited (SSTL) Disaster Monitoring Constellation (DMC) satellites 🛰️. Future communications architectures do include IP-based networking as an essential building block, though 🧱. The Consultative Committee for Space Data Systems (CCSDS) has a working group producing a network architecture for using IP-based communications in both manned and unmanned near-Earth missions, with international participation towards this goal [22] 🌏. NASA's Space Communications Architecture Working Group (SCAWG) has also developed an IP-based multi-mission networking architecture [23] 🚀. Neither of these is explicitly based on Mobile IP technologies, but NEMO is usable within these architectures, and they may be extended to include NEMO when and if the need becomes apparent 🔮.

Authors' Addresses 🖋️💕

Wesley M. Eddy
Verizon Federal Network Systems
NASA Glenn Research Center
21000 Brookpark Road, MS 54-5
Cleveland, OH  44135
USA

EMail: weddy@grc.nasa.gov


Will Ivancic
NASA Glenn Research Center
21000 Brookpark Road, MS 54-5
Cleveland, OH  44135
USA

Phone: +1-216-433-3494
EMail: William.D.Ivancic@grc.nasa.gov


Terry Davis
Boeing Commercial Airplanes
P.O.Box 3707  MC 0Y-96
Seattle, WA  98124-2207
USA

Phone: 206-280-3715
EMail: Terry.L.Davis@boeing.com

📦 where this page comes from

ietf: rfc5522 2009-10
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms