Multiple Federation Taxonomy Michael Myjak Vice President, R&D The Virtual Workshop, Inc. P.O. Box 98 Titusville, FL 32781 <mmyjak@virtualworkshop.com>

Project Goals To analyze the evolving models of federation development, and indicate where extensions might be provided... To expand on the scope and variety of federation executions... And to determine the validity of multiple federation interaction.

Background… HLA supports the interoperation of sets of simulations within the context of a single FOM, using the HLA Federate Interface Specification services provided by the Run Time Interface (RTI). But this doesn’t say anything about Compound Federates, Federation Hierarchies, or Cross-Federation Relationships!

Reaching Beyond the Boundaries The original developers of HLA realized that some issues were problematic: Hierarchical or Recursive Federates Hierarchical or Recursive Federations RTI-to-RTI interface protocols So they were simply written out of the HLA specification. Beyond scope

And it came to pass... How did we get to this point? Are multifederation simulations required? Security and other multi-level domain models seem to indicate this is so. Could it be that the pendulum of Abstraction has swung to far to the right? From OSI based Interoperable Datagrams and Packets... to Frameworks and Architectures that only promote interoperability?

First, a Little Simulation Archeology 1984 - the birth of SIMNET ARPANET transitioned to the NSF. The Macintosh had just been released into the marketplace. We saw the introduction of window systems, the mouse, desktop networking. Mac Maze, Sim City, etc. Intel 8086 Computers were Hot! and Pong was The Thing!

Data Link layer Protocol SIMNET Layered Model SIMNET Application [User’s Application] SIMNET Protocol [Custom Protocols] Association Protocol Data Link layer Protocol [e.g., IEEE 802.3] Hardware

The way things stack up... Protocol Layers User’s Application ref: IEEE 1278.2-1995 - Figure 2: shows a representation of this ISO 7-layer model User’s Application Application Layer Transport Layer Internet Layer Data Link Layer Hardware Layer Presentation Layer Session Layer Protocol Layers The foundation of the OSI Model...

Simulation Archeology (con’t) As SIMNET and the Internet evolved Simulation and Interoperability were still in their infancy. DIS standardization attempts - Focus was on transport-level Interaction. OSI Model was incorporated. ALSP developers found DIS to restrictive Evolved a higher level abstraction - Advanced Distributed Simulation

[Standardized Protocols] DIS Layered Model DIS Application [User’s Application] UDP / TCP Transport Protocol [Standardized Protocols] Internet Protocol Data Link Protocol [e.g., IEEE 802.3] Hardware

Simulation Archeology (con’t) ASLP evolved 3 unique requirements beyond those identified in DIS Time Management Maintain causality by coordinating events. Data Management Each simulation application (or application process) uses its own database. A Common Architecture Introduced the ALSP Common Module

High Level ALSP Model ALSP ALSP Application Application ALSP ALSP Actor/Translator ALSP Common Module ALSP Common Module ACM ALSP Basic Engine ABE

High Level Architecture Model Federate Application Federate Application Notice the relationship here… ? RTI Ambassador RTI Ambassador Run Time infrastructure

ALSP Layered Implementation Application Actor/Translator ALSP Common Module ACM UDP Transport Protocol Internet Protocol ABE Data Link Protocol [e.g., IEEE 802.3] Hardware

Simulation Archeology (con’t) HLA also retained ALSP’s principle extensions from DIS environments: The federation has no central node No server, at least in concept. Federates can be geographically distributed They can reside in different locations. Federate communications use a pre-defined interface resembling message passing in object-oriented design. Attribute and Interaction Updates.

Motivation behind HLA... HLA is a relative newcomer to M&S Demonstrations have shown: Support for the reuse of legacy systems. Usefulness in data acquisition & confirmation. System integration, including disparate simulation systems. But where does HLA fit In the “Open Systems Interconnect” (OSI) Model?

DIS and SIMNET Applications Simulation Application Application’s Network Interface, NIU, NAPI, etc. All Generated Network Interface code Directly... SIMNET & DIS PDUs UDP / TCP Transport Protocol Internet Protocol Data Link Protocol Hardware

ALSP and HLA “Raised the Bar” Confederate / Federate Application Program Interface ALSP Common Module - or - Run-Time Infrastructure UDP / TCP Transport Protocol Internet Protocol Data Link Protocol Hardware

Internetwork Model Layering... Conceptual Layers Seen by the User’s Application Objects Passed Between Layers API to User Applications Application Layer Messages & Streams Transport Layer Protocol Packets Internet Layer IP Datagrams Data Link Layer Network-Specific Frames Hardware Layer

Focus On The Application Layer Well-defined application layer protocol specifications are: Concise Clearly Articulated unambiguous Application Layer Protocols define two interfaces: To the “User Application*” To the Transport Layer Protocol Comer defines “user application” as either the user, or the user’s application.

Application Layer is the Key In one sense, the application layer protocol is unique* among the other protocol layers - Only the application layer protocol defines two discrete interfaces: One to interface with the user’s application, and One to interface with the lower layer interface. So, if HLA is an Application Layer Protocol… then the following architectural examples are all possible. Excluding the data link and hardware layers, as they also have unique features.

Basic HLA Federation The Infamous Lollypop Diagram… Squared up a bit...

2 Levels of Classification The most basic level of classification permits Federations to be classified into two broad types: Bridged RTI & Federate Bridges Federate and Federation Proxies Hierarchical Containing Component Federates Proxy Federates (gateways)

Bridged Federations A True Bridge Inter or Intra-RTI

Bridged Federations True Bridge Connects internally between RTI Understands the RTI to RTI interface A protocol which here unto is undefined Requires RTI internal state information Potential exists to operate using the Federate Interface Specification... However, this his solution is problematic - Unclear how multiple yet dissimilar services could be bridged

Bridged Federations Federation Proxy (not a Gateway!) Inter Federate-level Operation (traffic is “out of band” from the RTI) Bridges Two or more Federations

Hierarchical Federations Simulation Proxies - Basic Form Sometimes called Gateways...

Hierarchical Federations Component or Hierarchical Federates A Federate consisting of Multiple components

Hierarchical Federations Logical view of Joined Component Federates

Hierarchical Federations Components May Also Be Non-Federates

Hierarchical Federations Simulation Proxy between component federates… e.g., DIS Gateway

Conclusions RTI developers need to be aware of special interest Federate and Federation designers. The “Other” interface to the RTI needs work too! Policy is easy… it’s the mechanics that need additional support. Clear and simple need will be the driving factor.