RFC 1667

RFC 1667: Modeling and Simulation Requirements for IPng 💖

okay bestie, this is part 1 of 2 so hold onto your 🎀 🦋. This is RFC 1667, titled Modeling and Simulation Requirements for IPng, and it's an Informational doc from the Network Working Group, dated August 1994. It's written by S. Symington and D. Wood (both from MITRE Corporation) and M. Pullen (George Mason University). The header doesn't list anything it obsoletes or updates, so it's just doing its own thing 💅

Status of this Memo ✨

This memo gives information to the Internet community. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🌸

Abstract 🫶

This doc was submitted to the IETF IPng area as a response to RFC 1550. Publishing it does not mean the IPng area accepted any of the ideas in it, so no pressure. If you want to comment, send them to the big-internet@munnari.oz.au mailing list 💜

Executive Summary 👑

The Defense Modeling and Simulation community uses packet networks a LOT, so it has a real stake in how IPng gets defined. This white paper sums up the Distributed Interactive Simulation environment that's currently being built, focusing on how real-time it is and how big its networking needs are 🔥 It sets out the requirements for real-time response, multicasting, and resource reservation, based on the community's best current understanding of where Defense Modeling and Simulation is headed ✨

1. Introduction 🦋

The Internet Engineering Task Force (IETF) is currently designing the Next Generation Internet Protocol (IPng) 👀 IPng is expected to be a driving force behind the future of commercial off-the-shelf (COTS) networking tech, and it's going to have a huge impact on which networking technologies are widely available, cost effective, and interoperable across multiple vendors 💅 Apps that get all of their network-layer requirements from IPng's standard features are going to be at a great advantage. The apps that don't? They'll have to lean on less-available, pricier protocols that might not play nicely with the everywhere-IPng-based COTS products 😭

This paper is meant to be input for the IPng design work, and it does that by spelling out the network-layer requirements of Defense Modeling and Simulation (M&S) applications. It's super important that the M&S community makes its unique needs clear to the IPng designers, so that the mechanisms meeting those needs can be considered as standard IPng features 🧚 The goal is for IPng's perks (wide COTS availability, multi-vendor interoperability, and cost-effectiveness) to be fully available to the M&S community. no cap, that's the whole mission 💖

2. Background: Overview of Distributed Interactive Simulation 🌈

The Defense M&S community needs an integrated, wide-area, wideband internetwork to run Distributed Interactive Simulation (DIS) exercises. These exercises connect remote, dissimilar simulation devices at sites all around the world 🌍 The network topology used in current M&S exercises is usually a high-speed cross-country and trans-oceanic backbone running between wideband packet switches, with tail circuits running from those packet switches out to various nearby sites 🛰️ At any site taking part in an exercise, there might be several internetworked local area networks with lots of simulation entity hosts running on them. Some of those hosts could be running computer-generated semi-automated forces, while others could be manned simulators 🎮

The whole system has to handle delays and delay variance that work with human interaction times. That's how it keeps an accurate order of events and a realistic combat simulation ⚔️ The sites can be geographically far apart, but the simulation entities at different sites might be acting and interacting as if they're right next to each other on the battlefield 🫠 The goal is for all of this to happen on one common network that supports all Defense modeling and simulation needs, and hopefully gets shared with other Defense applications too 🤞

In a typical DIS exercise, distributed simulators swap info over an internetwork in the form of standardized protocol data units (PDUs) 📦 The DIS protocols and PDU formats are still under development. The first generation was standardized as IEEE 1278.1 and used for small exercises (around 100 hosts), and a second generation is in the works. The current Communications Architecture for DIS specifies the use of Internet protocols, which is very on-brand for IPng 🫶

The amount, type, and sensitivity level of the info that has to be exchanged during a typical DIS exercise is what drives that exercise's communications requirements. It depends on how many entities are taking part, what types they are, and how they interact with each other 🧠 Future DIS exercises now in planning are going to reach hundreds of sites and tens of thousands of simulation platforms worldwide 😳 For example, an exercise might have semi-automated and manned tank, aircraft, and surface ship simulators all interacting on pre-defined geographic terrain 🚀 The actual locations of those simulation entities might be spread across sites in Virginia, Kansas, Massachusetts, Germany, and Korea 🗺️

