Multiple Federation Taxonomy

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

2. 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.

3. Background… • HLA supports the interoperation of sets of simulations within the context of a singleFOM, 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!

4. 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

5. 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?

6. 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!

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

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

9. 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

10. 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

11. 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

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

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

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

15. 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.

16. 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?

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

18. 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

19. 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

20. 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.

21. 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.

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

23. 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)

24. Bridged Federations • A True Bridge • Inter or Intra-RTI

25. 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

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

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

28. Hierarchical Federations • Component or Hierarchical Federates • A Federate consisting of Multiple components

29. Hierarchical Federations • Logical view of Joined Component Federates

30. Hierarchical Federations • Components May Also Be Non-Federates

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

32. 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.