The PDUs swapped between entities at these sites have to carry all of the info needed to tell each site about everything relevant that happens with the other sites that could affect it in the simulation. That info could include each entity's location, its direction and speed, the orientation of its weapons systems (if it has any), and the frequency it's transmitting and receiving radio messages on 📡 If an entity launches a weapon, like a missile, a brand new entity representing that missile gets created in the simulation. It starts sending its own PDUs with info about its state, like its location and speed 💥

A typical moving entity generates between one and two PDUs per second. Typical PDU sizes are 220 bytes, with a maximum size of 1400 bytes, although rates of 15 PDUs/second and higher are possible 🏎️ Stationary entities still have to generate some traffic to refresh the receiving simulators. Under the current standard, that can be as little as 0.2 PDUs per second 🐢 Compression techniques that reduce PDU size by 50% or more are being investigated, but they aren't included in the current DIS standard yet ✨

With so much info flying around among simulation entities at lots of locations, multicasting is required to cut down on the network bandwidth used. It also cuts down on the input to individual simulation entities, so each entity only receives the PDUs that matter to it 💜 For example, a given entity only needs info about the location, speed, and direction of other entities that are close enough in the simulation geography that they could affect it. Similarly, an entity doesn't need PDUs with the contents of radio transmissions sent on a frequency other than the one it's listening to 📻

Resource reservation mechanisms are also essential to guarantee the performance DIS exercises need. Reliability and real-time transmission are necessary to accommodate the manned simulators taking part in an exercise 🔒

M&S exercises with humans in the loop that run in real time need rapid network response times to provide realistic combat simulations. For DIS, the latency requirements are defined as the time between when a PDU is output at the application level of one simulator and when it's input at the application level of any other simulator in the same exercise 🕒 Here's the breakdown:

• 100 milliseconds for exercises containing simulated units whose interactions are tightly coupled
• 300 milliseconds for exercises whose interactions are not tightly coupled [2].

The reliability of the best-effort datagram delivery service supporting DIS should be such that 98% of all datagrams are delivered to all intended destination sites, with the missing datagrams randomly distributed [3]. That's a whole vibe 🎯

These numbers might get refined for some classes of simulation data in the future, but latency is expected to stay under a few hundred milliseconds in all cases ⏱️ It's also required that delay variance (jitter) be low enough that smoothing by buffering the data stream at the receiving simulator doesn't cause the stated latency specs to be exceeded. Jitter is a whole thing, bestie 😤

There are several architectures under consideration for the M&S network of the future. Under fully distributed models, all simulation entities rely directly on the network protocols for multicasting. That gives them a lot of flexibility to join and leave multicast groups dynamically, in large numbers 🦄

In some cases, M&S exercises will involve sending classified data over the network. For example, messages might contain sensitive data about warfare tactics and weapons systems characteristics, or an exercise itself might be a rehearsal of an imminent military operation 🫣 That means the data communications used for these exercises have to meet security constraints defined by the National Security Agency (NSA). Some of those requirements can be met in current systems with end-to-end packet encryption (E3) systems. E3 systems give adequate protection from disclosure and tampering, while still letting multiple security partitions use the same network at the same time 🔐

Right now, the M&S community is using the experimental Internet Stream protocol version 2 (ST2) to provide resource reservation and multicast 🧪 There's a lot of interest in switching over to IPv4 multicast once it's available across the COTS base, but that can't happen until IPv4 has a resource reservation capability. The community is watching the RSVP work ongoing in the IETF in the hope that it'll provide that capability 👀 Some tests of IPv4 multicast without resource reservation have already come back positive, but larger tests are still needed to confirm the expected scalability of IPv4 multicast. Issues remain though: for security reasons, some M&S exercises will require sender-initiated joining of members to multicast groups. It's also not clear that IPv4 multicast will be able to make use of the link-layer multicast available in ATM systems, which the M&S community expects to use to hit the performance needed for large exercises 😩

---

More to come in part 2! 🌸

3. M&S Requirements for IPng ✨

Okay bestie, this is where the M&S crowd spills exactly what they need from IPng 💅 The network-layer service requirements fall into three big categories: real-time response, multicast capability, and resource reservation capability 🦋 Everything here is an absolute requirement for supporting DIS the way the M&S community currently understands it, except the stuff explicitly marked highly desirable 🙈 By desirable, we mean it's not essential, but it would unlock more direct or cost-effective networking solutions. Iconic, right?

Some of these capabilities MAY be provided by companion protocols instead of IPng itself, like RSVP and IGMP 🧚 The real ask is a compatible suite of protocols that you can actually buy in commercial products 🛍️

a. Real-time Response

DIS is still going to need to communicate real-time data, so how well IPng can power real-time networks is basically how we'll measure its usefulness for M&S networking 🔥 The system-level specs for the DIS real-time environment are laid out in Section 2 above, so go check those out 🌸

b. Multicasting

M&S needs a multicasting capability and a way to manage multicast group membership 🫶 These multicasting capabilities MUST meet the following requirements:

• Scalable to hundreds of sites and, potentially, to tens of thousands of simulation platforms 🌍
• It is highly desirable that the network-layer multicasting protocol be able to use the multicasting capabilities of link-level technologies, such as broadcast LANs, Frame Relay, and ATM 💜
• The group management mechanics MUST have the characteristics that thousands of multicast groups consisting of tens of thousands of members each can be supported on a given network, and that a host SHOULD be able to belong to hundreds of multicast groups simultaneously 👑
• Multicast group members MUST be able to be added to or removed from groups dynamically, in less than one second, at rates of hundreds of membership changes per second. It's not possible to predict what special cases MAY develop, so this requirement covers all members of all groups 😭
• The network layer MUST support options for both sender- and receiver-initiated joining of multicast groups 🎀

c. Resource Reservation

The M&S community needs performance guarantees from its supporting networks, no cap 💖 That means IPng MUST be compatible with a capability to reserve bandwidth and other necessary allocations in a multicast environment. The goal is to guarantee network capacity from simulator to simulator across a shared network for as long as the user is interacting with the network ✨ This kind of reservation is essential for using limited network resources well, boosting reliability, and cutting delay and delay variance for priority traffic, especially when the network is heavily used 🔥 The reservations SHOULD be accomplished so that traffic without performance guarantees gets re-routed, dropped, or blocked before reserved bandwidth traffic is affected. Main character energy for the reserved traffic 👑

It would be highly desirable for the resource reservation capability to also provide mechanisms for:

• Invoking additional network resources (on-demand capacity) when needed 🧁
• The network feeding back its loading status to the applications, so they can gracefully degrade performance 🦋

---

4. References 📚

[1] Cohen, D., "DSI Requirements", December 13, 1993.

[2] Final Draft Communication Architecture for Distributed Interactive Simulation (CADIS), Institute for Simulation and Training, Orlando, Florida, June 28, 1993.

[3] Miller, D., "Distributed Interactive Simulation Networking Issues", briefing presented to the ST/IP Peer Review Panel, MIT Lincoln Laboratory, December 15, 1993.

[4] Pate, L., Curtis, K., and K. Shah, "Communication Service Requirements for the M&S Community", September 1992.

[5] Pullen, M., "Multicast Network Architecture for DIS, briefing presented to the Networks Infrastructure Task Force", George Mason University, C3I Center/Computer Science, November 10, 1993, revised November 11, 1993.

---

5. Authors' Addresses 💌

These are the brilliant minds behind it all 🧚

Susan Symington
MITRE Corporation
7525 Colshire Drive
McLean, VA 22101-3481

Phone: 703-883-7209
EMail: susan@gateway.mitre.org

David Wood
MITRE Corporation
7525 Colshire Drive
McLean, VA 22101-3481

Phone: 703-883-6394
EMail: wood@mitre.org

J. Mark Pullen
Computer Science
George Mason University
Fairfax, VA 22030

Phone: 703-993-1538
EMail: mpullen@cs.gmu.edu