(AGIE) Using Internet Protocols - Aviation Committees - AEEC - AMC

ARINC PROJECT PAPER 830TABLE OF CONTENTS4.0 AGIE FUNCTIONAL SPECIFICATION .................................................................... 28284.1 Top-Level Capabilities ............................................................................................. 28284.2 Architecture .............................................................................................................. 29294.2.1 AGIE Clients ........................................................................................................ 29294.2.2 AGIE Servers ...................................................................................................... 32324.2.3 Topology Considerations ..................................................................................... 33334.2.4 Cross Domain AGIE ............................................................................................ 34344.2.5 AGIE and AMQP Architecture ............................................................................. 34344.2.6 AGIE Architectural Security ................................................................................. 35354.3 Paths and Routing ................................................................................................... 36364.3.1 IP Routes ............................................................................................................. 36364.3.2 AGIE Connections and Profiles ........................................................................... 36364.3.3 AGIE Paths .......................................................................................................... 37374.3.3.1 Best Path Selection ........................................................................................ 37374.4 Messaging and Message Delivery ........................................................................... 37374.4.1 Message Service Interface .................................................................................. 39394.4.2 Message Service Attributes ................................................................................. 39394.4.2.1 Priority Request .............................................................................................. 40404.4.2.2 Message or Notification .................................................................................. 40404.4.2.3 Originator Controls ......................................................................................... 40404.4.3 Message Service Considerations ........................................................................ 41414.4.3.1 Immediate Messaging .................................................................................... 41414.4.3.2 Point-to-Multi-Point Messages ........................................................................ 42424.4.3.3 Large and Small Messages ............................................................................ 42424.4.3.4 Publish-Subscribe Message Service .............................................................. 42424.4.4 Priorities and Flow Control .................................................................................. 43434.4.4.1 Prioritization Mechanisms ............................................................................... 44444.4.4.2 AGIE Priority Expectations ............................................................................. 44444.4.4.3 Priorities in Functions ..................................................................................... 45454.4.4.4 Background Priority ........................................................................................ 45454.4.4.5 Priorities with Network .................................................................................... 45454.5 Naming and Addressing Processing ........................................................................ 46464.5.1 Name Space Considerations ............................................................................... 46464.5.2 Naming Considerations ....................................................................................... 47474.5.3 AGIE Name Descriptors ...................................................................................... 48484.5.4 Name Parsing ...................................................................................................... 48484.5.5 Name Resolution ................................................................................................. 49494.5.6 Address Resolution ............................................................................................. 49494.5.7 AGIE Name Service ............................................................................................ 50504.6 AGIE Functions ........................................................................................................ 51514.6.1 AGIE Client Functions ......................................................................................... 52524.6.1.1 Accept and Process Incoming XML Service Request from Application .......... 53534.6.1.2 Send Autonomous Request to Host ............................................................... 53534.6.1.3 Receive and Process Message from Host ..................................................... 54544.6.2 AGIE Server Functions ........................................................................................ 55554.6.2.1 AGIE Message Server Functionality Overview ............................................... 56564.6.2.1.1 Message Origination Host Server Tasks ................................................... 57574.6.2.1.2 Message Destination Host Server Tasks ................................................... 58584.6.2.1.3 Current Message Client Host Server Tasks ............................................... 58584.6.2.1.4 Client Home Server Tasks ......................................................................... 58584.6.2.2 Message Storage ........................................................................................... 58584.6.3 Primary and System Functions ........................................................................... 60604.6.3.1 Root AGIE Name Service Functions .............................................................. 6060

ARINC PROJECT PAPER 830TABLE OF CONTENTS4.6.3.2 Publish-Subscribe Server Functions .............................................................. 60604.6.3.3 Configuration Database Distribution Functions .............................................. 60604.6.3.4 AGIE Logging Functions ................................................................................. 61614.6.3.5 Admin Functions ............................................................................................. 61614.6.3.6 Isolated Network Communication ................................................................... 62624.6.3.7 Primary Redirect Function .............................................................................. 62624.6.3.8 AGIE Compaction Function ............................................................................ 63634.6.4 AMQP Functions ................................................................................................. 63634.7 Security Requirements ............................................................................................. 64644.7.1 Internal Security Requirements ........................................................................... 64645.0 AGIE OPERATIONS ................................................................................................ 66665.1 System Setup ........................................................................................................... 67675.1.1 AMQP Setup and Configuration .......................................................................... 68685.2 Configuration Management ...................................................................................... 68685.3 Operational AGIE Naming Considerations .............................................................. 69695.3.1 Operational Naming Requirements ..................................................................... 69695.3.2 Suggested Naming Practices .............................................................................. 69695.4 Operational Priority Considerations ......................................................................... 70705.5 Operational Path Considerations ............................................................................. 71715.6 Security and Partitioning .......................................................................................... 71715.6.1 Operational Partitioning ....................................................................................... 72725.7 Use Case Overview ................................................................................................. 73735.7.1 User Application Use Cases ................................................................................ 73735.7.2 Infrastructure Use Cases ..................................................................................... 74746.0 AGIE INTERFACES ................................................................................................. 76766.1 XML Interfaces ......................................................................................................... 77776.1.1 Application-to-Client-to-Host Interface ................................................................ 77776.1.1.1 Application-Client-Host XML Description ........................................................ 78786.1.2 Host-to-Client-to-Application Interface ................................................................ 78786.1.2.1 Host-Client-Application XML Description ........................................................ 78786.2 Coordination Messages ........................................................................................... 78786.3 Coordination Database Definitions .......................................................................... 79796.3.1 Client DB Definition ............................................................................................. 80806.3.2 Server DB Definition ............................................................................................ 80806.3.3 Current Associations DB Definition ..................................................................... 80806.3.4 Connection Profiles DB Definition ....................................................................... 80806.3.5 Current Paths DB Definition ................................................................................ 81816.3.6 Message Types DB Definition ............................................................................. 81816.3.7 Best Path Selection Table DB Definition ............................................................. 8181APPENDICESAPPENDIX A GLOSSARY OF TERMS ................................................................................ 8280APPENDIX B AGIE OPERATIONAL THREADS .................................................................. 8987APPENDIX C AMQP THREAD MAPPING AND DIAGRAMS .......................................... 107105v

ARINC PROJECT PAPER 830 – Page 11.0 INTRODUCTION1.0 INTRODUCTIONAircraft communications is an important element in the operations and safety oftoday’s commercial airlines. This is becoming more evident as new aircraft areintroduced into airlines’ fleets, like the Airbus A380 and Boeing B787, and involveincreasingly more data intensive operations. Similarly, many airlines areincorporating Electronic Flight Bags (EFBs), which typically have large datarequirements, into the operations of their existing legacy aircraft, as well as onboardmobile devices that support flight deck, cabin, and maintenance functions. Thisincrease in the amount of operational data and messaging results in acorresponding increased demand on aircraft communications systems and theirability to handle the necessary data exchanges with the various onboardapplications.Today, there can be many data communications paths to and from the aircraft.These typically involve many different communications media that could include, forexample, VHF, HF, satellite, cellular, and Wi-Fi Gatelink. Some recentimplementations in the satellite, cellular, and Wi-Fi Gatelink areas potentially havethe capability to address the broadband communications requirements needed tohelp meet the increased data communications demands discussed above. Thesebroadband capabilities are typically IP (Internet Protocol) -based communicationstechnologies. However, separate technology implementations within each of themedia as well as between the media themselves currently require each aircraftapplication to specifically meet the unique interface requirements of each mediacommunications path in order to use it.It is desirable, therefore, to have a common aircraft communications interface thatall onboard message oriented applications could use to access the appropriatemedia link to communicate with their ground complements. In addition, because thebroadband throughput capability may not always be available along the entire pathbetween the aircraft application and its complement on the ground (e.g., airlineserver), it is also desirable to allow a common store and forward capability to beimplemented on the ground to address such throughput restrictions when they arise.This will help minimize the need for costly communication equipment on the groundthat various users might find necessary to deploy to address throughput restrictionsimpacting their individual applications.1.1 PurposeThe purpose of ARINC Project Paper 830 is to define a general purpose nonproprietaryinformation exchange framework and protocol for the conduct of InternetProtocol based message traffic between aircraft and airline ground infrastructure.This standard is motivated by the vision to substantially simplify informationprocessing management for airlines by eliminating multiple dissimilarimplementations with a single universal system and thereby establishing a moreeconomical environment.1.2 ScopeThis document defines Aircraft/Ground Information Exchange (AGIE) as a set offunctions, protocols and interfaces in sufficient detail such that any party maydevelop a functioning and interoperable implementation of the standard. To allowAGIE to meet an acceptable deployment schedule, complex features deemed notrequired for initial use cases are deferred to a future definition of this standard. This

ARINC PROJECT PAPER 830 – Page 21.0 INTRODUCTIONspecification defines features, capabilities, and requirements necessary to executeinitial use cases only, while minimizing conceptual and development complexity.1.3 Document OverviewThis document is structured as follows:Section 2.0 provides purposes and objectives of the AGIE standard.Section 3.0 provides a brief overview of the AGIE standard and operatingprinciples with focus of a user’s perspective.Section 4.0 describes AGIE from a functional aspect from a developer’sperspective. This section contains all functional requirements.Section 5.0 describes AGIE from an operational aspect from an operator’sperspective. It contains all operational requirements and externalexpectations for an implementation of this standard and describes the AGIEsystem administration related requirements.Section 6.0 describes all interface specifications and semantics. Theseinclude both component-to-component and peer-to-peer interfaces.Component interfaces consist of functional interfaces, while peer interfacesconsist of coordination messages and databases.APPENDIX A is the Glossary of Terms.APPENDIX B provides a description of example AGIE operational threads.APPENDIX C provides mapping of operational threads to AMQPfunctionality.APPENDIX CAPPENDIX D provides AGIE interface syntax in XML format.Sections 4 through 6 contain all AGIE normative requirements. The remainingsections are descriptive in nature. For this standard, “shall” means “required” or“mandatory” to claim compliance to this standard.1.4 Related DocumentsHigh-level requirements for a messaging service type application are addressed inARINC Report 821: Aircraft Network Server System (NSS) Functional Definition.ARINC 821 serves as an umbrella document that identifies and describes the highlevelrequirements for various network services from which detailed requirementsare derived in respective dedicated ARINC Standards. In addition to high-levelrequirements, ARINC 821 provides general guidance and design considerations foraircraft network services, as well as defines a set of services for management ofnetwork elements.The other network services that have their high-level requirements delineated inARINC Report 821 but have their detailed requirements developed in separate,dedicated standards include avionics interface services such ARINC Specification664 Part 5: Network Domain Characteristics and Interconnection, ARINC ProjectPaper 839: Manager of Air/Ground Interface Connections (MAGIC) and themessaging services such as the Aircraft/Ground Information Exchange (AGIE) asdefined by this document.Additional reference documents include those related datalink interfaces, services,QoS, and performance. These include:ARINC Characteristic 781: Mark 3 Aviation Satellite Communication System.ARINC Characteristic 791: Mark I Aviation Ku-Band and Ka-Band SatelliteCommunication System

ARINC PROJECT PAPER 830 – Page 31.0 INTRODUCTIONARINC Specification 841: Media Independent Aircraft Messaging (MIAM)FAA: Aircraft Access to SWIM Implementation Guidance V2.0RTCA SC-206 Aeronautical Information Services (AIS) Data Link standards aredefined to deliver aeronautical information and weather to and from the aircraftsystems to and from the ground.RTCA SC-206 DO-308: Operational Services and Environment Definition(OSED) for Aeronautical Information Services (AIS) Meteorological (MET) DataLink Services, December 2006RTCA SC-206 DO-324: Safety and Performance Requirements (SPR) forAeronautical Information Services (AIS) and Meteorological (MET) Data LinkServices, December 2010RTCA DO-340: Concept of Use for AIS and MET Data Link Services,September 2012 [9] ConUseCOMMENTARYDuring the preparation of this document, several papers were prepared byvarious Subcommittee participants that provide additional useful informationrelated to AGIE implementation, development and operation but the contentdoes not constitute material to be included in this document. These papers maybe obtained by contacting ARINC Industry Activities and are found in AEECLetter 13-088/AMS. The following is a partial list of these papers:1. Considerations for AGIE Certification and Approval2. AGIE DNS Use3. Deferred AGIE Features4. AGIE Demonstration and Testing Scenarios5. AGIE Topologies6. AGIE Use Cases1.5 Regulatory ApprovalAGIE is an end-to-end message transport service for aviation air-to-groundapplications. As such, regulatory certification and approval may span multipleaviation environments including onboard, air/ground and ground/ground. Certifyingand/or approving AGIE as a system may involve multiple authorities for animplementation. AGIE is a middleware software service that may use resources ofother systems. AGIE is part of a larger system which includes applications, clients,administrative policies, intended use and function, safety hazard analysis,information security analysis, and operational mitigations. AGIE softwarecomponents will provide certification artifacts to be used in implementation.This document does not and cannot provide regulatory guidance. The developer isencouraged to contact their local regulatory authority for guidance in this area. TheAGIE system must be certified for its intended function in the geographical areasthat it operates.

ARINC PROJECT PAPER 830 – Page 41.6 AGIE Compliance1.0 INTRODUCTIONAGIE compliant implementations meet the functional, interoperable, and interfacerequirements contained in this standard. Independent implementations shouldfunction in a similar and consistent manner. Independently developed AGIEcompliant components, systems, or subsystems (clients, servers, applications, andsub-networks) are expected to seamlessly interact with other components within anAGIE compliant implementation.

2.0 AGIE PURPOSE AND OBJECTIVESARINC PROJECT PAPER 830 – Page 52.0 AGIE PURPOSE AND OBJECTIVESThe intention of ARINC Project Paper 830: Aircraft/Ground Information Exchange(AGIE) is to establish a standard for a non-proprietary application level informationinterchange framework. This includes protocols, functions, and interfaces thatenable application-to-application information exchange between aircraft and groundapplications in a universal manner. While at the AGIE layer all communicationsoccur over IP, the standard does not stipulate lower layer communicationtechnologies.The aviation industry has spent significant effort defining numerous, independentand often competing technologies and communication protocols to support thedelivery of aircraft information. With the introduction of these technologies toaviation comes the need to assure efficient, interoperable and secure informationinterchange between various systems and respective software applications suchthat airlines, airframe manufacturers, third-party content providers, and Internetdata-link service providers may rely on this type of data exchange infrastructure.This information interchange capability needs to be based on an always available,common, and non-proprietary information exchange framework. Moreover, thisframework needs to coordinate and centrally manage cost, performance and qualityof service, and reduce the operator’s footprint in applications associated serverequipment.Examples of systems that are in need of such an infrastructure include: DataLoading Systems, Electronic Flight Bags (EFB), In-Flight Entertainment (IFE), FlightOperations Quality Assurance (FOQA), and IP enabled avionics and cabin systems.Other emerging capabilities driven from regulatory community include: FAA AircraftAccess to SWIM and RTCA SC-206 weather and aviation information.2.1 ObjectivesAGIE brings several diverse concepts to bear on messaging and data exchange.AGIE goals include supporting cross domain services. These services support theAircraft Control Domain (ACD), Airline Information Services Domain (AIS) andPassenger Information and Entertainment (PIES) Domain. These domains aredefined in ARINC Specification 664 Part 5: Network Domain Characteristics andInterconnection. AGIE intentionally excludes the Passenger Operated DevicesDomain (PODS). This goal is accomplished by providing features and capabilitiesthat allow operation across and segregation between these three domains.An additional important goal is for AGIE to be link agnostic. While AGIE is definedfor Internet Protocol (IP) links, it is intended to function over any air-to-ground link.AGIE shares these links with other services which may in fact be within any of thefour domains (in this context AGIE also interacts with PODS).While this Specification is designed to support these goals, it does not guaranteethat any specific implementation or set of overriding applications will in the end beapprovable. A careful security and safety analysis in implementation is required.AGIE’s end-to-end capability is unique (compared to other aviation standards) inthat most aviation standards apply to either the air or ground side or to a (rather)narrow air-to-ground segment. AGIE is truly end-to-end. Not only does AGIE specifyair and ground aspects, but also client-to-client and application-to-application.Another key AGIE goal is to provide mechanisms that allow the operator to managedatalink cost, performance and QoS. AGIE provides operator prioritization and

ARINC PROJECT PAPER 830 – Page 62.0 AGIE PURPOSE AND OBJECTIVESqueuing features to allow optimization of message traffic on datalinks and messagequeue management.The Advanced Message Queuing Protocol Version 1.0 (AMQP) is the transportlayer specified by this standard to leverage an existing industry standard. This givesrise to the additional AGIE goal to take advantage of all the services that AMQPoffers. However, as AMQP is also still early in its maturity cycle, the Specificationmay only make minimal expectations of AMQP features, though this is expected toevolve and further mature over time.2.2 Benefits of AGIE ServicesAGIE is expected to offer numerous significant benefits that can add business valuein many areas and in particular to:Airlines, information service providers, as well as information systemdevelopers by increasing efficiency of information exchange using astandardized, cross-domain, end-to-end service paradigm (AGIE is definedto work across the OEMs, suppliers, and data links).Airlines by increasing efficiency and reducing data transmission costs, aswell as reducing equipment/software development and procurement costs,and allowing use of more standard IT applications development processes.OEMs, equipment, and software system suppliers by providing simpler,standardized access to off-board communication links through predefinedservice interfaces.Data link system suppliers by allowing easier access to the datalinks.Information service providers through standardized and commodity likeaircraft access across airlines, OEMs, and equipment suppliers.AGIE adds business value also by:o Reducing operational ground-side equipment footprint requirements byallowing the number of server installations to be reduced even down to apossible single server environment to host all applicationso Utilizing communication links more efficiently and thus reducingcommunication chargeso Providing airlines a common communications management function inturn simplifying operationso Providing airlines a means of centralizing prioritization of all airline datatraffic to aircrafto Providing standard, more homogeneous secure ground-side interface toaircraft networkso Providing efficient state-of-the-art messaging services for all aircraftdomainso Reducing variability, operational complexity, and implementation costsfor airlines, OEMs, and application developerso Providing in depth security by allowing the separation of the Internetfrom aircraft applications via a secure AGIE networko Reducing overall system complexity allowing fleet-wide deployment ofair-to-ground applications which all use same air-ground communicationsprotocol.

2.0 AGIE PURPOSE AND OBJECTIVESARINC PROJECT PAPER 830 – Page 7A further key added business value results from AGIE supporting highly scalableimplementation topologies ranging from large scale complex to very small simpleimplementations, such as iPad-only EFB clients with no onboard servers.The benefits experienced by incorporating an AGIE based infrastructure increasessubstantially with increase in operator’s air-ground system complexity.On a system level application as AGIE clients benefit from a commoncommunication mechanism across multiple aircraft and implementation topologiesand where AGIE can prioritize data transfers across multiple domains. In thiscontext AGIE significantly reduces development and integration effort and cost forapplication developers.All in all AGIE -simplifies operations for customers even when some or many aircrafthave limited onboard capabilities, e.g. by:1. Ground-side clients being common across the fleet2. Ground-side AGIE leveraging all ground servers and some aircraft3. The same Store-and-forward mechanism also available for ground-groundcommunication4. Receiving all benefits resulting from AGIE’s flexible naming and addressingmechanism5. Receiving all AGIE security architecture benefits6. Reducing on board architecture for AGIE messaging7. Usable with most of onboard applications on mobile devicesThe presence of onboard AGIE servers provides additional benefits as follows:1. The presence of onboard AGIE service functions:a. Avoids the need for each device to be separately addressed andaccessedb. Permits on-board message storage (to/from aircraft)c. Establishes on-board AGIE securityd. Enables on-board AGIE naming servicee. Enables on-board local host services2. Establishing server-server benefits:a. Avoiding Client-server access and association over long distancesb. Enabling dynamic server-server server features, such as store-andforward3. Providing AGIE link efficiency benefits:a. Enabling AGIE prioritization for air-toward-ground communicationb. Enabling AGIE path selection over air-to-ground link with no direct onaircraft path4. Enabling onboard detached functionalitya. Store-and-forward from on-board applicationsb. Addressing/messaging on-board unassociated fixed clients5. Enhanced security in depth:a. One less on-board interface/enclave

ARINC PROJECT PAPER 830 – Page 82.0 AGIE PURPOSE AND OBJECTIVESb. May not support all aircraft domains2.3 ApproachAGIE establishes a communication infrastructure through which any end-systemapplication (aircraft or ground-based) can submit data into the AGIE data networkfor the purpose of having this data being automatically transported and madeavailable for retrieval by the intended recipient end-system (also either aircraft orground-based) application. AGIE performs this function without any of the endsystemapplications requiring knowledge of the actual delivery mechanism.Operationally, this is analogous to a person depositing a letter in a mail box with theexpectation that this letter is subsequently delivered by the postal service to a mailbox from which the addressee will retrieve this letter at some later time.One particularly important and therefore key capability of AGIE is supporting thistype of information transfer between mobile devices. Mobile devices move around inthe AGIE data network and their instantaneous location is not known to the sendingapplication. Such mobile devices behave similarly to smart phones and may attachto the AGIE data network from multiple locations, including onboard and on theground.End-system applications need not have knowledge of how actual data transport isachieved:a. The sending application needs to know the format of data submittal and whatinformation is necessary to assure successful delivery, as well as name/ID ofthe recipientb. The transport mechanism needs to know how to deliver the data to theintended recipient(s)c. AGIE needs to maintain delivery status until delivery is completed. The recipient needs to know how to access the data when availableConsequently, the AGIE definition includes two related yet operationally differenttypes of interfaces:a. The interface specifications which define how end-system applicationssubmit and retrieve data as well as manage, track, and status in-transitmessages and includes: Data exchange services Data encapsulation and content definition Data transport and delivery management Data transport priority management Data transport status tracking and alertingb. The operational infrastructure which implements the actual transport of databetween end-system applications including all related network aspects and:AGIE framework and topology: “typical” system architectures of an AGIEsystemAddressing: standardized locator information for data originators andrecipientsMessage path selection: means to specify data delivery pathsBridging to the IP level: integrating AGIE into the “rest” of the internetworld

2.0 AGIE PURPOSE AND OBJECTIVESARINC PROJECT PAPER 830 – Page 92.3.1 AGIE Data Exchange ServicesOf the interface specifications listed above, the data exchange services may beregarded the most fundamental element of the AGIE definition and thus deservesparticular attention.AGIE defines for data to be exchanged between end-systems/applications to besent as messages. AGIE provides the following delivery methods:1. Point-to-point small messaging2. Point-to-point large messaging3. Point-to-multi-point small messaging4. Point-to-multi-point large messaging5. Publish-subscribe messagingTo achieve maximum flexibility and operational efficiency, AGIE provides for twotypes of message delivery processes:1. Direct delivery from origination to destination2. Indirect delivery: allows intermediate storage of data before final delivery tothe destination2.3.2 Concept of Operations ApproachThe AGIE concept of operations can be viewed from two primary perspectives, i.e.from1. An operations view as systems and functions.2. A user’s view and is best understood as a set of use cases. This areaoutlines the AGIE approach to defining the concept of operations around alist of use cases.2.3.2.1 System OperationsThe approach to defining system functionality to meet the concept of operations isas shown in Figure 1 and can be described as follows:1. Operations are identified as top-level “user” capabilities2. Operations are mapped to operational threads (described in more detail inSection 3.7.6)3. Operational threads are mapped to component functions4. Functions derive requirements and recommended practices5. Interoperation between components becomes AGIE interfacesFigure 1 – Use Cases and Operational Requirements

ARINC PROJECT PAPER 830 – Page 102.0 AGIE PURPOSE AND OBJECTIVESAGIE users initiate and/or terminate operations. From a systems perspective the setof AGIE users is small and each user specific sets of operations are defined: The primary AGIE user is an end system application AGIE automated client and server functions initiate operations Network Management Function (NMF) initiates operations externally to AGIE AGIE Administration or “admin” is an important external user and is a superuserapplicationEach operation is invoked as a processing “thread” by an AGIE user. These threads(described further in Section 3.7.6 and are not to be confused with executingthreads within a computer’s operating system) describe process flow and provideinsight into required functionality and component interfaces. Threads are intended todescribe general information about and control flow between components and majorfunctions and are not intended to provide rigorous data flows or sequence diagrams.Moreover, only major success paths and occasionally common failures aredepicted. In summary, they provide a bridge between functionality, described inSection 4.0, and operations, described in Section 5.0.The list of operations provides a summary of operations each AGIE user/componentcan initiate. Each operation in this list is captured in the detailed operational threadslist. The threads are organized by user (without repeats) and provide a mapping todetailed functional flows. The list of AGIE operations is found in Section 3.7 withdetailed operational threads being provided in APPENDIX B “AGIE OperationalThreads” APPENDIX C “AMQP Thread Mapping and diagrams”.A key element of validating specification requirements and ensuring definedcapabilities meet user needs are use cases. Use cases define proper end-to-endfunctionality, performance expectations, and allow modeling of data flows. Theyprovide concrete examples of anticipated AGIE usage in the real-world. Primary usecases involve user applications, such as electronic software delivery, IFE contentdelivery, and FOQA data download. These are supplemented by infrastructure usecases that facilitate AGIE system operation and management.A list of use cases has been selected to provide an overview of the operationalintent and capabilities of AGIE in use. The detailed use cases provide a mapping ofuse cases with objectives to threads for functional completeness and accuracy.2.3.3 AGIE Development and TestingAGIE is intended to permit implementation via independently developedcomponents and integrated into working implementations by adapting them to thespecific operator implementation. A related prime AGIE goal is to minimize rework ofre-integration of components while maximizing re-use and interoperability. Thisrequires the use of integration, testing, and demonstration environments.Two problem categories result from the complex aviation development andoperational environments.1. Validating end-to-end functionality and performance of message deliveryover realistic onboard and ground architectures.2. Validating interoperability between independently developed messaginginfrastructure components (server end) and independently developedapplications (client end).

2.0 AGIE PURPOSE AND OBJECTIVESARINC PROJECT PAPER 830 – Page 11To facilitate common demonstration and testing respective scenarios and topologiesare found in AGIE Demonstration and Testing paper, see Section 1.4 for reference.2.3.4 InteroperabilityInteroperability is one of AGIE’s primary goals. In order to realize this goal, an AGIEobjective is to allow elements of AGIE implementations developed by independentdevelopers to operate seamlessly in a single AGIE system. Another objective is tofacilitate seamless adaptation and re-use across system implementations.AGIE defines four primary areas of interoperability:1. Interoperability between independently developed AGIE Clients and AGIEServers2. Interoperability between independently developed AGIE Servers and AGIEServers3. Interoperable configuration and management from an administrative point ofview4. Re-usability of components, functions, and subsystems across independentimplementations2.4 Policy and Quality of Service Considerations2.4.1 Priority, Cost and PerformanceAGIE provides features that support operationally defined policies regardingprioritization and QoS management. Further, AGIE provides policy based pathselection using profiles of air-to-ground connections. AGIE allows the operator to setpolicies to manage cost, performance, and datalink usage.2.4.2 Certification and ApprovalOperators need to work with regulators to obtain certification and/or operationalapproval. There are built-in features, many of which offer a range of options,designed to allow tailoring AGIE to meet certification and approval needs. Thesefeatures are controlled by operator policies and include: prioritization, partitioning,visibility limits, network topologies, security features, association mechanisms, andmessage type definitions. The Considerations for AGIE Certification and Approvalpaper (See Section 1.4 for reference) provides more detailed discussion.AGIE is defined to allow operators to modify elements of AGIE without affectingcertification or approval basis for minor changes and updates to configuration andsecurity parameters. For example, the operators may add new clients-applicationassociations without affecting system’s operational approval. AGIE specifies thatserver associations are always initiated by the onboard equipment, never by theground. Moreover, Operators are strongly encouraged to utilize AGIE security andpartitioning features.2.5 Security AspectsSome of the key policies managed by the operator with regard to AGIE are itsinformation security policies. This section addresses the approach taken for thesecurity related aspects of AGIE.2.5.1 Security GoalsAGIE’s goal is to perform secure and reliable communications for applications inmultiple aviation domains communicating over shared data links and networks.

ARINC PROJECT PAPER 830 – Page 122.0 AGIE PURPOSE AND OBJECTIVESThese domains as defined in ARINC 664 include ACD, AISD and PIESD domains.The key to efficient operations is a single system (possibly partitioned) that sharesnetwork, computing and messaging resources while meeting privacy, security,certification/approval, and safety requirements. AGIE not only supports crossdomainmessaging, but also supports certified FAR Part 25 and operationallyapproved systems, data, and datalinks.2.5.2 Security ObjectivesAGIE’s approach allows flexible selection of features to meet the particularrequirements of the implementation, which may support a range of security,certification, and operating parameters. AGIE leverages security functions present inother layers and devices of the overall information systems environment. While thissection focuses on security, other aspects of security are functionally integrated intoother sections of this document where possible and appropriate.The overall approach taken for AGIE is to leverage existing standards and bestpractices to the maximum extent possible and/or practical while limiting theintroduction of new AGIE-unique security features. In particular, AGIE leverages tothe IETF Transport Layer Security (TLS) standard, ARINC 842 Standard and ATASpecification 42 as well as the security features that integral part of protocolschosen to be part of AGIE, e.g. TLS within AMQP.Actual AGIE security requirements are defined in Section 4.7.2.5.3 Security GuidanceAGIE security guidance is focused on functional requirements of the messaginglayer of the standard. Specific AGIE security guidance addresses: AGIE functions Interfaces to external systems AGIE administrative operationsAGIE security guidance specifically addresses user needs for protecting aviationdata including:1. Integrity (primary need):a. Protect messages from being tampered with at endpoints as well as intransitb. Prevent spoofed or unauthorized messages being injected into thesystemc. Authenticate and correctly authorize AGIE servers and clients to eachother2. Confidentiality:a. Prevent messages from being read or intercepted at rest or in transit3. Availabilitya. Minimize impact to timely message delivery resulting from attacks onAGIE system4. Monitoringa. AGIE system generates sufficient logging data for security monitoringpurposes, e.g., detection of bogus messages

2.0 AGIE PURPOSE AND OBJECTIVESAGIE security guidance intentionally does not specify:Airline IT security practicesPhysical securityARINC PROJECT PAPER 830 – Page 13Security functions for other layers of the IT system, e.g., end-to-end securityneeds of the applications2.5.4 Security AssumptionsSystem security specifications related to AGIE are not adequate by themselves andneed to be integrated with an organization’s overall security risk managementprocess.Applications and/or data requiring additional protections for sensitive user data areresponsible for protecting it end-to-end (application-to-application).AGIE operators and service providers need to design and operate their IT systemsand networks according to industry best practices for security. Requirements andguidance are defined in Section 4.7 and Section 5.6.

ARINC PROJECT PAPER 830 – Page 143.0 AGIE OVERVIEW3.0 AGIE OVERVIEWThis section provides an overview of AGIE. The objective is to provide an outsidereader with a user’s level perspective of AGIE and its capabilities and intendeduses.3.1 General DescriptionThe AGIE specification defines a client-server based message broker system wherededicated AGIE nodes act as brokers that manage data exchange between endsystem applications. This is shown in Figure 2. Such AGIE nodes are referred to asAGIE “Servers.”AGIE uses a flexible addressing scheme to meet the requirements and operationalneeds for data transport in the aerospace and aviation environment.End system applications interface with these servers via dedicated AGIE “Client”software components through a dedicated Application Program Interface (API) forthe purpose of submitting data for transfer to and retrieving from other end systemapplications. A single client software instance may support multiple end-systemapplications.To enable a functional interaction between AGIE clients and servers, the client issaid to “associate” with an AGIE server at which point this server becomes thatclient’s “host”. Once a client has associated with a server, AGIE data exchangebetween that client and other end system applications occurs through this hostserver. A client can un-associate and re-associate with a different server at anytime, which can be often in the case of mobile applications.COMMENTARYThe term “association” should not be mistaken with the term “connection,”which takes place on network level prior to the association on the AGIElevel. Network level connection management takes place outside of AGIE.Message originating clients submit data for delivery to their host and the receivingclients in turn obtain the data from their respective AGIE hosts. AGIE data isexchanged via XM document between applications, clients and servers. Submitteddata may be contained directly in the XML document or through attachments.As illustrated in Figure 2the AGIE architecture consists of two primary groups ofcomponents: aircraft and ground based. Typically all data transfers between theground and aircraft occurs between two AGIE servers. However, the AGIE standarddoes allow association of an aircraft client with a ground based server, thus air-togroundas client-server.AGIE specifies the use of Advanced Messaging Queuing Protocol (AMQP) as thewire-level protocol that performs the actual underlying message transport, queuing,and tracking.AGIE servers are defined in two layers. The upper layer is the “AGIE service layer”and performs AGIE specific functions which map AGIE services to functions,manage coordination messages, and interface with AMQP. The lower layer is the“AMQP layer” and is referred to as the “AMQP broker”. A similar architecture appliesfor the AGIE client, where there is an “AGIE service layer” and an AMQP client.Messages originate from an end user application and are sent to another end userapplication. The XML document is forwarded with defined header parameters to theAGIE client. The AGIE client processes the XML message request and forwards awell formed message via the client’s AMQP layer to the AMQP broker of its AGIE

ARINC PROJECT PAPER 830 – Page 153.0 AGIE OVERVIEWhost server. The AMQP broker passes the message up to the AGIE host’s servicelayer for processing. The AGIE host obtains addressing and path data and passesan updated and well-formed coordination message to its AMQP broker. The AMQPbroker performs a broker-broker transfer to the destination client’s AGIE server,where the reverse process is followed. The destination application receives a wellformed XML message.Any available IP supported communication link technology may be employed totransfer data between two AGIE servers. As such, this exchange may be managedby the IP router on the aircraft. AGIE is an application (Layer 7) layer service,consisting of a set of interfaces and functions. This standard does not define anynetwork or lower layer functionality.Depending on the air-ground communication links and flight profile, a connectionwith ground systems may not be always available. AGIE provides for this situationby supporting dynamic associations for aircraft nodes. An important aspect of AGIEis that an application need not be aware (though it may be) of:The type of aircraft/ground communication link that may be usedWhether the destination client is reachable at the time of messageorigination Whether an aircraft/ground communication is active at the time a datatransfer is initiatedAn AGIE client is a software program that is configured to communicate via theAGIE services to send and receive messages for end-system applications. Anyapplication may be an AGIE client. An AGIE client may support more than oneapplication.AGIE clients support applications hosted on an aircraft or on the ground. Groundclients may be inside the operator’s managed network or connected to it through anexternal firewall. While typically data exchange occurs between aircraft based andground-based applications, this is not a requirement. An aircraft resident AGIE clientmay also exchange messages with AGIE clients on the same aircraft and likewiseground-based AGIE clients can exchange messages with other ground-based AGIEclients.

ARINC PROJECT PAPER 830 – Page 163.0 AGIE OVERVIEWFigure 2 – Conceptual AGIE System Overview3.2 AGIE TerminologyThis standard introduces a number of new AGIE specific terms and uses others torepresent specific and possibly non-typical meanings. A comprehensive list of AGIEspecific terms is found in the Glossary Appendix. A few key such terms, however,are listed here to make reading the document easier:Architectural Definitions:AGIE client: application level software that implements the functionalinterface with AGIE servers and applicationsAGIE server: application level software the implements as a messageserver functionAGIE node: either AGIE client or AGIE server softwareAssociation: joining of two AGIE nodes that enables operational data trafficflow

ARINC PROJECT PAPER 830 – Page 173.0 AGIE OVERVIEWConnection: network level path or route between two AGIE serversLink: physical communication establishment provided by Datalink ServiceProvider (DSP)Path: a connection between two AGIE servers with a valid IP routeHost: a server with which a client is associated is said to be this client’s“host” serverMessage Related Definitions:Message Type: common message format with templateMessage Service: AGIE services for sending messagesMessage topic: logical category of message based on content type (usedfor publish-subscribe) Message Class: defines payload type or coordination type message3.3 Architecture and TopologiesAGIE’s client-server architecture contains AGIE and non-AGIE components.Functionality is defined as well as the operational aspects. AGIE componentsinclude AGIE clients and AGIE servers. AGIE servers include client hosts andinfrastructure servers. Client and server functionality is clearly defined. This is thebasis for AGIE’s end-to-end architecture.AGIE also defines a layered, service oriented architecture. The layered architecturedefines application and service interfaces, underlying infrastructure services andfunctionality, as well as transport layer. The transport layer architecture is based onAMQP.Some necessary capabilities are actually provided by non-AGIE functions. AGIE’sarchitecture defines those external functions (with expectations) and the interfacesto them. External functions include the network, network manager, data links, and ITsecurity.Each AGIE and AMQP component communicates with its adjacent componenteither horizontally (like AMQP broker to broker) or vertically (like AGIE client toAMQP client). These component interfaces are functional. AGIE components (orfunctions) also communicate with non-adjacent components (or functions) at thesame layer in the protocol stack for peer level communications. These interfaces aredefined as AGIE coordination messages.AGIE coordination messages are used for configuration management, messaging,security, as well as monitoring and control. Required messages are defined inSection 6.AGIE supports a range of topologies. This is necessary to handle the variety ofairline and industry arrangements between air-and-ground. The AGIE Topologiespaper (referenced in section 1.4) describes a representative range of topologies tostimulate thinking, ensure valid requirements, and foster effective implementation.However, it is not the intent of this document nor is it practical to define all possibletopologies.AGIE supports the concept of isolated AGIE networks within an AGIE systemimplementation. Isolated AGIE networks are sub-networks of AGIE nodes,separated by operator configured visibility limits. This allows system level domain

ARINC PROJECT PAPER 830 – Page 183.0 AGIE OVERVIEWseparation. Isolated AGIE networks are not the same as detached AGIE networks.Detached AGIE networks are AGIE sub-networks on aircraft that do not haveaccess to the Main AGIE network at the time. They become re-attached whenconnectivity between them is restored and they are able to reach the Main AGIEnetwork.3.4 AGIE Administration ConceptsOperation of an AGIE system implementation is fully in the control of the operatorand is managed via the “admin” role. This is due to the fact that AGIE is primarily adata driven system. While AGIE functions transfer data and messages, operationalfeatures, management, control, security, and performance are driven by policies setby administrators and the information contained in distributed configurationdatabases. Distributed databases contain all of AGIE’s configuration data. AGIEadministration builds, loads, and distributes these databases.COMMENTARYThe term database as used here is a descriptor for a file that holdsconfiguration information. It does not imply a complex data structure or set ofinformation services.Operator administrators manage AGIE system configuration. System configurationis built outside of AGIE. System configurations are input into the AGIE system via acentralized server access and control point, called a “Primary Server” and itsadministrator’s client interface. When a configuration update is received from thisclient, the Primary server pushes or notifies all the nodes within the system of thenew configuration. AGIE administration services provide the capability toautomatically synchronize configuration updates by database exchanges. AGIEdatabases may be updated wholly or by sending only updates.Additional Administrator responsibilities include:Managing client and server lists. All clients are known to the Primary server(and onboard Primary).Setting bounds of client-server associations, which involves configuringclients to address potential AGIE hosts via IP DNS or hard coding addressesfor association.Defining an AGIE Name Server topology for dynamically exchanginginformation regarding client addressing at any given time. Performing AGIE system configuration and IT functions as well as dailyoperations and performance management functions.While operational administration is not part of AGIE scope, AGIE providesrespective administrative interfaces and services to allow the administrator toconfigure and manage an AGIE system. This is accomplished through built-inAdministrative and Log clients as well as related functions on Primary. AGIEAdministration operations are ground-based functions managing the ground-side ofAGIE using airline IT processes and the onboard elements using remote AGIEadmin access.COMMENTARYThe aircraft maintenance functions and processes are entirely outside theAGIE scope.

ARINC PROJECT PAPER 830 – Page 193.0 AGIE OVERVIEW3.5 AGIE Messaging OperationsPrincipal AGIE operations provide application-to-application messaging services.3.5.1 Small Message Point-to-Point ServiceThis AGIE data exchange service addresses the need to exchange informationbetween end-system applications where the data is sufficiently small enough to bedelivered as a single data transfer.The message originator may be any AGIE client and may send a message to anyother AGIE client. An aircraft application may send a message to a ground-basedapplication, or application on another aircraft, or an application on the same aircraft.A ground based application may send a message to an aircraft based application oranother ground-based application.Messages may be sent at any time with near-real time message delivery notguaranteed. Return requests may be included in the original message, in whichcase the message originator will receive explicit notification of delivery or failure.3.5.2 Large Message Point-to-Point ServiceThis AGIE data exchange service addresses the need to transfer data between endsystemapplications when the data is too large to be sent in a single data transfer.The message originator may be any AGIE client and may send a message to anyother AGIE client, just as for small point-to-point service.Messages may be sent at any time and with near-real time message delivery notexpected, the file will be broken into smaller fragments for efficient transmission.Return request may be included in original message, in which case the messageoriginator will receive explicit notification of delivery or failure.3.5.3 Small Message Point-to-Multi-Point ServiceThis AGIE data exchange service addresses the need for (typically ground-based)applications to reliably multi-cast information to more than one destination, wherethe data is sufficiently small in size to be delivered in a single data transfer. Themessage originator is typically a ground-based application, though aircraft clientsmay also use the service and the recipient may be any combination of aircraft orground based applicationsMessages may be sent at any time and with near-real time message delivery notguaranteed. This point-to-multi-point type of delivery does not support automaticmessage acknowledgement, but allows the sender to obtain a list of successfuldeliveries upon request.3.5.4 Large Message Point-to-Multi-Point ServiceThis AGIE data exchange service addresses the need for an application (typicallyon the ground) to transfer large data items that cannot be delivered in a single datatransfer to multiple (typically aircraft based) applications in a reliable multi-cast typemanner, although the recipients may also be ground-based applications. Themessage originator is typically a ground-based application, though that is notrequired, and the recipients may be any combination of aircraft or ground-basedapplications.Messages may be sent at any time and with near-real time message delivery notexpected. Messages may be sent as background messages with long delivery time

ARINC PROJECT PAPER 830 – Page 203.0 AGIE OVERVIEWok, and a very low priority and cost basis. This type of delivery does not supportautomated message acknowledgement, but allows the sender to obtain a list ofsuccessful deliveries upon request.3.5.5 Publish-Subscribe Message ServiceThis AGIE data exchange service addresses the capability for an application topublish data under a topic name that is intended to be delivered to applicationssubscribing to the topic. The originator sends the message to the Publish-Subscribeservice with the specified message topic. The server in turn notifies subscribingapplications that a new message has been “published” to that topic.The originators of messages being distributed on a Publish-Subscribe basis aretypically ground-based applications and the recipients may be any combination ofaircraft or ground based applications. Publish-Subscribe messages are addressedto the ground based (on logically a function on Primary) Publish-Subscribe function(client).Messages may be sent at any time and with near-real time message delivery notexpected. There is no specific acknowledgement of message delivery forpublish/subscribe type message distribution. The originator may obtain a list ofsuccessful deliveries upon request.3.6 AGIE Principles of OperationThis standard defines protocols and functionality for exchange of data between endsystems/applications. End system software applications implement AGIE clientinterfaces. Clients associate with AGIE servers or hosts. Typically, Aircraft based(onboard) clients associate themselves with an aircraft resident server while nonaircraftbased clients associate with ground-based. Onboard clients are notprecluded from associating with ground-based servers. However, ground-basedclients cannot associate with an onboard server at any time. Onboard serversassociate with ground servers by connecting over active communication links whichcome and go over time. Association is based on establishing a connection or newlyjoining client.COMMENTARYAssociation does not constitute network level authentication, only functionalconnection establishment.“Fixed” clients can only associate with a designated server and only associateoccasionally, e.g., in the event of an aircraft power up sequence. An example is anairborne data loader, which is permanently installed in the aircraft that also hosts anonboard AGIE server. “Mobile” clients on the other hand are not permanentlyassigned to the same server, e.g., an EFB which is removed from the cockpit afterflight and later re-associates on a different aircraft, on the ground from flightoperations, or a hotel room via a ground-based server.3.6.1 AGIE Organization OverviewAGIE defines a message brokering system where dedicated AGIE servers managethe data exchanges and end system applications associate, as AGIE clients, with anAGIE “host” server for the purpose of submitting and receiving data from other AGIEclients and end system applications.AGIE nodes communicate with each other via AGIE addressing mechanisms. Theseare defined in Section 4.5. To allow flexible addressing of AGIE nodes, especiallyAGIE clients, an AGIE system is a closed system, where “closed” is defined as:

ARINC PROJECT PAPER 830 – Page 213.0 AGIE OVERVIEW1. The set of all clients and servers is known at all times to the Primary Serverand admin.2. The network topology between all AGIE servers is static, i.e., all nodes arepre-defined, fixed connectivity is known, and the limits on dynamicassociations and connections are bounded.COMMENTARYThe term “Primary” or “Primary Server” is a logical definition which may beimplemented as a single physical server or multiple federated servers.In this closed system the relationship between all servers is static in the sense thatall servers are known, all fixed connections are known, and dynamic connectionsare bounded. Association of clients to hosts is dynamic, such that any client canassociate or un-associate with any server (as bounded by system administration) atany time. To assure full addressing capability is maintained, hosts make all newassociations visible to the AGIE Name Service (ANS) and thus to all other nodes inthe system as described in Section 4.5.All clients are uniquely identifiable within the system. In the event more than oneinstantiation of a Client ID attempts to associate with a server, they are providedwith unique identifications or denied association. Typical examples are EFBs orcredit card authorization devices. See Section 4.5.It is necessary to amend the static system configuration from time to time. Suchchanges require a managed effort controlled by authorized system administrators.They are globally visible across the system. AGIE defines configuration controlmethods and messages for this purpose in Section 6.0.Part of the AGIE definition includes limitations of which clients other clients areallowed to see. This is accomplished by administrators setting a “visible client list”for each client and setting client visibility policies.AGIE provides for managing global system configuration and distributing thisinformation to all system nodes. For simplicity, the AGIE standard assumes thisinformation is centrally managed on the ground-based Primary knowledge store(Primary), which also hosts the root level AGIE Name Server.AGIE nodes may inquire about the status of other nodes. AGIE servers may alsorequest the status of AGIE databases from Primary server at any time. Whereredundant, distributed ANS is used, they are kept synchronized. In the case wheremore than one server exists on an aircraft, one of these servers is defined as thelocal primary. All AGIE servers know how to reach an ANS and other Primaryfunctions. ANS provides the translation of AGIE node identifiers to addresses andprovides path quality information.3.6.2 Connection ManagementAGIE is an application level (Layer 7) service. All AGIE connections are logicalconnections and not physical communication links and for that reason one AGIEentity is said to be “associated” with another AGIE entity on an application level.Within AGIE two types of connections exist. First are connections between clientsand servers; second are connections between two AGIE servers. The initiation ofconnection establishment is subject to the following rules/conventions which arestrictly adhered to:

ARINC PROJECT PAPER 830 – Page 223.0 AGIE OVERVIEW1. A client always initiates an association with a server (client-serverassociation).2. An onboard server always initiates an association with a ground-basedserver. A ground-based server cannot initiate an association with an aircraftbased server (server-server association).3. Ground server-server associations are static within AGIE (setting up,establishing, modifying ground connectivity is not within AGIE scope).4. Connection establishment between two onboard servers requires the non-Primary servers to initiate the association.5. A ground-based client only associates with a ground-based server (never anaircraft based server).Association indicates to each party that the ability to exchange information has beenestablished. The actual physical link exists outside the AGIE framework at a lowerlayer and is managed by the underlying components employed for actual transportof AGIE messages. This is described further in Section 4.3.The “association” process involves the exchange of specific coordination messagesbetween two AGIE nodes. Within AGIE association and the exchange of suchmessages is the only mechanism through which AGIE entities are allowed toconnect to the AGIE system. Association includes updating the ANS andpropagating the new client status and access information throughout the AGIEsystem.AGIE interfaces to network management functions that provide notification andstatus of connectivity changes and other connectivity information used by a specificimplementation.The creation of an AGIE connection, and subsequent association, is automatic anddoes not involve any human action. It is externally triggered by networkmanagement. However, in the event a connection is interrupted, the party whichnormally initiates the connection may re-initiate the connection. AGIE does notrequire explicit un-association, though this is provided to allow efficient resourcemanagement.3.6.3 Protocol BindingAlthough AGIE is a Layer 7 protocol, the standard stipulates the use the AdvancedMessage Queuing Protocol (AMQP) through which binding of the application’s XMLmessage documents to a data transport protocol is achieved for both client-serverand server-server communication. Details of protocol binding are found in Section6.0 for AGIE client-to-AMQP client and AGIE server-to-AMQP broker bindings andinterfaces. Functional mapping to AMQP is found in Section 4.6.3.6.4 AGIE AddressingOne of the main AGIE challenges is accommodating the need to dynamicallydetermine how AGIE clients can be reached at any given time. Aircraft with onboardAGIE servers move around the network and mobile devices come and go as well asmove around the network. Fixed aircraft equipment is regularly removed from oneaircraft and installed on a different aircraft. An example of this is an Electronic FlightBag (EFB) that is ported from aircraft to ground networks, e.g., hotels, and again toanother aircraft.The AGIE standard addresses this need by allowing applications to address otherapplications by client name and application ID without knowing the actual physical

ARINC PROJECT PAPER 830 – Page 233.0 AGIE OVERVIEWor IP address of the destination, see Section 4.5. AGIE centrally maintainsdatabases containing the following information for the entire AGIE system:1. List of all defined AGIE clients2. List of all defined AGIE servers3. List of current associations between clients and servers4. List of current connections (paths) between servers.To assure that all AGIE nodes have access to this data, AGIE uses a ground basedsystem to host Primary functions including AGIE name services and hosting allcoordination databases.Every client has a ground-based “Home” server. All air-ground and ground-groundexchanges are routed through the client’s home to the final destination. While thisindirection adds latency, it reduces complexity and overhead and there is still only asingle air-ground exchange.It is, however, not efficient for client-to-client data exchange within the same aircraftto require routing messages through the Home server. Therefore, an onboard AGIEserver acts as a “local Primary” server and supports direct onboard routing. It alsoacts as a local “Temporary Client Home” server when there is no access to theground-based client’s Home, providing store-and-forward capabilities todisconnected AGIE sub-networks. AGIE naming and addressing is further defined inSection 4.5.3.6.5 AGIE Data Delivery ManagementAGIE implements “store and forward” and “direct delivery” methods. All end-systemmessages are sent strictly from one client to another client with no exception.Internally, AGIE sends data to specific servers or functions, but clients are not setup or even allowed to do this. To initiate a transfer of data to a destination client, theoriginator client sends an XML document as a message to its host using a messageservice interface. The host processes the message and forwards it to the destination(or home). It may be necessary to locally store the information along the way until itreaches the destination, see Section 4.6.AGIE defines two end message servers. An “Origination server” receives themessage from its client. A “Destination server” delivers the message to thedestination client. While actual data paths may consist of multiple physical “hops,”only the origination and the destination servers are of relevance to the end clientsfor an AGIE data transfer. Both servers may be the same AGIE server.Data transfer between those two servers is managed via standard IP protocol usingAMQP in conjunction with any other aircraft/ground link IP routing service (e.g.,MAGIC).AGIE defines two principal classes of messages.User messages used to transfer end-system application related databetween AGIE clients.Coordination messages used to communicate any internal systemmanagement related information such as notifications, status enquires,connection coordination etc.Each message includes a unique identifier which is a combination of the senderidentifier plus an integer number, unique to the server, from which the message

ARINC PROJECT PAPER 830 – Page 243.0 AGIE OVERVIEWoriginates. The delivery of data takes either of two forms depending on the messagetype, class and message service used.1. The server notifies the client of the data and the client subsequently requeststhe data to be “pulled” to the client.2. The server can also “push” the data directly to a client when a connection isestablished without prior explicit notification.AGIE defines the capability to send data to multiple destinations via direct naming orvia publish-subscribe methods. The exchange of data via AGIE is completelysymmetrical, i.e., the same services apply for aircraft to ground as wells as forground to aircraft messaging.3.6.6 PrioritizationAGIE provides for prioritization and preemption to facilitate needed performance,cost management, and manage link usage. Prioritization is an important construct insupporting cross-domain services. Prioritization includes messaging, datalink,queuing, and processing. The admin sets AGIE priorities.AGIE prioritizes messages based on message type, client attributes, and messageservice used. A sender requests the message’s priority. The admin pre-determinesprioritization policies. AGIE accepts the sender’s request and maps it to the adminset policies.Prioritization affects AGIE processing and underlying network IP services.Prioritization supports a range of options from background to immediate messaging.One aspect of prioritization is preemption, which is AGIE’s ability to re-orderprocessing based on a later arriving higher priority message or task.Within AGIE, two levels of fixed data priority are defined, “NORMAL” and“URGENT.” The vast majority of traffic is expected to be managed as NORMALtraffic. As a rule, all data are strictly queued and acted on a First-In First-Out (FIFO)basis irrespective of their origin and/or destinations. Priorities are applied to serverfunctions, processing queues and communication paths/ports. With respect tonormal vs. urgent messages, the following general rules apply: Urgent messages take precedence over normal messages Newly appearing urgent messages generally are placed ahead of the queue Urgent messages are queued in FIFO order with respect to each other Small urgent messages can suspend the processing of normal messages Some level of fair-weighted queuing also existsThe AGIE standard does not stipulate prioritization implementation details, such ashow many queues a particular server needs to maintain. It does provideprioritization expectations and guidance, explained in Section 4.4. Also, eachmessage service has a default priority associated with it. The default may beoverridden by message request and/or admin control. “NORMAL” is the defaultpriority attribute value for all transactions. A “user priority” is defined in the messagefield and allows the implementation to provide more fidelity in handling priorities insophisticated implementations. Also, AGIE provides a priority mapping interface tothe underlying IP network.3.6.7 Application Message ManagementAGIE applications use built-in services to manage messages that are in-transit to afinal destination. The AGIE data delivery framework includes methods of managing

ARINC PROJECT PAPER 830 – Page 253.0 AGIE OVERVIEWdata flow that includes status tracking and enquiry, automated reporting, logging,delivery time management, and message deletion.AGIE provides applications and administrators with the ability to determine whatlevel of message delivery status and reporting is required on a per message basis.This can be defined for each message instance, for each message type and/or foreach service invoked. Reporting may be automated or by a later request. AGIEensures the reports and status are delivered to the originating client, whether or notit has changed hosts or is off-line when report is generated.AGIE provides built-in automated and on-demand logging features. There areaviation requirements relative to the logging of data sent to the aircraft. Loggingfunctionality is defined to facilitate efficient logging and to allow tailoring tooperational needs. Log function is required as it supports highly important functions,such as capturing security events.AGIE tracks the status of a message from origination until successful delivery, nondelivery,or timeout. A sending client can enquire about the status of a message atany time while the message is in transit via the defined message service interface.AGIE ensures transaction history is maintained. The retention period is based onregulatory and/or operational considerations and is not defined by AGIE. It is a goalfor onboard transactions and event logging to be minimized, and where possible,handled on the ground. Also, when possible, aircraft logged events areautomatically transferred to ground for permanent logging.3.7 List of OperationsThe AGIE concept of operations defines users and operations for each user. Thissection lists user operations specific to the type of user.3.7.1 Application OperationsThe following operations are initiated by end user applications via the AGIE clientinterface.1. Send message using message service (considered to be a complexoperation)2. Pull messages from AGIE server3. Manage (control/status) in transit message4. Request AGIE node/network status (ping)5. Log event6. Manage publication subscription3.7.2 Client OperationsThe following operations are initiated by AGIE client on behalf of the applications orAGIE system via client-host interface.1. Associate with AGIE host server2. Un-associate with host server3. Log event3.7.3 AGIE Server OperationsThe following operations are initiated by AGIE server via server-host and serverserverinterfaces.

ARINC PROJECT PAPER 830 – Page 263.0 AGIE OVERVIEW1. AGIE node/network status response2. Process expired messages3. Database synchronization (push/notify)4. Associate with dynamic sever5. Pull database update6. Un-associate with client7. Get AGIE node address/status (ping)8. Log event3.7.4 Network Management Function (NMF) OperationsThe following operations are initiated by non-AGIE NMF.1. Manage connection to server (add or remove).3.7.5 AGIE Administrator OperationsThe following operations are initiated by AGIE Admin functions.1. Manage and distribute AGIE databases on Primary.3.7.6 Operational Thread IndexEach operation is invoked as a processing thread by an AGIE user. Threads in theAGIE context describe process flow and provide insight into required functionalityand component interfaces.The threads are intended to provide general flow between components and betweenmajor functions. Threads are not literal source codes or rigorous flows and onlydepict major success paths and occasionally simple failures. Threads flow from userinvocation until success or failure. Unlike software data flows, they simply pauseand continue when interrupted or waiting for inputs to continue.Listed below is the thread index for all AGIE user operations. Details of the threadsare found in 107105 AMQP Thread Mapping and diagrams. Gray entries areduplicates.1. Applicationa. Send messageb. Pull message to hostc. Manage messaged. AGIE pinge. Log eventf. Manage subscription2. Clienta. Associateb. Un-associatec. Log event (App#5)3. Servera. AGIE ping responseb. Process expired messagec. Un-associate – (Client#2)d. Ping – (App#4)

ARINC PROJECT PAPER 830 – Page 273.0 AGIE OVERVIEWe. Log event (App#5)f. Send coordination message – (App#1)g. Pull coordination message – (App#2)4. NMFa. Manage connection5. Admin

ARINC PROJECT PAPER 830 – Page 284.0 AGIE FUNCTIONAL SPECIFICATION4.0 AGIE FUNCTIONAL SPECIFICATIONThis section defines the AGIE system and components on a functional level withoutgetting into the operational aspects and protocol interfaces which are addressed inlater sections. This section addresses the principles of operations, architecture,technical functionality, message transmission, and delivery, naming, andaddressing, mapping to AMQP and security. All requirements defined for AGIEfunctionality are captured in this section. They are stated as “AGIE shall” or “AGIEfunction shall.”AGIE shall meet the intent of all functionality defined in Section 4 and described inAppendix B, AGIE Operational Threads, unless it is otherwise stated as a nonrequirement,objective or goal.4.1 Top-Level CapabilitiesAny AGIE standard compliant implementation shall exhibit the functional behaviorcharacterized via the following top level or system requirements:1. Implement an application-to-application messaging service through whichaircraft hosted applications can achieve reliable bi-directional informationexchanges with applications hosted on ground using IP protocols over IPenabled communication links.2. Support application-to-application data exchanges within the same aircraft,between air-and-ground, and between ground-based applications.3. Provide a messaging data exchange paradigm (as opposed to streaming),implementing the minimum set of functions defined in Section 4 of thisstandard.4. Provide the minimum set of interfaces and coordination messages defined inSection 6.0.5. Provide messaging services including “store and forward,” “push and pull,”“publish and subscribe,” “one-to-one,” and “one-to-many” messaging fortransferring data. Implement the minimum message services defined inSection 4.4.6. Allow the initiation of data transfers without requiring an activecommunication link between the applications using store-and-forwardtechniques as defined in Section 4.6.7. Not require end-system applications to be cognizant of the type and status ofaircraft/ground communications link used for aircraft/ground communication.8. Provide policy mechanisms that allow the operator to manage messagedelivery and routing by implementing the minimum admin functions definedin Sections 4.0 and 5.0.9. Include means for actively managing delivery of messages as defined inSection 4.4.10. Permit exchange of any type of message oriented data, e.g., binary, ASCII,Unicode.11. Provide means to prioritize data transport as defined in Section 4.4.12. Include a universal addressing mechanism through which all AGIE nodescan be reached as defined in Section 4.5.13. Provide features to allow implementing a secure data path between theorigination and destination clients/functions by implementing the securityrequirements defined in Section 4.7.

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 294.2 ArchitectureThe AGIE based communication system is composed of a network of AGIE Clientinstantiations through which end-system (software) applications interface with thesystem and a network of AGIE server instantiations that manage the actualinformation exchange across the system. The functions of an AGIE client aredescribed below. The functions of AGIE servers are considerably more complex andare described in Section 4.6. Architecture describes AGIE nodes, both clients andservers, and their relationships defined by node definitions and end-to-end topologyconsiderations.COMMENTARYMessage implies “message push” or “message notifications.”COMMENTARYThe terms AGIE protocols and AGIE interfaces are used throughout thisdocument. AGIE protocols refer functional interfaces between AGIEcomponents. These are primarily related to AMQP. AGIE interfaces are peerlevel inter-function communications using AGIE messages which areconsumed by AGIE functions. AGIE interface semantics are defined inSection 6. AGIE interface syntax is defined in Appendix D.4.2.1 AGIE ClientsThe AGIE client is an AGIE node that interacts between an end user application andan AGIE host server. The client provides AGIE services to the applications. Itinterfaces between applications and its host.COMMENTARYThe term “application” as used throughout the document usually means anexternal software based AGIE user. However, most often is can also be readas “AGIE function” or “function”, as AGIE infrastructure functions behave likeuser applications in regards to AGIE messaging. They however, oftenprovide their inputs directly in well formed and compressed formats and havespecial security handling provisionsThe client-application interfaces are defined as XML documents over an undefinedphysical interface via AMQP client layer. Physically, clients and applications maycommunicate via any method, such as inter-process communication (i.e., sockets),by function calls within software programs, or over LAN or IP networks. This is left toimplementation.AGIE defines a service layer application-client interface. This interface operates viaservice request on message originator side and via message notification/push onthe receiver side and may use application-to-application addressing via applicationIDs.Clients perform fragmentation and re-assembly of large data. A size limit for datatransfer is defined within a particular AGIE system implementation. Should a datafile be larger than this size, then the client fragments the file into smaller messages.This ensures the AMQP data transfers and internal memory constraints are notoverloaded. The destination client re-assembles the message fragments into a finalmessage for delivery. This requires care in implementation to minimize data lossand efficiency, where either the client has persistent storage or is highly available.

ARINC PROJECT PAPER 830 – Page 304.0 AGIE FUNCTIONAL SPECIFICATIONWhile the service interface between the application and client is defined as XML,large data items may be either directly embedded within an XML document orattached via a link provided in the message header, allowing the client to obtain thedata in an efficient manner. This data transfer process itself is not defined in thisstandard.The client interfaces with host server by predefined XML messages. AGIE does notpermit “out-of-band” communication i.e. all client-server and server-server servicelayer interfaces are via XML defined messages and all data transfers are via AMQP,although large file transport may be performed using non-AMQP definedmechanisms consistent with the provisions of AMQP as defined in Section4.6.4These interfaces and coordination messages are listed below and defined inSection 6.The client functional scope includes several standalone (client initiated) services aswell as proxy services on behalf of the application. The client performs the followingfunctions on behalf of the application by forwarding and processing the defined XMLservice request. In particular an AGIE client shall perform the following services.1. Send using message service (complex)2. Pull from AGIE server3. Manage (control/status) in transit4. Request AGIE node/network status (ping)5. Log event6. Manage publication subscriptionAGIE client shall provide these services.1. Associate with AGIE host server2. Un-associate with host server3. Log event4. Provide access to the AGIE name serviceFrom the AGIE specification point of view a client is a logical entity and may beintegral with application code or may be separate software service in/on operatingsystem supporting multiple applications on a single, addressable IP device. It maybe remote via IP or Ethernet or other LAN access. However, a client is always singleIP addressable.The following association requirements apply to AGIE clients:AGIE clients may be allowed to associate with multiple hosts, but AGIEclients shall be associated with ONLY a single host at any given time.AGIE ground clients shall only be allowed to associate with a ground server.Onboard AGIE clients shall only be allowed associate with an onboardserver.Mobile clients may associate with any client.All AGIE clients shall be allowed to ONLY associate with clients listed intheir allowed visibility as defined by the adminClients are NOT required to have persistent storage, so any time a client unassociateswith a server, or reboots, or restarts for any reason, all in-transit data isassumed lost. This allows every restart to begin in a known. All re-associationssynchronize database configuration and resend non-delivered messages. A client

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 31with persistent store should provide status of message segments already receivedand being held to minimize resending of large data.AGIE clients shall be designed to support multiple simultaneous applications via amulti-threaded interface. While It is not actually required for implementers on theapplication side to implement the multi-threaded interface, the AGIE client shallnonetheless provide such an interface if it is implemented. This allows multiplesimultaneous message transfers and service requests. It also provides built-inapplication name/ID addressing to support application mapping of incomingmessages via meta-data parameter (Application ID). The application ID provides ameta-data tag for use by end system application’s message routing function for easydetermination of the appropriate destination application. AGIE does not process theApplication ID other than to parse it, put it in the message, and pass it on to theapplication interface.COMMENTARYWhile it is assumed that the client and application interface is local, it ispossible that a client and its application may be separated by a datalink ormultiple Internet links.To avoid messages from being blocked by another higher priority message theAGIE client shall provide the following communication capabilities:1. The application-to-client interface operates at a performance level thatallows multiple applications to submit message requests to clients such thatno large, low priority message will block a later arriving small, high priorityone.2. The client-to-application interface operates at a performance level thatallows multiple applications to receive messages from clients such that nolarge, low priority message will block a later arriving small, high priority one.3. The client-to-server interface operates at a performance level that allowsmultiple messages to be sent to hosts such that no large, low prioritymessage will block a later arriving small, high priority one.4. The server-to-client interface operates at a performance level that allowsmultiple messages to be received from hosts such that no large, low prioritymessage will block a later arriving small, high priority one.5. The Application ID is handled by the originating client mapping theApplication ID to a field in message header and destination client passingthe field in XML to application. If the Application ID is “” then the ApplicationID becomes “DEFAULT.”Applications may direct messages to any application by setting the Application IDfield, or may omit it all together. The Application ID is an element in the AGIE namedescriptor. It may be used by the end user application routing function as meta-datato allow straight forward selection of the appropriate destination application by endsystem software handler. This allows application-to-application message mappingwhere only the two end applications need to be concerned with the Application IDstring. No AGIE internal messaging functionality is required to support thiscapability.Client-host server interface provides for well defined, secure interaction between theclient being hosted, AGIE services, and the AGIE network and shall always be overIP.

ARINC PROJECT PAPER 830 – Page 324.0 AGIE FUNCTIONAL SPECIFICATION4.2.2 AGIE ServersThe term “AGIE Server” refers to both AGIE service layer and AMQP layerfunctions. Each AGIE server has a single instance of a service layer attached to one(or more) AMQP Brokers. The AGIE service layer contains all the AGIE uniquefunctions. The AMQP layer contains the transport functions along with built-inAMQP services directly utilized by the implementation. AGIE messaging serverssupport a variety of delivery mechanisms. See Section 4.4 for details of messagingservices. See Section 4.6.4 for details of AMQP functions. Server messagingfunctionality operates in one of three areas:1. Message initiation or origination2. Message transmission3. Post message transmission for status, reporting and loggingAGIE implementations typically include ground-based as well as aircraft residentAGIE servers although AGIE does not require the existence of aircraft basedservers.An AGIE implementation requires as a minimum one ground-based server and it ispossible to implement several ground servers within a single AGIE system. In theevent of multiple ground-servers, one of these server shall be designated the“primary” server.A primary server performs additional functions that are not required for any of theother AGIE servers. In a single ground-server implementation this server must takethe role of the primary server.During times when an aircraft does not have connectivity with the ground one of itsonboard servers takes the role of a temporary “home” server for that aircraft.Aircraft based or “onboard” servers are dynamic with respect to connectivity to theground-side of AGIE system. Only AGIE aircraft servers shall be dynamic. Allground-side AGIE servers shall be static, and are always reachable using staticaddressing, routing and connectivity. The ground-side of AGIE or “Main AGIE” or“Central AGIE” is defined as containing the “Primary” server. The concept of a“Primary Server” is logical and may be implemented in any physical manner.Only a dynamic aircraft AGIE server shall be allowed to request server associationwith the Main AGIE network, and only via the Primary server. This serverassociation is triggered by a new path between the aircraft and the Main AGIE or bythe onboard server booting up or restarting.The onboard server makes a request for association with a service hosted on thePrimary. The Primary responds by setting up the association at the AGIE serviceand AMQP layers, then updating all onboard configuration databases required foroperation. After the onboard server is synchronized with the Main AGIE server,stored messages are transferred between the aircraft and ground server and theAGIE Name Server (ANS) is notified of the new accessibility. The ANS function isdescribed in Section 4.5.7. ANS performs name resolution. Stored messageforwarding from the aircraft is accomplished using the onboard temporary homeserver.AGIE Primary services shall include maintaining and serving system-widedatabases to all AGIE nodes, as well as a root level AGIE Name Service.The admin is responsible for defining the AGIE name space. AGIE supportsconcepts of client unique naming as well as that of replicated naming as is found

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 33onboard aircraft using ARINC Specification 664 addressing conventions. SeeSection 4.5 for detailed discussion on AGIE name space and namingconsiderations.4.2.3 Topology ConsiderationsThe following topologies describe a method of distributing AGIE functionality. It islikely that some airlines will require a melding of multiple topologies. AGIE shallpermit the implementation of mixed topology architectures, e.g.:1. All aircraft with a single AGIE server2. Some aircraft with multiple AGIE servers3. Some aircraft with only AGIE clients onboardAGIE implementation topologies can change over time. As newer aircraft with moreAGIE and connectivity come into an airline’s fleet, a more robust topology may beexpected. For example, early on in AGIE deployment there may be only a fewaircraft with onboard servers, many aircraft with only onboard clients, and evensome aircraft without in flight connectivity. Over time this will shift until the oppositebecomes true. Therefore, it is essential for AGIE to support such complex, mixedtopology implementations for the foreseeable future.The baseline AGIE topology is easily understood as a system with a single groundserver and a single server on each aircraft and multiple clients. Figure 3 depicts thistopology.Figure 3 – AGIE Topology

ARINC PROJECT PAPER 830 – Page 344.0 AGIE FUNCTIONAL SPECIFICATIONSome topologies might include aircraft that do not host an AGIE server, even thoughthis reduces AGIE’s value to those aircraft. A number of reasons exist why early onaircraft may not be able to host an AGIE server.1. No onboard or not sufficiently capable computing environment available2. No onboard network present3. No air-to-ground in flight connectivity4. Only available onboard applications are on mobile devices that directlyconnect to ground5. Mixed fleet operation where most of the cost is getting ground-side datacreatedAGIE supports simple topologies with only a few nodes. Only one single AGIEserver in the entire system is required for a fully functional system. Simpletopologies also include a single server on the ground and a single server on eachaircraft. More complex topologies have a larger ground footprint and may havemultiple servers on each (or some) aircraft. The most complex topologies arepartitioned and operate as isolated AGIE networks or systems with the admincontrolling inter-isolated network communications. The AGIE Topologies paper(referenced in Section 1.4) contains additional detail on these topologies.4.2.4 Cross Domain AGIEOne of the key capabilities of AGIE is to provide cross-domain services. The term“cross domain” is defined as AGIE having the capability of supporting applicationsand devices hosting applications assigned to the first three ARINC Specification 664Part 5 domains (ACD, AISD, and PIESD). An AGIE implementation may bedeveloped for a single domain or may support multiple domains. This multi-domainapproach means that the AGIE standard and functional definitions are establishedfor this intent. It is up to implementers, certification and approval authorities tovalidate this claim.AGIE provides built-in features to support multiple domains. These include admincontrols over node visibility, security features, coordination message protection, andAGIE client-server architecture. AGIE allows administrators to configure an AGIEsystem to the desired level of partitioning.Another cross domain feature is sharing off-board communication links across allfour domains (ACD, AISD, PIES and even PODS despite AGIE not supportingpassenger devices). Such a cross-domain implementation involves protecting andisolating information while transferring across these links. The approach is thatAGIE does not trust the link and therefore AGIE includes provisions to protect all ofits own data. The standard does not have built-in reliability and availabilityrequirements, though an implementation may.COMMENTARYWhile the AGIE specification is defined for cross domain service offerings, itis an emerging technology area in aviation and much of the lower levelimplementation and security features are outside of AGIE scope.4.2.5 AGIE and AMQP ArchitectureAGIE standard defines service layer functional architecture that touches theapplications above AGIE by application-client interface and the underlying IPnetwork below by AMQP. AMQP shall be the transport layer. All AGIE server-servermessage transfers shall be by AMQP messaging services (i.e. no out of band

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 35messaging). The basic components in an AGIE system are end user applications(technically considered not part of AGIE itself), AGIE clients, AMQP clients, AGIEservers, AMQP brokers, administrator (outside of AGIE) and network/networkmanager (outside of AGIE).At AGIE service level there are AGIE clients and AGIE servers, and at the AMQPlevel there are AMQP clients and AMQP brokers, respectively.AGIE servers and clients communicate at peer level as do AMQP clients andbrokers. AGIE clients and AGIE servers communicate vertically within the largerstack with AMQP brokers in one-to-one mapping. That is, each AMQP client isattached to an AGIE client and likewise each AMQP broker is attached to an AGIEserver and there may be more than one AMQP broker attached to an AGIE server,as a distributed implementation of a single AGIE server. AGIE and AMQP clients aswell as AGIE and AMQP servers are considered co-resident. Detailed interfaces aredefined in Section 6.0.The relationships between these nodes are defined as either component-tocomponentwith functional interfaces or peer-to-peer with logical interfaces.Component interfaces are where AGIE components touch an adjacent component.These include: application-client, AGIE client-AMQP client, AMQP client-AMQPbroker, AMQP broker-AMQP broker, AGIE server- Network Manager, AMQP brokernetwork services, and AGIE server-Administrator.Peer level relationships are logical relationships to components at the same peerlevel. They are not adjacent components and communicate by coordinationmessages at AGIE service layer and built-in standard interfaces at AMQP layer.These relationships include: application-application, AGIE client-AGIE server, AGIE server-AGIE server.See interface definitions in Section 6 for interface details.4.2.6 AGIE Architectural SecurityAGIE has been architected to include secure messaging features. AGIE has built-infeatures designed for architectural security intended to provide domain segregationand allow sharing of datalinks between domains. AGIE’s client-broker architectureprovides an environment where inherent isolation exists between Internet-basedground clients and on-board clients with an AGIE server network in middle.1. Ground based clients have no direct visibility or addressing information foron-board clients (or any client, for that matter).2. AGIE server network is managed by airline IT therefore benefits from allavailable IT security capabilities.AGIE partitioning design provides for implementation of separate, secure physicallyand/or logically isolated messaging domains when necessary.1. Domain implementations and control is managed by the operator’s admin2. Naming and address is limited to nodes with “need-to-know” by the admin3. Private AGIE networks are defined by operator admin as isolated domainswith controlled inter-network communication tightly managed by the adminonly at the Primary ground server interconnect.

ARINC PROJECT PAPER 830 – Page 364.0 AGIE FUNCTIONAL SPECIFICATION4.3 Paths and RoutingAnother key concept of AGIE is the “AGIE path,” which is an abstraction of the lowerlevel IP route between AGIE servers. AGIE sends messages over AGIE paths, whileIP routes IP packets over IP routes. This section describes AGIE paths and theirrelationship with IP routes. AGIE does not perform IP routing; instead, it relies onthe network layers for this capability. Discussed below are IP routes, AGIEconnection, and AGIE paths.4.3.1 IP RoutesIP routes are used by the IP network protocols and devices (computers, IP routers,and switches) to route IP packets and perform IP network services. AGIE does nothave the notion of AGIE routes. AGIE does not perform ANY processing of IP routesor IP addresses. However, AGIE does influence IP packet delivery by prioritization(TOS/DiffServ) and IP route selection (source-destination routing). AMQP directlyinterfaces with the network services but does not perform them.4.3.2 AGIE Connections and ProfilesWithin the framework of AGIE, “Connections” are communication/data exchangelinks between AGIE servers. Servers may have multiple connections to anotherserver. Dynamically associated servers may alter their connections as they comeand go. Ground-side connections are assumed to be static and fixed, that is, nologic or requirements are written in this standard to deal with dynamic server-serverrelationships other than those associated with onboard aircraft servers. Further, howand by what means the ground-side, fixed networks are developed, maintained, ormodified is out of AGIE scope and left to implementation. The network infrastructureties into AGIE by virtue of the AMQP layer.AGIE characterizes connections by their attributes using AGIE specific “ConnectionProfiles.” Connection profiles capture key parameters of the connection. Connectionprofiles are static and unchanging during operation. Operator admin may modify,add, or delete profiles off-line by system configuration. Connection profiles capturelogical link characteristics, not physical characteristics. However, there may be aclose correlation between a datalink connected to an onboard server and itsconnection profile. The Admin role manages the system-wide connection profile listas well as a mapping for each onboard AGIE server. This is an abstracted mappingof one or more datalink service offerings to a connection profile. Examples ofconnection profiles are “SBB Safety Service,” “Gatelink,” and “Wi-Fi.”Connection profiles are most closely tied to onboard AGIE servers. The datalinksare assumed to be the weakest part of a connection between the onboard nodesand the Main AGIE ground network. Therefore, all ground-side nodes are assumedto have the same access characteristics (QoS, performance, latency, etc…) to allnodes on an aircraft via that path or connection profile.Given that connection profiles are static, AGIE connection profiles shall pre-sharedand stored on all AGIE name servers during system configuration. All that isrequired in real-time exchange is to inform the other nodes of QoS and otherconnection is the connection profile name.Connection profile parameters are defined for each connection profile. Basic AGIEfunctionality does not use these parameters at this time. They are, however,provided to smart functions (AGIE and non-AGIE) as meta-data. When a smartapplication or smart function pings a destination, the AGIE name server returns a listof the available paths to the destination. This list is processed by the host server.

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 37Available path profiles along with their parameters are passed on to the applicationfor its decision making. Connection profile parameters are defined in Section 6.0.4.3.3 AGIE PathsWhen a new connection becomes available (or goes away), the entity that performsonboard IP network management service (e.g., MAGIC) creates a new connectionto the onboard server. The network management function selects the appropriateconnection profile. The onboard AGIE server sets up paths based on the connectionprofile updates provided by the onboard network manager. The onboard local AGIEname service maintains a list of available paths between the aircraft and the AGIEmain network. The local AGIE name service shares the newly created (and ifpossible recently lost) paths with the Primary’s root level AGIE name service.The interface between the AGIE server and the network manager that providesconnectivity updates to onboard AGIE servers is not defined by this standard. Theimplementer is free to choose the most appropriate mechanism for this withoutrisking interoperability and may be implemented by direct software function calls, bySNMP traps, or MAGIC defined interfaces.4.3.3.1 Best Path SelectionAGIE selects the appropriate path based on a “best path selection” algorithm, whichis driven by the Best Path Selection Table. An example is shown in Figure 4, and isspecified by system admin. The algorithm accesses the lookup table to compute atype of “goodness factor” for each available path. The path with the highestgoodness factor is selected. If no paths are available, the message is not sent.The lookup table is a multi-dimensional structure. It contains a path entry for eachconnection profile in the system. Each path entry contains a list of selectionparameters. The Best Path Selection Table Database XML template is furtherdescribed in Section 6 and the syntax in Appendix D.Figure 4 – Best Path Selection Table Example4.4 Messaging and Message DeliveryThis section defines the message transmission services offered by an AGIEcompliant implementation. These services map to functions, message handling, andparameter settings. The end user application does not directly see these services.The application simply sends a message via a single common XML based messagecommand interface. Within the interface, various parameters map to requests which,

ARINC PROJECT PAPER 830 – Page 384.0 AGIE FUNCTIONAL SPECIFICATIONalong with built-in AGIE logic, determines which message service AGIE selects tosend the message or make the service request. Figure 5 shows the typical messageflow with AGIE and AMQP components.Figure 5– AGIE Message FlowIf the application destination target processing maps to a single destination ID, thena point-to-point service is invoked; if it resolves to multiple destination IDs, then apoint-to-multi-point service is selected. If the data being sent is larger than theadmin defined size limit, then a large message service is invoked and likewise if thevalue is smaller. If the destination target is the “Pub-Sub,” then the Publishsubscribeservice is selected and the destination becomes the function/client/serviceon Primary.In addition to message sending, AGIE provides applications message managementservices. These use the same XML based application interface which is defined inSection 6.0.AGIE shall provide five message transmission services:1. Point-to-point messaging for small messages2. Point-to-point for large messages/data3. Point-to-multi-point for small messages4. Point-to-multi-point for large messages/data5. Publish-subscribe (point-to-multi-point)AGIE shall provide the following message management services:1. Pull messages from AGIE server2. Manage (control/status) in-transit messages3. Request AGIE node/network status (ping)4. Log event5. Manage publication subscriptions

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 394.4.1 Message Service InterfaceThe message service interface is the method the application uses to command theclient to send a message or request a message service. The client accepts the XMLdata from the application and maps the request to the predefined message type.Message services are usually invoked by an application via the client interface foruser payload messages. However, AGIE functions also invoke the messageservices for control, system management and distribution of configuration data.AGIE functions may use the XML interface like end user applications or may invokethe services directly via a well formed coordination message already in compactformat. Compact messages provide more efficient transmission over costlydatalinks.COMMENTARYTwo separate terms are used with regard to reducing XML document size.Compaction means using the pre-defined and pre-shared templates toreduce the bit count in the header. This is included in this standard.Compression means using an industry standard based XML add-on featureto compress the entire XML message (including payload). This algorithm isnot defined in this standard. It may be implemented between AMQP nodesby built-in AMQP features. However, care must be taken to ensureinteroperability.The application interface to the client is defined to be simple, portable and humanreadable. The definition is an XML template and format. It is anticipated that theapplication and client are in close proximity and that there is acceptable costassociated with application request to the client over XML with a verbose message.This is not necessarily the case for AGIE functional service requests and interservermessaging. Therefore, a compact version of the XML interface with wellformedcoordination messages is also defined.Standard message formats are defined to allow interoperability between clients andservers developed independently by implementers on a single implementation AGIEsystem and across all implementations. The XML interfaces are defined for basicservices. Operators may add XML message types to refine message sets, increasemessaging efficiency or strengthen information security.The XML message types are processed into pre-shared XML templates. AGIE shallsupport pre-sharing of standard XML message templates with built-in efficiencyfeatures. Template processing removes all non-needed message fields that can bereconstructed using the pre-shared template at the destination host. It alsosubstitutes short tokens for enumerated fields, which are replaced at templatereconstruction.4.4.2 Message Service AttributesAGIE provides operationally selectable attributes for managing efficient transmissionof message sending. Each attribute has a default for each message service. Thedefaults may be overridden within range set by the admin for each client type,message type, and/or service offering. The attributes manage prioritization, deliverymechanism, and status and reporting.

ARINC PROJECT PAPER 830 – Page 404.0 AGIE FUNCTIONAL SPECIFICATION4.4.2.1 Priority RequestThe service invocation includes an initial priority request in the XML or by default.The AGIE host validates the priority request when building the coordinationmessage. AGIE may override the request by admin configuration with specifiedvalue or range of values based on a number of conditions, like client type or ID,message type, link status, or time-to-live.The default priority requests are defined below for service type. They are for basicAGIE priority and for user priority if implemented. The admin may override these inimplementation to another default. AGIE provides for URGENT and NORMALpriority requests by message sender and admin configuration.1. User messages point-to-point small normal, normal2. User messages point-to-point large normal, background3. User messages point-to-multi-point small normal, low4. User messages that are immediate urgent, high5. All messages point-to-multi-point large normal, background6. Coordination messages point-to-point small urgent, medium7. Coordination messages point-to-point large normal, low8. Coordination messages point-to-multi-point small normal, normal4.4.2.2 Message or NotificationAGIE shall support direct message delivery “push” and message notification “pull.”That is, the sender may send a message directly or may notify the destination amessage is waiting to be sent. This allows the destination to determine if and whento pull the message to it from the storage location. This allows smart applications tocontrol their link usage, QoS, or cost, and manage message timing. The sender setsthe message push or pull in the service request or by default. The admin mayoverride this request on a specific message type or size, or client ID or client type,or other parameter. Standard defaults are:1. User messages point-to-point small send2. User messages point-to-point large notify3. User messages point-to-multi-point small send4. User messages that are immediate send5. All messages point-to-multi-point large notify6. Coordination messages point-to-point small send7. Coordination messages point-to-point large send8. Coordination messages point-to-multi-point small send4.4.2.3 Originator ControlsAGIE shall provide the following message management controls accessed viasender requests, message parameters and admin control:1. Automatic message reporting. The default for automated reporting is OFF foruser payload messages (except for immediate messages) and ON forcoordination messages.2. Automatic logging of message delivery status with the same defaults. Theadmin may override these defaults in implementation with other defaults andmay set them by client or server type/ID or message type, or any other logic.

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 413. Manage time-to-live by standard default, which the admin may override, bymessage type.4. Automatic message deletion after delivery and/or timeout. Originator mayrequest message deletion or request status any time after the message issent (until the message expires).5. Message persistence, which is default to NO-CHECKPOINT, where theoriginator may request persistence to check point it when possible byservers with access to persistent store. This allows very important messagesto reduce the likelihood of being lost and unrecoverable.COMMENTARYIt is not a requirement (except logging) for any data to be consideredpersistent. This is a request, which may or may not be honored by any AGIEnode handling the message based on the node’s AMQP durabilitycapabilities and settings.What happens when a message times out is left to implementation (other thandefined logging, reporting, and deletion). The implementation may simply delete themessage, query the application, or process the message in some other way for resubmission.The minimum or default is to simply delete the message and ifreporting, status, or logging is requested, follow that line of response.AGIE provides for message persistence using AMQP durability settings. Not allAGIE servers or AMQP brokers will have access to persistent storage. AGIEpersistence is managed in the XML templates via a standard message field called“Checkpoint” that when set, requests the message be check pointed any time thedestination is not immediately reachable. This is important for critical logging events,such as security events. One task of association is reporting status of storedmessages, which include check pointed messages not yet delivered as well asmessage segments received but not completed.AGIE shall provide logging function that provides logged events to an external logfunction via Log Client. AGIE does not define what happens to these logged eventsoutside of AGIE.4.4.3 Message Service ConsiderationsEach messaging service has unique considerations.4.4.3.1 Immediate MessagingImmediate messaging is a service defined to provide real-time like capabilitieswithout adding strict real-time requirements to AGIE. This service is defined simplyas a high priority message with an immediate (zero) “time-to-live.” Immediatemessages have the guarantee of real-time response to success or failure. Thissupports applications such as chat-like services and low latency aviation messages,where it is important to either have a real-time AGIE service or real-time (immediate)response, be it positive or negative. AGIE shall provide immediate messagingservice. AGIE implementation shall include provisions that are aimed at minimizinglatency when processing for immediate messaging.

ARINC PROJECT PAPER 830 – Page 424.0 AGIE FUNCTIONAL SPECIFICATIONImmediate messaging is a sub-service of small point-to-point messaging for user orcoordination messages. Parameters are set to urgent priority, immediate time-out,or minimum (zero) time-to-live, push, and automatic reporting.The application making the request will either get an immediate success, and thenmay start the real-time like application, or immediate failure. Immediate successimplies that the destination client is reachable at time of service invocation.4.4.3.2 Point-to-Multi-Point MessagesPoint-to-multi-point messages are defined as messages with multiple destinationtargets. When a client invokes a message service, it provides a destination name inthe AGIE descriptor. The destination name is parsed during name resolution, seeSection 4.5. The result is a list of destination client ID’s. If the list is null then themessage fails. If the list has more than one destination client, then it is a multi-pointmessage by definition.Default parameters for multi-point messages in addition to the priority andsend/notify parameters described above, include: no-automatic reporting and noimmediatemessaging.COMMENTARYPoint-to-multi-point messages are primarily intended for ground to aircraftcommunication although AGIE permits this service for any messagingneeds.4.4.3.3 Large and Small MessagesA single system-wide parameter determines what constitutes a small or a largemessage. Small messages, i.e. messages that are smaller in size than thisparameter, are never segmented and large messages are always segmented. Thedefault setting for large messages is normal priority. Urgent priority is allowed but isto be used with extreme caution. Large data elements may be contained directly inthe XML data file by the application or may be attached via a link/reference in theXML service request. The latter is not defined in this standard.AGIE clients shall provide for segmentation of large files. Segmentation isperformed by the originating client and is reassembled by the destination client.Section 6.0 lists AGIE Interface methods specifically defined for the management oflarge message segmentation and an AGIE implementation shall uses thesemethods to manage segmentation to assure interoperability.This method is efficient for clients that remain associated for long duration.However, care must be taken when sending large files to clients that dynamicallycome and go on the AGIE network.4.4.3.4 Publish-Subscribe Message ServiceOne special adaptation of a point-to-multi-point message service is the Publish andSubscribe or “Pub-Sub” service. A Pub-Sub message is addressed to a singledestination which is always the Pub-Sub client or function on the Primary. The firststage of message delivery is handled like a point-to-point non immediate deliverymessage. The second stage of delivery to zero or more end destinations isaccomplished by the Pub-Sub algorithms and service functions of AGIE with thenumber of destinations being determined by the number of client that subscribe tothose message types

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 43Pub-Sub is based on pre-defined topics. Senders publish messages that include aspecial topic attribute in their message header. Destination clients determine whichtopics they wish to subscribe to. This determination can be at any time duringsystem operation. The Pub-Sub service maintains a list of subscribers for each topicpublished and clients notify the Pub-Sub service when a change in subscriptionstatus occurs. The pub-sub service also ensures the messages are sent to eachavailable destination in the subscriber list for the matching topic.The list of topics available for subscription is static and well bounded but shall onlybe changed via admin configuration updates.Topics are named by string values and AGIE does not prescribe a particular formatfor topic strings. Topics may be further defined by substring matches usingwildcards and dot notation. For example, the topic “NA Weather Turbulence Data”maps exactly to a topic of same string, “NA Weather Turbulence Data.” Moreovertopic names are not case sensitive and therefore this topic example also maps to“na weather turbulence data”. Use of wildcards is permitted. For example, the string“NA Weather Turbulence*” also maps to the same topic. Refer to the treatment ofname and address parsing in Section 4.5 for further details.In order to minimize admin processing and allow longevity to topics and names,complex parsing algorithms above and beyond the basic matches defined in thenaming and addressing section may be implemented, but are not defined as such inthis standard.Clients subscribe to messages via the standard message service interface. XMLmessage field parameters map to a predefined coordination message. See Section6.0 for details. The subscription and publication topic strings may include thewildcards and dot notation. Clients may unsubscribe using the same coordinationmessage, but with the unsubscribe request.The message delivery from publisher to the Pub-Sub service is via a “push” only tothe Primary. It is assumed, though not required, that most publishers will be on theground-side as is the Primary. Message delivery to the destination may be by pushor pull (notify).4.4.4 Priorities and Flow ControlThis section describes how AGIE controls message processing priorities andperforms flow control. Prioritizing message traffic is a key aspect of AGIE systemfunctionality and its interfaces with the underlying network(s). While on one hand itis desirable for AGIE to be able to completely and deterministically manage allmessage prioritization aspects, it is also clear that there are many variables in theunderlying networks that make this not possible. Often AGIE priority control is nomore than attempting to influence the underlying implementations.AGIE is datalink agnostic. AGIE transmits data over any IP datalink. Datalinks havedifferent prioritization capabilities. Some datalinks have no prioritization and arebased on equal and fair treatment of all users. Other datalinks have moderateprioritization by IP class of service, and lastly there are datalinks that provide a highdegree of prioritization (usually with a higher cost) via separated services. AGIE isdesigned to function efficiently over any or all of these links.AGIE servers are defined logically not physically. Therefore, specifying hardcomputing priorities is not possible. It is not known if the AGIE servers execute on areal-time kernel or a best effort Operating System. AGIE priorities are defined not as

ARINC PROJECT PAPER 830 – Page 444.0 AGIE FUNCTIONAL SPECIFICATION“hard requirements” but as goals with “nominal flow control behavior.” Nominal flowcontrol behavior means that AGIE compliant implementations are expected tofunction in the manner defined. This allows the specification to remain simple whilemeeting user expectations and adaptable to various implementation environments.It is an implementation issue to ensure the end-to-end prioritization meets userneeds of the in service applications and their intended functions.AGIE priorities are requested by the message originator, and are set and managedby the admin with defaults and ranges. Each message requests a priority for thatmessage. The AGIE server ensures the message request is within the range set forthat message type, that client, and for that service. AGIE sets the message priorityin the header which is used to communicate to AGIE computing functions themessage priority (AGIE service layer and AMQP layer). It is also communicated tothe underlying IP network by AMQP so it can do its best to implement AGIE’sdesired prioritization.4.4.4.1 Prioritization MechanismsAGIE includes two prioritization mechanisms. The first is a basic and mandatorycapability that all AGIE compliant implantations need to incorporate. This basicAGIE priority mechanism shall provide two priority levels that are NORMAL andURGENT message priorities. The second mechanism is the USER PRIORITYmechanism, and is optional but recommended. User priority refines the normalAGIE priority range to allow broader range in flow control options. User priorities aredefined as: very high, high, medium, low, and background and is captured in anoptional field in the AGIE message header. AGIE prioritization affects theAGIE/AMQP function processing, queuing as well as IP network processing (via IPTOS/Diffserv).4.4.4.2 AGIE Priority ExpectationsAGIE defines the following general behavior as the basis for specificationdevelopment and functional definition. An AGIE compliant implementation shallexhibit the following:1. Functions execute as if they are multi-threaded non-blocking (client andserver functions) manner2. Functions execute as if they are multi-threaded non-blocking manner at theclient interface to the application3. Queuing executes as if there are separate queues for each IO client/session4. Queuing executes as if there are separate queues for each connection/port5. Prevents queue starving for client IO from large files6. Prevents queue starving on connections from large files7. High priority coordination tasks are handled before payload and not waitingin back of queue8. no (major) priority inversions occur from priority stack (below)9. Large urgent messages are used sparingly, if at all10. Priorities are used with a fair weighted scheduling function that does notstarve other functions/queues if/when mishandledAGIE priority nominal behavior shall be implemented with some form of fairweighted queuing for basic AGIE priorities is defined below with highest priority firstand lowest priority last.1. Urgent coordination have highest system priority

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 452. Urgent user small messages3. Urgent user large messages4. Normal coordination or user small messages5. Normal coordination or user large messagesAGIE priority nominal behavior for AGIE user priorities, when used with basic AGIEpriorities, shall be as defined below with highest priority first and lowest priority last.1. Urgent coordination have highest system priority2. Urgent user small messages3. Urgent user large messages4. Normal – Very high5. Normal – High6. Normal – Medium7. Normal – Low8. Normal - Background4.4.4.3 Priorities in FunctionsAGIE computing functions affect prioritization at the AGIE service and AMQP layers.AGIE server computing processing affects and manages prioritization in three ways.1. Best path selection considers priority setting and influences QoS2. AGIE and AMQP orders queues based on priority settings3. AGIE and AMQP feeds/meters data from queues to network based onpriority settingBest path selection is determined by priority setting and mapping table managed byoperator admin. Path selection is a key element of prioritization. Path selectiondetermines the datalink and type of service. Path selection is implemented byAMQP mapping to default or source-destination routing on the IP network betweenAGIE servers/AMQP brokers. Paths are defined by their connection profile name.AGIE sets the priority for messages, which may be treated anywhere from near realtimeto background message priorities. The priority settings determine how AMQPqueues and transmits the messages relative to other messages. Segmentedmessages are queued multiple times for each individual segment.4.4.4.4 Background PriorityAGIE supports the concept of background messaging using a “background priority”.Background priority allows the operator to minimize cost and QoS impacts ofsending less important (time criticality) messages, especially large ones, by longtermscheduling. The actual mapping of background priority features is left tooperator admin, but it includes the ability to hold a message until specified time orcondition exists. Examples would be only allowing transmission over grounddatalinks, metering traffic during phase of flight, or sending over a lower class ofservice. Again, the special feature of background priority is the ability to hold offinitial message sending from the origination host or home server.4.4.4.5 Priorities with NetworkThis standard is developed to support priority managed networks and datalinks.However, AGIE does not require them for operation. AGIE does not have control

ARINC PROJECT PAPER 830 – Page 464.0 AGIE FUNCTIONAL SPECIFICATIONover them. AGIE functions even when any of the underlying networks or datalinksprovides no any prioritization at all, AGIE will still function, albeit without control overnon-AGIE prioritization capabilities. AGIE (and AMQP) maps priorities to underlyingnetwork by setting the IP message header IP TOS/DiffServ byte. The mapping is notdefined in the AGIE standard.4.5 Naming and Addressing ProcessingAGIE naming and addressing is one of the most critical aspects of the AGIEstandard because an AGIE requirement that is of paramount importance is toenable any AGIE client to address any destination client without requiringknowledge of how the destination client may actually be reached. The AGIEstandard therefore explicitly defines a mechanism for addressing messagerecipients.One of the key elements of AGIE architecture and security is separation of AGIEnaming from AGIE addressing. A further key aspect is separating IP leveladdressing from AGIE addressing. These separations provide for stronger securityand allow AGIE to stay above the underlying network architecture and design.AGIE provides a multi-step process for name and address resolution. First, theAGIE name string is parsed. Next, the name is resolved to a list of target IDs. Lastly,the target IDs are resolved to AGIE addresses with path options.4.5.1 Name Space ConsiderationsThe AGIE naming convention includes the concept of Name Space and every AGIEclient must be uniquely identifiable in AGIE name space. At times, it may benecessary for individual applications to also be uniquely identifiable. Name-spaceseparation guarantees that clients, admin, and AGIE functions can uniquely addressany single client when desired. AGIE allows application name space separation,although this support is limited. Conditions can arise where multiple destinations aretargeted or when it is too burdensome to provide every client with a unique identifier.AGIE has adopted a name space approach that allows both situations to beefficiently handled.AGIE defines several methods for guaranteeing name-space separation. The first isto uniquely name each in the entire system. This approach, however, may be aburden for large operators and result in unreadable and complex names. Second,the system may limit name visibility/scope, allowing replication at the global level,but not at a lower level (i.e., AGIE network, sub-network or server). AGIE supportsboth of these methods. Careful planning is needed to select the more appropriateapproach for a particular implementation.COMMENTARYWith regard to the potential need for replicated naming, consider thefollowing. ARINC 664 naming and addressing is used on most aircraft.ARINC 664 naming uses replication, where the scope of names andaddresses is a single platform. Devices are configured identically across thefleet, allowing a single part number to be used on all platforms, minimizingmaintenance activity.AGIE ensures client name separation by using a combining the client ID and theAGIE host ID. For example, the FOQA device on a plane could be named by thereplicated name of “FOQA Device,” yet identified on a specific plane by the onboardAGIE server “N1234” as “FOQA Device.N1234.” Below is a more detaileddescription of naming processes.

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 47AGIE name-space approach combines unique IDs with replicated IDs. The adminnames each client as desired (they may be unique or replicated). The AGIE serverthen ensures that within its local name space no duplicate named clients exist. Thisis a requirement to be accomplished during AGIE server association. How to handleduplicate name requests on a single AGIE server is left to implementation.The approach of combining replicated and unique names at the system level, workseither when all clients in the system have unique names, or when there are noreplicated client names on any AGIE server (type of AGIE sub-network). It alsoallows easy addressing for intentional multi-destination messages. AGIE shallprovide name space processing as defined below.1. The operator uniquely names each AGIE server. AGIE does not enforce aparticular naming convention although to make an AGIE system easilymanageable the chosen names should be user friendly and readable, suchas “N1234” from tail number, or “ACD.N1234” for Aircraft Control Domainserver on N1234, or “North America” for ground server, or “Primary.”2. The operator names each client as best suited for their operations.Replicated names may be used when there is no chance of conflict on asingle AGIE server. Unique names may be taken directly from devices, orpart number names, or user IDs, such as “FOQA Recorder,” “Pilot EFB” or“John Doe’s iPad.”3. AGIE server ensures name separation during association of a new client orclient request by checking existing client list of names against the newrequest or list of fixed clients normally associated with the host. It fails orhandles any conflicts that arise. Any name conflict must be removed priorallowing a new client with the conflicting name.4. AGIE name service maps names to a unique client or multiple clients whenlooking up a destination client address in name-address parsing.4.5.2 Naming ConsiderationsIt is an operational admin function to define all client and server name/identifiersacross the entire system. The operator admin has full control over client and servernames. Operational naming considerations are found in Section 5.0. Below aresome system considerations.The “Admin”, “Log” and “Pub-Sub” client names are AGIE predefined and must benamed exactly as defined. Onboard servers should reference aircraft Identifier intheir ID. Fixed devices should be named appropriately for their function, title, or role.Mobile clients associated with a specific user should reference their user name,while mobile clients associated with a crew or operator position should include theirtitle or position.Complex devices, such as EFB, host multiple applications on a single device.Unique naming of every application on each EFB results in complex names.Addressing all messages just to the device makes routing messages to applicationsoverly coarse, requiring complex mapping logic on the receiving end. The AGIEsolution is an “Application ID,” which is appended to the name descriptor. It providesthe application-client interface with meta-data for application routing withoutcomplex logic.

ARINC PROJECT PAPER 830 – Page 484.0 AGIE FUNCTIONAL SPECIFICATION4.5.3 AGIE Name DescriptorsAGIE name service processes a robust AGIE name descriptor, intended to besimple and efficient and self-documenting.The name descriptor has four sub elements used for addressing (1) an application,(2) a client, (3) a server and (4) an AGIE network. AGIE servers process the namedescriptor by parsing the entire descriptor. However, only the Primary serverconsumes and processes the Network element. The symbols were chosen with theexplicit intent to avoid any conflict with “conventional” IP or web addressing. AGIEname descriptors are parsed from left-to-right.AGIE shall implement the AGIE name descriptor as defined below.The structure of a standard Descriptor is as follows:“&&&”Uses the ID separator symbol “&” between identifiersIdentifiers are simple strings to AGIE functionsIdentifiers allow “.” separation to facilitate non-AGIE application parsingalthough within an AGIE identifier this “.” symbol has no meaningString may be null “” as && and map to any or all string matchesOnly Client ID is required all other identifiers are optionalFor server-server communications client name becomes function name (i.e.,ANS)Identifiers include:o Application name = o Client name = o Server name = ”o Network name = Example: for airborne data loader “esu#adl&N1234&United”ooooApplication name = “esu”Client name = “adl”Server name = “N1234”Network name = “united’4.5.4 Name ParsingAGIE shall provide for string parsing of names as defined below. This is also thesame process as used to parse topic strings used in Pub-Sub.AGIE parsing supports partial names. Only enough elements are required to ensurethat parsing is deterministic. The minimum needed to parse an AGIE descriptor isthe client name. Any other field may be null. Adding appropriate “&” is required forvariation of default shorthand defined below:1. With one name as 2. With two names “name & name” as & 3. With three names “name & name & name” as & &4. With four names “name & name & name & name” as & &

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 495. Variation examplesa. One name variation “& name && name” as & b. Two name variation “& name & name” as & AGIE defines two addressing identifier wildcard notations for use in names andparsing strings. The “*” matches “all” and “+” matches “this” or “local” as in localnetwork or local server. AGIE descriptor parsing has built-in defaults to allow simplenaming, for example default is resolves to all on allservers, this network. Null name values default to:1. Application name = “default application ID”2. Client name = not applicable as client name is required3. Server name = all servers on this network4. Network name = only this networkThe parser accepts the AGIE Name Descriptor and maps it to a target destinationstring. Parsing operates left to right defining the client name (or function name) andAGIE network scope. Parsing is the only AGIE function that deals with sub-stringsand wildcards while all other functions use the target ID list.4.5.5 Name ResolutionAGIE shall provide a Name Server, the “AGIE Name Server” or “ANS”, resolvesnames to IDs as defined below immediately at service invocation for nodes that areconfiguration synchronized with the Main AGIE or hosted on a local AGIE server,and immediately after synchronization for detached aircraft networks. Nameresolution is a service of the cascaded ANS. The root AGIE name server resolvesall names, where each local resolves names for its sub-network.Name resolution accepts parsed name descriptor strings and returns a list ofmatching node IDs. The list may be null, a single ID or multiple IDs. Null is amatching failure. A single ID is a one-to-one match. Multiple IDs are a one-to-manymatch.4.5.6 Address ResolutionAddress resolution is the process of determining the target ID’s AGIE address. Thetarget may be a client, server, or function. AGIE shall provide address resolution asdefined below.1. Address resolution is immediately performed for reachable destinations andfixed destinations2. Address resolution for mobile clients is performed as soon as destinationbecomes reachable and the address becomes known3. Address resolution is an ongoing process for point-to-multi-point messages,as destinations become reachable they are immediately resolved4. This is a function of cascaded AGIE Name ServiceThe following steps define the standard sequence of resolving names to AGIEaddresses for each ID.1. A client sends a message intended for another client to its host.2. The local ANS resolves the name immediately (as synchronized with rootANS).

ARINC PROJECT PAPER 830 – Page 504.0 AGIE FUNCTIONAL SPECIFICATION3. The local ANS attempts to resolve the ID address.4. If the local ANS resolves the ID to the same server or onboard sub-network,then name resolution is complete and the message is directly sent to thedestination client (if reachable).5. Otherwise, an interim destination is generated: the destination client’s Homeor Pub-Sub.6. Local ANS resolves to this interim ID, and the message is forwarded.a. If the local ANS is an onboard ANS and there is no connectivity to theroot ANS then a temporary interim address of the onboard temporaryhome server is resolved. When the root ANS becomes reachable,address resolution to the interim ID is resumed.7. The home server attempts to resolve the destination client’s address via itslocal ANS.8. If the local ANS cannot resolve the address then the Primary ANS isconsulted and the address resolved at the root (may take some time waitingfor mobile, un-associated clients).9. The Home forwards the message to the destination host, which ends thename resolution.10. If at any time it is determined that the address is incorrect, the message isdropped and the originating client notified of failure.4.5.7 AGIE Name ServiceAGIE name service processes a destination ID list to obtain destination addresses.It resolves the ID to host, Pub-Sub, or home server and provides path options toreach it. The root AGIE name server has list of all visible nodes, both clients andservers, as well as visibility restrictions for each node for all isolated networks. Eachlocal ANS has this same information for its sub-network. For ANS definition, eachuse of “client” may be substituted with “function” for AGIE functional naming.AGIE shall provide for a name service, which may be cascaded. The root shall behosted on the Primary and is the backstop for complete system level name space.Local name servers may be employed to reduce the load on backhaul. Each aircrafthosting an AGIE server shall have a single, visible, local ANS per aircraft. Inimplementation, it is up to the operator to determine if and where additional nameservices are hosted. At most only two name servers can exist between any twoclients, i.e. the origination host’s local ANS and the Primary ANS.The local ANS maintains lists of data including:List of all local client IDs in the system (or this sub-AGIE network)List of currently associated clientsList of fixed yet unassociated clientsCache of recently used IDs with paths and addressesMapping for each client ID to its home serverIn a partitioned system, the operator divides the AGIE network into smaller, isolatednetworks by operator determined domain space considerations. In this case thelocal ANS has limited visibility across the full AGIE network. However, the Primaryalways has access to all data and full visibility. The admin must authorize ALL crossisolated network access by configuring ANS to allow off-AGIE network access.Cross isolated network access is ONLY accomplished via AGIE networkinterconnect function on Primary. Only the root ANS may resolve cross network

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 51addresses. Therefore, it must be configured to contain network visibility data fornodes on any isolated domain. The local ANS also needs to be configured to allowcross domain access to allow it to make a request to the Primary. The node that isallowed cross domain access has a “cross domain allowed” flag set in itsconfiguration.To assure that AGIE Name Server data is always up to date every AGIE servershall “report” all changes in associations to the root ANS via the appropriatecoordination message (see Section 6.0. The ANS maintains its internal records overtime as associations and accessible paths change. The local ANS contains a cacheof addresses and paths which are subject to timing out as the information becomesstale. When the root ANS is not reachable from a local ANS name resolution for offboardID’s must be suspended until the root ANS is again reachable. This isnecessary to ensure correct system-wide synchronization.Admin manages the visibility of all nodes on the network(s). This is done by a list ofvisible nodes (servers and clients) and/or by using client or server type attributevisibility lists in the configuration database for client IDs or client types. AGIE nameservice supports isolated networks by ensuring visibility limitations set by the admin.The root level ANS may override the intra-network limitation and route trafficbetween isolated AGIE sub-networks when configured by the admin.4.6 AGIE FunctionsThis section describes key AGIE function. Functions are defined for (1) all AGIEservices provided to AGIE users and (2) for services provided for AGIE systeminfrastructure support. The primary AGIE service is information exchange. Ancillaryservices are provided to allow smart application development, efficient informationflow, ensure security, allow managing system operation and performance, andsupport AGIE system administration. AGIE functions include those at both the AGIEservice level and AMQP transport level.AGIE functions perform functional as well as interfacing tasks. Figure 6graphicallydepicts AGIE functional components and their key interfaces. Component interfacefunctions are performed at the software level. Peer interfaces are performed bycreating and processing fields in the XML messages.

ARINC PROJECT PAPER 830 – Page 524.0 AGIE FUNCTIONAL SPECIFICATIONFigure 6 AGIE Functional Components4.6.1 AGIE Client FunctionsAGIE client functions provide services between the AGIE client and userapplications on one end and the host server on the other. Clients receive applicationservice requests, deliver arriving messages, and perform autonomous client tasks.AGIE shall provide the client functionality defined below.Applications are attached to an AGIE client. Multiple applications may be attachedto a single client. Application-client interface is only defined at the logical level andnot at the physical level.Applications and clients may be two software functions of the same program, theymay be separated by an IP LAN or WAN with a datalink in between, they may beconnected by inter-process communication methods, such as sockets, or any othermethod desired. It is not in AGIE scope to define how applications attach to client, orthe startup process. However, the standard is written with the assumptions that theclient and applications are close to each other, with high bandwidth interconnectionthat is secure. That is, the standard makes no provisions that are otherwise. Also, itis assumed that the interface between them is secure and reliable.Transport layer communications between the client and application is via AMQPclient mechanisms using AMQP queues. XML data is placed in and retrieved frompre-defined AMQP queues. AMQP functions are described in Section 4.6.4.There is no requirement that the clients have access to a persistent store; therefore,each startup is a clean slate with no in transit messages assumed to be recoveredor dealt with. However, sending large messages to a client that does not haveaccess to persistent storage must be done with care as a large message will not bedelivered until all segments have been received.The client functions shall appear to be multi-threaded to allow simultaneousprocessing and transmission of multiple simultaneous incoming and outgoingmessages. This is to ensure that no large, low priority message will block a smaller,

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 53higher priority one. This does not mean the client must be programmed in thismanner; it only means the specification is written with this assumption.AGIE service level client functions include:1. Accept and process incoming XML service request from application2. Send autonomous request to host3. Receive and process message from host4.6.1.1 Accept and Process Incoming XML Service Request from ApplicationAGIE client software functional interface receives a XML service request from one ofits applications via AMQP. Incoming message processing parses the XML messageservice request. There is one single XML template “Application-Client XML” that hasdefined fields and parameters that determine which service the application isrequesting. The function processes the XML request, ensures it is well formed, andthen creates the “Client-Host XML” message by filling in all the appropriate fieldsand parameters before sending it to its host. If the message is large, then themessage is segmented and separate XML messages are built for each segment.The request can be for any of the following:1. Send a message to another client2. Pull waiting message from an AGIE server3. Manage in transit message4. Ping another node (client)5. Log an event6. Manage subscriptionsFunctional capability is defined by the tasks required to appropriately fill in the XMLtemplate from the application’s message request and send it to the host via AMQP.If for any reason a well formed coordination message cannot be developed, therequest is failed and the application notified. After the message is acknowledged bythe host, the application is notified of success. Forwarding the message to the hostis accomplished by the co-resident AMQP Client via the interfaces defined inSection 6 and AMQP bindings defined in Section 4.6.4. AMQP client forwards themessage to its AMQP broker, which forwards it to the AGIE server host as peerlevel communications.4.6.1.2 Send Autonomous Request to HostClients perform several autonomous functions to abstract applications from AGIEdetails and foster security. These functions are autonomous in the sense that theapplication is not involved in triggering their operation. All client communications tohost are performed via the “Client-Host XML” message. Three functions areperformed:1. Associate with AGIE host2. Un-associate from host3. Log eventThe association function attaches a client to a host. It is always initiated by theclient. The trigger is outside of AGIE, likely software startup. The client is providedan IP name or IP address to associate with. This IP address may be built-in to itssoftware or it may be an IP name requiring IP name resolution via IP DNS. The

ARINC PROJECT PAPER 830 – Page 544.0 AGIE FUNCTIONAL SPECIFICATIONclient sets up a secure IP session with the host for association via AMQP using TLS.The host sets up the association. The client informs the applications that theassociation is complete via AMQP status update. TODO review this statement.The host notifies the ANS the client is associated. This triggers the configurationupdate process that ensures the client has all latest configuration data (if any) aswell as the sending and receiving of waiting messages.Clients with persistent store include information about partially received (alreadystored message segments) and check pointed (non-delivered) messages as part ofinitial configuration synchronization. AGIE provides an association redirectionfunction on Primary server, where the initial association attempt to Primary is failed,but the Primary returns the IP name/address of a better host for association. Theclient associates with the recommended host. In this case, AGIE does not requirethe initial association request be performed using a TLS session. Applications arenotified of association success or failure via AMQP. Association is a logicalconnection between the client and host that is physically implemented using AMQPfunctions that interface with network and TLS security.Un-association function tears down an existing association. It is also triggered byan outside event. While operational usage of un-association is not required fornominal system operation, implementing the function is a requirement. Using itincreases system efficiency by the timely update of the client’s status in the ANStables. The un-association function notifies the host of the un-association request,terminates the secure IP session, updates the ANS table, and notifies theapplications.Log event function is triggered by an event for security, error, or other reason. Thefunction receives an event notification from the requesting function and creates aLog entry in the payload of the message. The message is addressed to the LogClient.4.6.1.3 Receive and Process Message from HostClients listen for incoming messages from the host. They are received via AMQP.After arrival they are processed by the AGIE service functions. The incomingmessage is contained in the “Host-Client XML” template. If the message is adirected to the client, then the client handles the message alone. Otherwise, themessage is intended for an application. It is processed and the “Client-ApplicationXML” template is filled in and provided to the application via AMQP. The incomingmessage is one of the following:1. Received message from another client2. Notification of waiting message from server3. Ping response4. Manage message response5. Subscription response6. Peer acknowledgement of previous application requestThis function is defined by the tasks required to parse incoming XML message fromhost, process it, handle any autonomous tasks, appropriately set the fields in theapplication bound XML message and send to AMQP. This is logical with AMQPperforming the actual low level interface with the host.

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 554.6.2 AGIE Server FunctionsAGIE server functions are derived from AGIE messaging services provided to AGIEusers as well as infrastructure based system service functions. The functions areorganized as 1) client-server, 2) server-server, and 3) Primary and system tasks.The specific mapping of functionality to each function is left to implementation. AGIEshall provide server based functional capabilities defined below.1) Client initiated server functions:1. Client sends a message request2. Client pulls waiting message request3. Client manages in transit message request4. Client pings another node request5. Client logs an event request6. Client manages subscriptions request7. Client associates with AGIE host request8. Client un-associates from host requestClient terminated server functions. Includes appropriate response tasks:1. Receive message for client2. Manage message response3. Ping response4. Subscription response5. Peer acknowledgement of previous application request6. Client associates with AGIE host response7. Client un-associates from host response2) AGIE server messaging support functions:1. Dynamic server-server association2. Dynamic server-server un-association3. Server sends coordination message4. Server receives coordination message5. Server best path selection for message6. Server pulls coordination message from notification7. Server processes expired messages8. Server commands un-associate client9. Server status AGIE network (ping) request10. Server logs eventTo understand the functionality required in the functions listed above, it is importantto describe the complex messaging services being provided. These services cutacross multiple servers and AGIE nodes. Sending message service requirescomplex functionality that accommodates many options and variables. Sendingmessage features include: one-to-one or one-to-many destinations, allow push orpull, sending large or small messages, provide automated reporting, setting highand low priorities, making path selection, and mapping to a specific application.Sending messages includes both user application messages and AGIE coordination

ARINC PROJECT PAPER 830 – Page 564.0 AGIE FUNCTIONAL SPECIFICATIONmessages. It also involves various store-and-forward options, such as TemporaryHome, Client Home and Destination Server.3) Primary and system functions:1. AGIE Name Service functions2. Publish-subscribe server functions3. Configuration database distribution functions4. Logging client and functions5. Admin client and functions6. Primary level communication across isolated AGIE network functions7. Primary association redirect functionAGIE defines Primary and system functionality that is not tied directly to sendingand receiving messages. This functionality provides infrastructure support. Thesefunctions are defined to exist on the Primary server or temporary onboard Primaryfor a detached AGIE sub-network. The Primary is a logical definition and itsfunctions may be distributed in implementation.4.6.2.1 AGIE Message Server Functionality OverviewThe following sections describe server functionally for messaging by server type.The term “AGIE Server” refers to both the AGIE service layer functions and theAMQP transport layer functions. The AGIE Service Layer contains all the AGIEunique messaging functions. The AMQP Layer contains the transport functions aswell as any built-in AMQP services being directly utilized. AMQP functionality isdescribed in Section 4.6.4.Server messaging functionality is defined at message origination, during messagetransfer, and after delivery (status reporting and logging). Message delivery includesstore-and-forward capability which may result from not having access to thedestination client, destination client’s home, or destination client’s host. Storedmessages are automatically delivered when next target node becomes reachable.Aircraft based server connectivity is dynamic with respect to the ground AGIEsystem. Only aircraft servers are dynamic. Dynamic means that they may not beconnected 100% of the time, and their routing varies as does QoS and performance.Ground servers are not dynamic. They always are reachable using sameaddressing and routing (subject to admin configuration changes). Further groundside servers are considered “pervasive” or “always on.” The ground-side of AGIE iscalled the “Main AGIE” which is defined as having access to the “Primary” serverand all fixed Client Homes.COMMENTARYThe preceding statements do not mean implementations are required toguarantee that ground-side connectivity are both pervasive and fixed;however, managing any dynamics of the ground-side of AGIE is not part ofthe AGIE standard.Only a dynamic aircraft server may request “server association”. Server associationis always with the Main AGIE network via the Primary. This server association istriggered by either new paths between the onboard Primary or by the onboardserver booting up and establishing air-ground connectivity. The association isalways requested by the onboard server. Ground servers may never initiate anassociation due to security concerns.

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 57The onboard server makes a request for association with a function hosted on thePrimary. The Primary responds by setting up the association at the AGIE serviceand AMQP layers. It then updates all of the onboard databases required foroperation. Clients provide message segment status via their host. After the onboardserver is synchronized with the Main AGIE and ANS is updated, stored messagesare transferred and the clients on both ends are notified of the new accessibility.The latter is accomplished using the onboard temporary Home server and theground side Home server. The new accessibility is updated as applicable throughoutthe distributed AGIE Name Service.There are four logical types of message servers:1. Message Origination Server2. Message Destination Server3. Current Message Client Host Server4. Client Home Server4.6.2.1.1 Message Origination Host Server TasksThe message origination server is the host of the client that initiates messagesending at the time of the message service invocation. The origination serverinitiates message transfer. The following are key attributes and tasks of this server:1. Obtains the XML message from the client via AMQP2. Validates the message request (security and admin parameters)3. Determines destination targets4. Obtains destination target addresses5. Obtains path options to the destination6. Selects the best path for transport7. Sets message transmission priority8. Builds coordination messages with payload9. Is always reachable by the originating client after association.If the destination client is hosted by the same AGIE server and AMQP broker, thenthe message is delivered immediately and directly. If the destination client is not onthe same server or AMQP broker and not on the same onboard sub-network then itis routed to the client’s home server. If the client’s home server is not reachable andthe origination server is onboard, then the message is routed to a temporaryonboard home server. If the client home or temporary onboard home is notreachable and the host is not an onboard server, the service request is failed.The origination server accepts immediate reporting and status responsibility for themessage. However, when the message is successfully handed off to the next target(interim or final destination) in line, it also hands off the reporting responsibility to thenext server.The origination server is responsible for making the coordination message asefficient as possible. It reduces message header size by using the pre-defined andpre-shared coordination message templates. It also invokes XML compression asapplicable between adjacent AMQP nodes.

ARINC PROJECT PAPER 830 – Page 584.0 AGIE FUNCTIONAL SPECIFICATION4.6.2.1.2 Message Destination Host Server TasksThe destination server is the host server of the destination client. The host may befixed to a client or may be the temporary host of a mobile client. Clients are notalways reachable from the host, such as when they are not associated with a host.Even fixed clients may not be reachable all the time, such as when the client isturned off or the network is down. Mobile client hosts are defined by currentassociation and may change hosts.The destination server receives messages from the origination host, home server, orPub-Sub service on Primary. This server then forwards the message to client. Whenthe client is not reachable, the message is stored by the destination server. Aftersuccessfully receiving the message, this host takes the reporting responsibility.Upon successful (or some failure conditions) delivery to the client, the destinationhost initiates automated reporting and logging per message declarations.4.6.2.1.3 Current Message Client Host Server TasksThe current message client host server is the host of the message originating clientduring message status reporting. After sending a message, a mobile client maychange hosts. Therefore, automated reporting and later arriving status messagesare mapped to the new host. This server becomes the report destination. It alsofunctions as the originating host of post-service invocation status requests.4.6.2.1.4 Client Home Server TasksThe client home server is an interim server between clients on different AGIEservers or AMQP brokers. All non-direct message delivery is staged through thedestination client’s Home. This reduces the naming and addressing overhead byproviding a persistent and fixed client location for mobile client addressing.The client home server is assumed to be on the Primary. This is logical and is notphysically required. What is required is that all client home servers be pervasive andfixed as to addressing and routing and are assumed to be on the Main AGIEnetwork. There should never be the need for more than one air-to-ground hop ofany air-ground message.Home server stores all waiting messages. It messages reachable clientsimmediately and non-reachable automatically when they become reachable. Itperforms automatic synchronizing with onboard temporary home server when anaircraft becomes reachable. Key client home server characteristics:1. Required for ALL clients.2. Must be pervasive and fixed (on Primary)3. Location defined by the admin in configuration4. Supports all messaging services5. Maintains a list of messages and notifications for non-reachable clients6. Automatically serves messages and notifications when client becomesreachable7. Automatically synchs with temporary onboard home server when reachable8. Accepts reporting responsibility for messages it stores4.6.2.2 Message StorageOne task of the servers is to store messages waiting for delivery to the finaldestination. Generally the following types of servers perform this message storagefunction:

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 591. Client Home Server2. Message Destination Server3. Onboard Temporary Home ServerFigure 7Figure 6 shows the message storage logic associated with determiningmessage storage location. Stored messages are automatically forwarded when thedestination becomes reachable. This is further described as follows:1. Messages with immediate reachable destination client (on same AGIEserver or AGIE onboard sub-network) are immediately delivered todestination client (not stored)2. Messages with immediate reachable destination server (on same AGIEserver or AGIE onboard sub-network) but not reachable to destination clientare stored on destination server3. Messages with reachable Home then destination client are immediatelydelivered (not stored)4. Messages with reachable Home then destination host only (client notreachable) are stored on destination server5. Messages with reachable Home but not reachable destination host arestored on Home6. Messages onboard without reachable Home or reachable onboarddestination server are stored on temporary onboard HomeFigure 76 – Message Storage Concept

ARINC PROJECT PAPER 830 – Page 604.0 AGIE FUNCTIONAL SPECIFICATION4.6.3 Primary and System FunctionsAGIE defines functionality to permit admin to manage its configuration andinfrastructure in general. The associated AGIE functions exist on the Primary serveror temporary onboard Primary only.4.6.3.1 Root AGIE Name Service FunctionsAGIE name service functions perform AGIE node name (ID) and address resolution.The service has its root at the Primary. It coordinates with other local distributedANS servers which support defined AGIE sub-networks. It provides AGIE serversinformation on how to reach each node in the AGIE system. It also maintainssystem-wide path information. Details of ANS functionality are found in Section 4.5.AGIE name service interface is defined in Section 6.4.6.3.2 Publish-Subscribe Server FunctionsThe Pub-Sub server resides on the Primary. An overview of functions is found inSection 4.4. The function performs the following tasks. The Pub-Sub interface isdefined in Section 6.1. Receives, processes client subscription requests2. Stores subscription requests3. Receives published messages4. Sends published messages to subscribing clients.This function receives requests from AGIE nodes to subscribe to a topic viapredefined coordination message. A topic is simply a string and may be dot notatedand contain wildcards to allow the subscription to match multiple and evolvingtopics. Topic and subscription strings are parsed by AGIE functions. Section 4.5discusses AGIE string parsing details. The function processes the subscriptionrequest and matches all existing topics. A response coordination message is builtwith a list of matching topics. Once topic resolution is completed, there is no notionof this function automatically re-appraising the request; the initial matching topic listis fixed until an admin directed system configuration update triggers a reassessment.Subscriptions with node ID are stored for each topic. A subscription request may bea cancel request, which functions that same through parsing but removes the nodeID from the topic subscription list. The request may also be an update request,which re-parses the string and maps to current topics for that subscriber.The function acts like a client receiving a message. The message is a standardAGIE message addressed to the Pub-Sub client, though it must contain a “Topic”field. The Pub-Sub function maps the string parameter to topics using AGIE parsingalgorithm. Again, it may match it to multiple topic lists due to wildcards. Themessage is sent to each subscriber in each of the topic(s) list as if it came directlyfrom the publisher as a one-to-many message using push or pull as appropriate.4.6.3.3 Configuration Database Distribution FunctionsConfiguration database distribution function distributes AGIE databases (generatedby admin) to any/all AGIE nodes in the AGIE system as appropriate. This functioninitiates on the Primary, but has receiving functionality resident on each AGIEserver. This function is used to send all configuration data throughout AGIE. Section6 defines the standard databases. Additionally operators may add their own nonstandarddatabases. This function may be used to distribute any data from Primaryto AGIE nodes (not limited to databases only).

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 61This function receives a database update from the admin client. The coordinationmessage lists the target nodes, database type and the data. The database updatemay be a full replacement or an update containing only changes (insertions,deletions, modified entries). It may be time tagged for initial applicability to allowprecise system-wide database synchronization.The Primary distributes the databases to the nodes using standard AGIE messagingservices. The local database function receives and stores the database updates onthe Primary. Depending on database activation process, it will cause the databaseupdate to be completed and trigger when it becomes operational. It reports status ofdatabase updates back to admin. The function may also request a database beretrieved from a remote server, via the Primary and send to the admin client forinspection.When a node (AGIE detached sub-network) associates with the Main AGIE network,an immediate task is to synchronize current databases with the Primary. ThePrimary may accomplish this by pushing the latest databases, requesting serverconfiguration, or internal tracking system configuration tracking. The latter being themost efficient, but most complex.AGIE does not define implementation requirements, but requires configuration databe confidential and protected from its creation through deployment and use, seesecurity requirements in Section 4.7.4.6.3.4 AGIE Logging FunctionsAGIE logging functions allow any AGIE node to log an event. AGIE logs areassumed persistent, though AGIE does not require persistency. If persistency isimplemented, it is a function of AMQP durability. This function has an “AGIE Log”client that acts like any other AGIE client and receives incoming messages. Logentries are contained in a predefined coordination message type. This functionforwards the message to a logging application, which may be addressed to a defaultlog function or sub-addressed, by Application ID (such as “Security Log”) to alogging sub-function. The function provides persistency of the log entry via AMQP.The log application is outside of AGIE scope. The external application is responsibleto store, retrieve, process, delete and otherwise manage the logs.Logging data on the aircraft is expensive; therefore, it is assumed that all possiblelogging is via a ground application, though this is not required. The concept of acascaded logging function is permissible and recommended. Implementation shoulduse an onboard temporary Home with persistency as temporary log storage serverwith all permanent logging on ground.Interim message server processing with store-and-forward services must beexamined in implementation as potential locations of lost logged events. AGIElogging should use the “check point” option.4.6.3.5 Admin FunctionsThe admin client and association functions are important to AGIE operations andsecurity. The admin client is required and must be named “AGIE Admin”. Admincapabilities are described in various sections throughout this document and deriverequirements on many AGIE functions. AGIE admin functions include the basicAGIE admin client, which is a standard AGIE client but with super-user privileges.Other AGIE functions include an external AGIE Admin Application, and a PrimaryDatabase Distribution function.

ARINC PROJECT PAPER 830 – Page 624.0 AGIE FUNCTIONAL SPECIFICATIONThe AGIE admin client must be hosted in a protected environment on the ground onthe Primary server. It (and no other client) has back-end access to the AdminApplication. It has visibility to ALL AGIE nodes, services, and functions across allisolated and sub-networks. The external admin application is not defined. However,AGIE admin data must be protected from creation through distribution. See securityrequirements in Section 4.7.The aspects of the Database Distribution function is hosted on all AGIE servers. ThePrimary hosts the origination function which has direct connection to the adminapplication. The remote servers host database receiving and reporting functions.4.6.3.6 Isolated Network CommunicationA “Cross Network Bridge” function provides for routing and messaging between twoisolated AGIE networks. This function is fully under admin configuration and control.It is hosted on the Primary and acts as an intermediary for routing messagesbetween isolated AGIE networks.This function looks like an ordinary client to nodes on each network, though visibilityto it is restricted by default. It functions like two back-to-back clients with a bridge inbetween. Admin provides specific nodes permission to send messages “to nodes onother isolated networks by providing visibility to the “Cross Network Bridge” client.Admin also sets the root level ANS visibility parameters to define which nodes cansee which other nodes on other isolated networks. How the applications obtain theclient ID is left to implementation.The bridge client sends a message to the destination client on another isolatednetwork in a normal manner. However, the local AGIE name server cannot resolvethe destination name as it is not allowed visibility to nodes on other networks. Thiswould normally cause a failure. However, since cross network visibility is allowed,the message is forwarded to the bridge client for cross network naming andaddressing.The bridge client receives the message. It uses the root ANS to resolve the name(which has visibility to all nodes in the entire AGIE system). If the root ANS hasbeen configured to allow the originating client to see the destination client then itresolves the address; otherwise, it fails the request and returns failure status. If thename was resolved by the root ANS, then the bridge client sends the messageusing normal AGIE messaging to the destination and any reporting and statusreverses the process. TODO: discuss this approach.4.6.3.7 Primary Redirect FunctionThe Primary hosts an association redirect function. This function allows a client torequest association using an unsecure session between it and the Primary to obtaininformation necessary to request a “best” and “secure” association. This allows theuse of simple (or out of date) client association software on mobile clients. It alsoallows the Primary to maintain control and management logic for mobileassociations.This function is a standard host association function with one additional feature. Ithas built in logic that recognizes that the Primary is either not the best host or notallowed, as well as the logic determine the best host. It parses the Client Attributesfield in the association request. This is just a string parameter. It selects the “besthost” using an implementation defined selection process. It denies the associationand returns the best host address to the client in the Better Host field. It may provideother information, such as security parameters needed to initiate the securesession, in the Association Attributes field.

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 634.6.3.8 AGIE Compaction FunctionAGIE pre-shares coordination message templates to reduce header size via aprocess termed “Compaction”. The compaction algorithm must be defined forinteroperability. The algorithm performs three tasks. First, it processes the XMLtemplate when a new coordination message type is created (or modified). It createsa share-able skeleton template that contains the full structure with all fixed fields laidout and placeholders for variable data. Second, it processes each coordinationmessage before it is sent leaving only the data necessary to fill in the skeleton as acompact message. Third, it rebuilds the message at the receiving end, interleavingthe skeleton and compacted message to make the original.TODO: define this algorithm/tool. This should be an industry standard that alreadyexists for submitting efficient XML forms across the Internet.4.6.4 AMQP FunctionsAMQP provides functions and services for securely transporting messages acrossIP networks. It also provides ancillary functions useful for implementing AGIE tasks.It is assumed that an AGIE client and AMQP client as well as, AGIE server andAMQP broker are co-located and integrated by developer. Also, assumed is thatmost AMQP level functional interfaces are standard within AMQP.AGIE shall provide AMQP functions:1. Set up and initialize AMQP client2. Set up and initialize AMQP broker3. Attach AMQP client to its AGIE client4. Attach AMQP broker to its AGIE server5. Attach AMQP broker to other visible AMQP brokers6. Manage AMQP client to AMQP broker communications7. Manage AMQP broker to AMQP broker communication8. Manage AMQP client to AMQP broker security (TLS)9. Manage AMQP broker to AMQP broker security (TLS)10. Process topics for publish-subscribe messages (in consideration and trade)11. Provide for message persistence (in consideration and trade)12. Transporting messages between AGIE and AMQP13. Setting network and AMQP queue prioritization14. Implementing AGIE directed path selection15. Managing message time out16. Providing status and reporting (failure, success, etc…)17.18. TODO: James to verify correct list, etc.The AGIE client-AMQP client and AGIE server-AMQP broker interfaces transportXML files between adjacent AGIE and AMQP components using secure TLStransport mechanism. It is assumed that these elements are co-located, that is, neareach other, and that they are integrated by developer. Therefore, interoperability isnot an issue and not further defined in this standard.

ARINC PROJECT PAPER 830 – Page 644.0 AGIE FUNCTIONAL SPECIFICATIONAGIE server-AMQP broker interface provides bi-directional and secure messagesharing between the AGIE server and the AMQP broker. Received messagehandling is straight forward as incoming messages are provided to AGIE server todeal with. Sending messages is a bit more complex interface as AGIE has a desireto set some messaging sending parameters controlled by AMQP. The interfaceallows AGIE to map messages to predefined AMQP queues. It also allows forprioritization within AMQP queues and may invoke special AMQP advancedservices to handle specific AGIE features built into AMQP (segmentation, security,multi-destinations, etc…).AMQP client-AMQP broker interface exchanges messages bi-directionally andsecurely using TLS. This is assumed to be accomplished by basic AMQPfunctionality. Interoperability is required at the AMQP level to allow separatedevelopers to implement the client and the broker.At this time there are no known interoperability issues. However, when differentAMQP implementations are used, issues will arise and will be defined as bestpractices or captured here as requirements.AMQP broker-AMQP broker interface exchanges messages bi-directionally betweenbrokers securely using TLS. This is assumed to be accomplished by basic AMQPfunctionality. Interoperability is required at the AMQP level to allow separatedevelopers to implement the different brokers in the system.At this time there are no known interoperability issues. However, when differentAMQP implementations are used, issues will arise and will be defined as bestpractices or captured here as requirements.4.7 Security RequirementsThe security requirements are defined by internal and external requirements.Internal requirements are on AGIE functions and capabilities, and are definedbelow. Expected behavior or security requirements on external functions are definedin Section 5.6.4.7.1 Internal Security RequirementsAGIE servers shall only accept messages from other authorized AGIE clients andservers, using a “white list” approach. This is under operator admin configuration.At each message hand-off, the receiving AGIE nodes shall accept messages thatare correctly formed. Non-correctly formed messages shall be dropped and asecurity event logged.AGIE security-relevant events shall be logged using standard log format defined inthe specification.Air to ground AGIE path creation shall only be initiated by an aircraft AGIE node(client or server).AGIE servers and clients shall only transfer messages within a TLS v1.2 (or later)session.Mutual authentication using digital certificates shall be usedMessage encryption may be usedAMQP peers shall specify TLS session establishmentPublic key certificates used for authentication should comply with the profiles in ATASpec 42. Also, additional guidance can be found in ARINC Report 842.

4.0 AGIE FUNCTIONAL SPECIFICATIONARINC PROJECT PAPER 830 – Page 65AGIE node configuration files shall be protected to prevent unauthorizedmodification.AGIE control and coordination data (messages, headers, configuration files) shallnot be exposed to unauthorized or external access.

ARINC PROJECT PAPER 830 – Page 665.0 AGIE OPERATIONS5.0 AGIE OPERATIONSAGIE operations are carried out by the operator. The operator may be an airline oran airline working with a third party AGIE service provider. Operations includesetting up the AGIE network connectivity and installing AGIE components, alsoestablishing and maintaining AGIE configurations, messaging parameters, securitysettings and enforcement, and managing AGIE databases. Throughout thedocument the “admin” references operator interaction with AGIE. TODO: committeeto get operational member input to completeness of section 5.Operation of an AGIE system implementation is fully in the control of the operator’s“admin.” This is due to the fact that AGIE is data driven. Distributed AGIE databasescontain the full system configuration. The admin manages client and server lists,sets bounds of client-server associations, configures clients to address potentialAGIE hosts for association, and defines an AGIE Name Server topology.While operation of an AGIE system is not a direct specification requirement, thestandard is written with operational assumptions and expectations. These arewritten as operational requirements and stated as either “operator shall” or “adminshall.”AGIE admin functions map to two major categories.1. AGIE system configuration and IT functionsa. Creates AGIE system configuration datab. Loads AGIE system configuration datac. Builds client configuration and visibility tablesd. Builds mapping between AGIE and network and NMFe. Defines AGIE topology (AGIE Name Servers, Primary functions)f. Defines AGIE Main network and isolated sub-networksg. Defines priority for messages, clients and mapping to IP layerh. Builds and distributes AGIE configuration databasesi. Defines AGIE name space and naming conventionsj. Determines requirements for domain separationk. Builds connection profiles and maps them to datalinks via onboardnetwork managerl. Defines and sets up best path tablem. Defines maximum system message sizen. Defines defaults for messaging attributes by messaging serviceo. Sets up and manages Primary server functionsp. Sets up and manages the cascaded AGIE name servicesq. Sets up AGIE security implementationr. Defines and manages message typess. Defines defaults for messaging attributes by message typet. Defines reporting and logging defaults2. Daily operations and control functionsa. Manages AGIE logsb. Defines publish-subscribe topics and determines when a refresh isneededc. Manages real-time network and data transaction issues

ARINC PROJECT PAPER 830 – Page 675.0 AGIE OPERATIONSd. Processes AGIE security events and logse. Troubleshoots messaging problems related to delivery, performance andcostf. Monitors AGIE system performanceAdmin interfaces with AGIE through built-in “AGIE Admin” and “AGIE Log” clientsand admin functions on Primary. AGIE admin operations are ground-basedfunctions. Admin manages the ground-side of AGIE using airline IT processes andthe onboard elements using remote AGIE admin access or aircraft softwaremanagement processes (out of AGIE scope).5.1 System SetupAn initial AGIE operational task is setting up an AGIE system. Setting up AGIEpresumes that the following are accomplished prior to operation. All of thesefunctions are out of AGIE scope:1. Onboard LANs are set up for onboard AGIE servers and clients to accessoff-board datalinks2. Ground based airline IT (or similar) network setup with firewalls, networking,and computing3. Establishing acceptable IT security procedures and processes4. Establishing Internetworking access between the ground-based computershosting AGIE ground nodes and onboard computing hosting onboard nodes5. Installing AGIE infrastructure components on computing resources6. Installing a Primary server on ground with all required Primary functions7. Setting up infrastructure IP services, routing, and addressing at networklayer8. Loading appropriate IP DNS tables to allow AGIE clients to find hosts9. Installing and configuration AMQPA properly installed AGIE system will have at least one server on the ground,hosting all required Primary functions and client Home servers. Only after AGIE isproperly installed does system configuration occur. Setting up the systemconfiguration involves admin setting policies (external to AGIE) then building all ofthe necessary AGIE databases and distributing them to AGIE nodes. AGIEconfiguration is database driven. The AGIE databases (mostly flat files) drive allaspects of AGIE management and control. Maintaining these databases andensuring they are properly secured and distributed is AGIE configurationmanagement. AGIE required databases are defined in Section 6.The operator shall set up AGIE configuration using the confidential AGIEconfiguration databases in a manner consistent with secure AGIE systemoperations.Admin designs and implements the desired topology for the implementation. Thisinvolves setting up AGIE networks, AGIE sub-networks, and isolated AGIEnetworks. This involves connecting static AGIE nodes to each other via AMQPbroker configuration and by setting up the client and server node lists at the AGIEservice layer. Admin also bounds dynamic aircraft server associations by predeterminingallowed connectivity between the Main AGIE network and the onboardAGIE networks and informing the underlying networks of this potential connectivity.

ARINC PROJECT PAPER 830 – Page 685.0 AGIE OPERATIONSAdmin configures the Primary server with all required functions, such as root ANS,client Home server, AGIE admin and AGIE Log clients, and Pub-Sub service. Adminsets the maximum size limit for small messages which determines whensegmentation will take place. Admin then defines acceptable detached AGIE subnetworkcapabilities and limits. This involves configuring a cascaded ANS withonboard local ANS, onboard Primary server, and temporary onboard Home server.Admin sets logging policy by configuring AGIE Log client(s), developing the desiredAGIE Log Application, and by declaring which nodes have access to persistentstorage.Admin determines partitioning requirements for domain separation given thecriticality of applications being supporting along with other known operationalfactors. This involves setting visibility limit policies and implementing them whencreating client, client-type, message type, and other database entries. If theimplementation requires isolated AGIE networks, then they are defined along withthe Cross Network Bridge client and function on the Primary. Then, cross-networkvisibility is set into each allowed client and in the appropriate ANS servers.Prior to a client associating with a host server, it must be provided the address of anacceptable host. IP host addresses may be built directly into client software or IPnames may be used as long as access is provided to an IP Domain Name Service(DNS). Standard IP DNS may also be used by mobile servers to set up dynamicconnections to the Main AGIE network but this is left to implementation. AGIEassumes the Main AGIE network of fixed nodes is pervasive and static. If it isdetermined that public IP DNS is not secure, or it is too complex to provide thedesired security to all mobile clients, admin may require some or all clients toassociate via Primary redirect function using a more secure session.5.1.1 AMQP Setup and ConfigurationTODO: James and AMQP team add operational aspects of setting up andconfiguring AMQP.Mapping AGIE priorities to IP TOS/Diffserv code points is accomplished duringAMQP setup. Considerations include: terrestrial links, airline IT networking design,datalink prioritization capabilities, and AGIE traffic in context with other non-AGIEtraffic on the links and networks.5.2 Configuration ManagementAGIE admin is responsible for configuring and managing AGIE system-wideconfiguration. Admin shall manage, maintain, distribute and protect all requiredAGIE configuration databases.Generally, admin maintains all of the configuration and databases described inSection 6. AGIE system configuration is built outside of AGIE. Systemconfigurations are input into the AGIE system via the admin client on the Primary asAGIE configuration databases. After the admin updates a configuration with one ormore database updates, it pushes the updates to the Primary database service. Thedatabase distribution function distributes the databases throughout the AGIEsystem. The admin determines when the new configuration becomes valid and howthe updates are synchronized. Local AGIE Primary services trigger thesynchronized database updates as requested by admin.Admin manages publish-subscribe topic lists using the Pub-Sub Topic database.While the topic list may be updated at any time, it is a separate admin function todetermine when to trigger the Pub-Sub function to re-compute client subscriptionbindings to the topics. This is a command to the Pub-Sub function that is not defined

ARINC PROJECT PAPER 830 – Page 695.0 AGIE OPERATIONSin this standard, but could be employed as follows. Topic subscription requests arestrings. These may be stored by the Pub-Sub function, then automatically reparsedwhen the topic list updates, resulting in up-to-date subscription-to-topic bindings.Further, it is also up to implementation if the updates warrant client notification of theresulting subscription changes.Admin creates all the desired message types. Each operator defined message typeis developed using XML templates that are pre-shared with applicable AGIEservers. The templates provide for compaction. Building these templates includesdetermining default reporting for the message type. This augments the basicreporting defaults defined for each message service offering. This is also true toauto-logging defaults.The operator shall manage the Primary server and protect it from external (nonadmin)viewing and corruption.The admin shall configure the system to ensure the following connectivityrules/conventions are strictly adhered to:1. A client always initiates a connection/association with a server2. An onboard server always initiates a connection/association with a groundbasedserver.3. A ground-based server never initiates a connection/association with anaircraft based server4. Ground server-server connections are static5. Connection between two onboard servers is only initiated by the non-Primaryservers6. A ground based clients never initiate association with an aircraft basedserver5.3 Operational AGIE Naming ConsiderationsOperator names every AGIE node and client. This is accomplished by setting thename in the AGIE node and building the client and server ID databases. SeeSection 4.5 on AGIE built-in naming functionality.5.3.1 Operational Naming RequirementsThe operator shall name all AGIE servers uniquely across the AGIE system. Clientnames may be replicated if there is no chance that two clients with the same namewill attempt association on a single server. The operator shall provide the followingclients “AGIE Admin,” “AGIE Log,” and “Cross Network Bridge” named exactly asshown.5.3.2 Suggested Naming PracticesThe specification provides requirements for naming features. Implementation andnaming practices are left to the operator. Below are some suggested conventions.Onboard servers should have reference to aircraft ID “N1234.” Fixed device clientsshould include their function, title, or name such as “FOQA” or “dispatcher.” Mobileclients associated with a specific user should include their user name, i.e., “JohnDoe,” while mobile clients associated with a crew or operator position should includetheir title, i.e., “Pilot,” “Flight attendant,” or “Maintenance.”

ARINC PROJECT PAPER 830 – Page 705.0 AGIE OPERATIONSIt is most efficient for devices, such as an EFB which hosts multiple applications ona single device, to share a client with the device’s name. Individual applications areidentified by the “Application ID” field and should be named for the appropriateapplication function. They are replicated across devices.Examples of fixed client replicated names:Name = “adl” for airborne data loaderID is replicated on each aircraft“adl&+” – this aircraft server only“adl” – all on this AGIE network“adl&N1234” – on “N1234” server, this AGIE network only“adl&N1234&UA” – on “N1234” server, “UA” AGIE network“adl&*&UA” or “adl&&UA” – all on “UA” AGIE network“adl&*&+” or “”adl&&” - all on this AGIE network“adl.*&+” – all on this network (e.g., “adl.left” & “adl.right”)“adl&*N1234” – all servers ending with “N1234” (e.g., “ACD.N1234” &“AIS.N1234” & “N1234”)Examples of unique user names: Name = “John.Doe” is unique user name in network “John.Doe” – all on any server this AGIE network “John.Doe&&*” – all any server in any AGIE network Returns one if unique across all system Returns multiple if only unique across network Name = “John.Doe.user” “*.user” – all ID ending with “.user” (addresses all users) Guarantees user IDs unique from other IDsExamples fixed unique ground names. Name = “dispatch” is unique user name in AGIE network “dispatch” – all any server in this AGIE network (one ID) “dispatch&&*” – all any server in any AGIE network “dispatch&&UA” – all on UA AGIE network5.4 Operational Priority ConsiderationsAdmin determines AGIE priorities. AGIE functional priority mechanisms are definedin Section 4.4.4. The admin sets up the configuration parameters and databasesthat control these built-in functions. This allows the operator to manage prioritiesacross AGIE, including function processing, queuing prioritization, and preemption.Admin sets up prioritization parameters (value or range) in each message type orclient-type, and for each message service. Prioritization supports a range of optionsfrom background to immediate messaging. Admin sets up both “NORMAL” and“URGENT” priority mapping as well as “USER” priority mapping. The vast majorityof traffic should be managed as normal traffic.Admin defines what constitutes a background message. This allows the admin tominimize cost and QoS impacts of sending unimportant (time criticality) messages,

ARINC PROJECT PAPER 830 – Page 715.0 AGIE OPERATIONSespecially large ones, by leveraging long-term scheduling. Background capabilitiesinclude the ability to hold a message until specified time or condition exists.Examples would be only allowing transmission over ground datalinks, meteringtraffic during phase of flight, or sending only over a lower class of service.Admin manages the priority mapping to the underlying IP network via AMQPconfiguration.5.5 Operational Path ConsiderationsAGIE paths are logical connections between AGIE servers. They are abstractconnections, not IP routes. They are defined by AMQP broker to AMQP broker links.Aside from just providing connectivity, paths have known or planned quality ofservice and performance metrics. AGIE assumes the critical segment of a path isthe air-to-ground link, which is managed by onboard network management. Pathsare modeled by their pre-determined profile or “connection profile.”The operator shall configure the onboard network management function to notifythe onboard AGIE server of all new and lost datalink connectivity, which includesproviding the best connection profile name for the new connection. While theconnection profiles are logical, it is likely that the admin will have a very directmapping to either physical links or classes of physical links. Examples mediumsinclude Gatelink, satcom, cellular and terrestrial services.The onboard AGIE name service shares newly created (and if possible, recentlylost) paths with the Primary’s root level AGIE name service to allow system-wideaccess between onboard and ground clients. This allows the managing of link trafficby connection profile. Admin loads the connection profiles for each onboard serverusing the Connection Profile Database, defined in Section 6.AGIE selects the appropriate path for each message based on the best pathselection algorithm, defined in Section 4.3.3.1. It is driven by an admin lookup tableprovided by loading the Best Path Selection Table Database, defined in Section 6.Admin sets up the table to allow AGIE’s path selection function to perform theappropriate selections. The table maps selection parameters to available connectionprofile names in priority order.5.6 Security and PartitioningThe operator sets up and manages AGIE security in the context of overall missionsecurity objectives. AGIE is just a service in the larger air-to-ground messagingcontext. Messaging security involves many tasks that are outside of AGIE scopeand are handled at the physical, network and application layers. AGIE as a servicein the application layer defines security requirements for AGIE components as wellas expectations on external functions. The security approach is laid out in Section2.5 and AGIE and internal requirements are defined in Section 4.7.Below are expected activities and characteristics of non-AGIE functions that areoutside of the specification scope. They are under operator control andmanagement. This standard has been developed based on these assumptions.They should be considered external requirements. The operator shall ensure thefollowing security capabilities are implemented:1. Logged security events are monitored for indications of security breaches2. AGIE system administrator roles and functions are properly managed andcontrolled

ARINC PROJECT PAPER 830 – Page 725.0 AGIE OPERATIONS3. AGIE system administrators are properly authenticated and authorized usingmethods stronger than name/password4. Security policies and procedures exist and are adhered to5. Regular security audits are conducted to ensure compliance6. Applications are adequately secured7. Networks are adequately secured and partitioned8. IT systems are physically secure9. User and device access is managed and controlled10. AGIE administrative data is protected when handled and stored outside ofthe AGIE system11. AGIE server network interfaces perform filtering of anomalous network traffic12. Unauthorized access to the aircraft is blocked on the ground side13. Off board connections are not initiated from the ground5.6.1 Operational PartitioningAGIE has built in features that allow multiple types and levels of partitioning.Partitioning is separating system capabilities or elements into isolated or separatedsub-systems or networks. This standard is written with the assumption that AGIEsupports applications that have been operationally mitigated to “minor hazard” orbelow. The standard does not preclude AGIE implementations that supportapplications above “minor hazard”; however, care must be taken in such animplementation to ensure the implementation meets the minimum set ofrequirements for those operations.AGIE’s primary partitioning features provide for operationally defined, “provabledomain separation.” Partitioning is only a requirement when certification or approvalrequires it. Some implementations will require very little, if any, AGIE partitioning.AGIE partitioning features consider the following:There is no requirement to implement partitioning in all implementationsNo requirements in this standard preclude partitioningStandard defines potential areas that may be partitionedStandard provides built-in partitioning featuresPartitioning, if carefully used, should not add unnecessary overhead tomessage transmissionsStandard is written to allow a single AGIE system to simultaneously supportapplications in all three aircraft operational domains via admin managed partitioningprocedures. Partitioning rationale includes the following:Ground clients do not need to see aircraft servers for any reasonACD clients do not interact with PIES clientsInternet clients only access airline IT servers, never the aircraftNo client needs the actual address or location of another client (or server)Adding partitioning features add to AGIE overhead, therefore it is desirable topartition only when and what is necessary. This also approach maximizes sharing ofresources (e.g., hardware, DSP links, networks, physical ports). However, it isdesirable from a security perspective to limit visibility of nodes that do not, and willnot, need access to other nodes and/or functions. The required level of partitioningmust be determined by the operator during system definition. Partitioning may be

ARINC PROJECT PAPER 830 – Page 735.0 AGIE OPERATIONSphysical (e.g., separate servers, networks, connections) or logical (e.g., separatevisibility), data oriented (by message type) or even layered/mixed. The appropriateamount and level of partitioning needed is based on operational business case andcertification/operational approval requirements for the specific implementation(intended use of functions and end-applications). The best approach to determiningpartitioning design is to 1) define areas of partitioning that match AGIE features, 2)perform the necessary security analysis, and 3) determine cost penalties based onusing those selected features. This may be an iterative process.AGIE supports the following are areas and methods of partitioning in a single AGIEsystem.1. Server partitioning using physically separate computing resources or serversor AMQP brokers2. AGIE network partitioning using isolated AGIE networks to limit node accessto other nodes, allowing cross network communication only as defined by theadmin and only on the secure Primary server3. Data partitioning with separate link access and/or link usage restrictions.Limits on client access or visibility by client-type and/or message type5.7 Use Case OverviewUse cases are provided to allow the operator to comprehend what uses AGIE hasbeen defined to facilitate. They are listed by user and operational service provided.These are included to allow high level understanding of driving AGIE use cases.The AGIE Use Cases paper (referenced in Section 1.4) provides detaileddescriptions of defined use cases.5.7.1 User Application Use CasesThese are use cases that provide value to applications using AGIE for applicationto-applicationmessaging services. Below are use cases for message senders andmay have complex interactions with more than one AGIE messaging feature:a. Send small message to another clientb. Send large message to another clientc. Send message notification to another clientd. Send small message to multiple other clientse. Send large message to multiple other clientsf. Send message notification to multiple other clientsg. Publish message to topic for publish-subscribeThese are sub-use cases to those above based on unique AGIE features:a. Immediate message deliveryb. Immediate message failurec. Direct delivery to client on same AGIE serverd. Indirect delivery to client on different AGIE serverse. Store-and-forward via Home when no destination accessf. Temporary store-and-forward onboard when no Home accessg. Temporary store message at destination server when no access todestination client

ARINC PROJECT PAPER 830 – Page 745.0 AGIE OPERATIONSh. Send message at high priorityi. Send message at low priorityj. Send message in background priorityk. Link selection by priority and link costl. Delay message waiting for acceptable link costm. Segment large messages for deliveryn. Addressing message to specific application via application Ido. Select transport such as secure FTB (if feature is specified)p. Push or pull for notification deliveryThese are sub-messaging use cases based on potential several security andefficiency features:a. Send messages within AGIE networkb. Send messages across isolated AGIE networksc. Limited client visibility in isolated networksd. Limited client visibility by admin settingsThese are use cases for messages receivers:a. Receive messageb. Receive message notificationc. Pull waiting messaged. Send message statusThese are use cases are for managing messages:a. Request sent message statusb. Receive message status (auto, by request, at time out)c. Modify sent message priorityd. Modify sent message time-to-live (may kill)e. Subscribe to topicf. Un-subscribe to topicThese are system and service use cases:a. Ping a client to see if it is reachable with acceptable costb. Set call back for when a client becomes reachable with costc. Ping Primary Server to get system status and link qualityd. Log system evente. Find AGIE server for associationf. Associate with AGIE serverg. Un-associate with AGIE server5.7.2 Infrastructure Use CasesThese infrastructure use cases support AGIE support services.a. Command client un-associationb. Connect dynamic (mobile) server to AGIE networkc. Synchronize newly accessible nodes (client message waiting queues, serverdatabases)

ARINC PROJECT PAPER 830 – Page 755.0 AGIE OPERATIONSd. Add new connection between serverse. Remove connection from AGIE serverf. Receive database updates from Admin Applicationg. Send database updates to AGIE nodesh. Activate database updatesi. Request status of AGIE node or connectionj. Receive status of AGIE node or connectionk. Message send request has no destination failurel. Server or broker startup or restartm. AGIE node DNS accessn. Implementation unique databases and update features

ARINC PROJECT PAPER 830 – Page 766.0 AGIE PROTCOL INTERFACES6.0 AGIE INTERFACESThis section describes key AGIE and AMQP interfaces required for implementingfunctions and features defined in Section 4 and the operational capabilities andcontrols described in Section 5. AGIE interfaces provide functional component andlogical peer communication. AGIE service level interfaces take the form of XMLbasedmessages, XML defined coordination messages, and XML defineddatabases.Peer level AGIE interfaces are described in this section, which provides high leveldescription of the interface as well as semantics involved in how the interface isused in operation. Appendix D provides a detailed definition in XML definition orsyntax for each interface.Component level interfaces are not defined in this section. AMQP functionalinterfaces are discussed in Section 4.6.4. Other functional interfaces are discussedin the appropriate sub-Section of 4.6. These component interfaces are implementedas software interfaces. Many of the low level interfaces are left to implementation.The primary user interface is the “Application Interface” definitions are kept assimple as possible. They are defined using XML templates with a single interface ineach direction, to and from application. The user payload is opaque to AGIE andAMQP. While application interfaces are never compacted or compressed, serverservermessages are always compacted and optionally compressed to nonreadable,non-standard XML files. Figure 6-1 shows these interfaces.Figure 6-1 - AGIE and AMQPAGIE and AMQP interfaces:1. Application–application End-to-end messaging2. Application–AGIE client XML interface3. AGIE client–AGIE server XML interface

6.0 AGIE PROTOCOL INTERFACESARINC PROJECT PAPER 830 – Page 774. AGIE server–AGIE server Coordination messages5. Application-AMQP client Functional AMQP client interface6. AGIE client–AMQP client Functional AGIE–AMQP interface7. AMQP client–AMQP broker Functional AMQP interface8. AGIE server–AMQP broker Functional AGIE–AMQP interface9. AMQP broker–AMQP broker Functional AMQP interfaceFigure 6-1 shows both peer and component interfaces. Peer interfaces consist ofXML based messaging and database exchanges, including defined coordinationmessages. Section 6.1 describes the XML interfaces, Section 6.2 describescoordination messages and Section 6.3 describes coordination databases.6.1 XML InterfacesAGIE clients interface with their applications and host via simple XML files. Thisapproach keeps the application-client interface simple, and the client-host secureand relatively free of client configuration updates. This works well given theassumptions that the application, client, and host are considered to be in closeproximity to each other (however, not an actual requirement).There is no dedicated and defined application-to-application interface. This peerlevel interface is logical. The syntax is made up of the two application XMLinterfaces. While semantically, all AGIE and AMQP messaging services make upthe operational aspects. this interface at applications appears as the application-toclientand then the client-to-application interfaces, respectively, though finalapplication mapping may include an Application ID if directed by originatingapplication.The Application-to-Client XML and the Client-to-Host XML templates are nearlyidentical as are the Client-to-Application XML and the Host-to-Client XML templates.Therefore, the same template is used for both interfaces in the same direction to orfrom the application. Some of the template fields are not visible to the application,while all are visible to the host and client.6.1.1 Application-to-Client-to-Host InterfaceApplication-to-Client-to-Host interface supports two sets of services. First,applications request AGIE host services via client, and second automated clientfunctions directly request AGIE host services. A single XML template is defined tocover both sets of services.These services are initiated by an application:1. Send message2. Pull message3. Manage message4. Manage subscription5. Ping status of client or Primary with QoS6. Log eventThese are initiated by AGIE client:1. Request association with host2. Request un-association with host

ARINC PROJECT PAPER 830 – Page 783. Acknowledge4. Log event6.0 AGIE PROTCOL INTERFACES6.1.1.1 Application-Client-Host XML DescriptionThis section describes the key fields and uses (semantics) of this interface.Appendix D contains the syntax in XML format.TODO describe this interface.Considerations include:1. Fragmentation instructions2. Directions for handling attachments6.1.2 Host-to-Client-to-Application InterfaceHost-to-Client-to- XML interface also supports two sets of services. First, host sendsdata to application via client, and second host sends data directly to client functions.A single XML template is defined to cover both sets of services.These are initiated by the host and forwarded to the application:1. Forward received message2. Forward ping response3. Forward message management response4. Forward manage subscription response5. AcknowledgeThese are initiated by host for AGIE client functions:1. Server response to association request2. Server request un-association with client3. Acknowledge6.1.2.1 Host-Client-Application XML DescriptionThis section describes the key fields and uses (semantics) of this interface.Appendix D contains the syntax in XML format.TODO describe this interface.Considerations include:1. Re-assembly instructions6.2 Coordination MessagesCoordination messages provide the server-server communications at peer levelthroughout AGIE. They communicate between AGIE server functions and AGIEbuilt-in clients. AGIE service level interfaces are peer-to-peer logical interfacesimplemented as coordination message defined in XML templates. They shareinformation and/or provide control between two non-adjacent AGIE service levelcomponents.Peer-level interfaces are defined as XML with a single template for eachcoordination message type. Each coordination message type may serve one ormore coordination functions, so the mapping between coordination functions andcoordination message types is not one-to-one. An operational tradeoff must be

6.0 AGIE PROTOCOL INTERFACESARINC PROJECT PAPER 830 – Page 79made between a large number of coordination messages and complexity andoverhead of fewer more complex ones.AGIE pre-shares coordination message templates to reduce header size via AGIECompaction. Compaction results in an additional skeleton template for eachcoordination message. These are auto-generated and temporary and not definedhere. Optionally, the entire message may be compressed to further reduce bit count.This feature is not defined in this version of the standard but is left to implementationbetween adjacent AMQP brokers.Operators may add implementation specific coordination messages for advancedfeatures or to streamline their implementation. These use standard AGIE messagingfeatures, with perhaps added security protection.The following are interfaces between AGIE servers.1. Send message to server (compressed)2. Receive message from server (compressed)3. Forward ping status request4. Received ping status response5. Forward manage subscription request6. Receive manage subscription request7. Forward manage message request8. Receive manage message request9. Acknowledge server request10. Log event11. AGIE name server request12. AGIE name server response13. Synchronize with Primary14. Update Primary AGIE name server (paths, associations)15. Add server connection16. Remove server connection17. Dynamic server association request18. Dynamic server association replyTODO map each service interface to specific message type in Section 6. There isnot likely a one-to-one mapping but re-usable server-server coordination messagefor most?6.3 Coordination Database DefinitionsMany of the interfaces are best viewed and defined as databases that are sharedacross servers and hold configuration data for AGIE network. They are shared usingdatabase distribution services. These services provide for sending full databases orupdates, as well as for database synchronization. This section provides a top-leveldescription of all AGIE required operational databases. They are compacted andmay be compressed for transmission.TODO: list each database here and fully define belowAGIE provides the following basic AGIE databases:

ARINC PROJECT PAPER 830 – Page 806.0 AGIE PROTCOL INTERFACES1. Clients DB2. Server DB3. Current associations DB4. Connection profiles DB5. Current paths DB6. Message types DB7. Best Path Selection Table DB6.3.1 Client DB DefinitionTODO define databaseAttribute fields:1. Client name or ID2. Client type3. Visibility list4. Host list6.3.2 Server DB DefinitionTODO define databaseAttribute fields:1. Server name or ID2. Server type3. Function list4. Host list5. Server clients (associated and fixed)6. Address7. AGIE-AMQP binding6.3.3 Current Associations DB DefinitionTODO define databaseThis is a Primary server database.Attribute fields:1. Host list2. Clients per hosta. Client IDb. Association status6.3.4 Connection Profiles DB DefinitionTODO define databaseThe following are the parameters contained in the connection profiles. TODO scrubthis list and define in Section 6.Connection profile nameOverall QoS factor (integer)Bandwidth (very low, low, medium, high, very high) if asymmetric then eachway

6.0 AGIE PROTOCOL INTERFACESARINC PROJECT PAPER 830 – Page 81 Link quality (high, medium, low, off) Guarantee (safety service, AIS, PIES differentiated, PIES plain) Cost (low, medium, high) Latency (high, medium, low)Attribute fields:1. Profile name2. Overall QoS factor (integer)3. Bandwidth (very low, low, medium, high, very high) if asymmetric then eachway4. Link quality (high, medium, low, off)5. Guarantee (safety service, AIS, PIES differentiated, PIES plain)6. Cost (low, medium, high)7. Latency (high, medium, low)6.3.5 Current Paths DB DefinitionTODO define databaseAttribute fields:1. Server ID2. Profile list6.3.6 Message Types DB DefinitionTODO define each database listedThis database contains a list of message types and pointers to the XML templates.Attribute fields:1. Message type name2. Message class (user, coordination)3. Pointer to XML template4. Pointer to template6.3.7 Best Path Selection Table DB DefinitionTODO define database and provide some examples, see Section 4.3.3.1 for details

ARINC PROJECT PAPER 830 – Page 82APPENDIX AGLOSSARY OF TERMSAPPENDIX A GLOSSARY OF TERMSThis appendix describes AGIE terminology and forms a system glossary.A-1 AGIE TermsAGIE StandardARINC Project Paper 830 documentAGIE SystemImplementation of AGIE standard, which consists of the collection of AGIE nodes,and associated databases and configurationStatic AGIE SystemIn AGIE system, the list of clients and servers is static as are most server-serverassociations and must be in the primary server’s databasesA-2 Network TermsAGIE NetworkStatic set of all AGIE servers and their instantaneous connectivity. This is theinternal core of an AGIE implementation (server-to-server).AGIE Sub-networkA defined subset of one or more connected of AGIE servers and their connections.Aircraft sub-network may be disconnected from AGIE Main Network, functionsautonomously with associated clients, contains a local AGIE Name ServerCentral AGIE NetworkMain AGIE networkDisconnected Sub-networkAGIE aircraft sub-network that does not have a path to the Main Network (Primaryserver)Flat AGIE NetworkAGIE server connectivity where the only topologies supported have only two serversbetween any two clients and only one server between any client and Primary (Mainor aircraft)Isolated NetworkAGIE network is divided into partitioned or “isolated” networks which all reside oncommon implementation but support separate virtual networks Isolated networks by partitioning servers and limiting client visibility e.g., create ACD, AIS, PIES networks Supports admin limited cross-network access via PrimaryMain AGIE NetworkMain component of AGIE Network that contains the Primary Server (on the ground)A-3 Interoperability TermsAdmin Interoperability

ARINC PROJECT PAPER 830 – Page 83APPENDIX AGLOSSARY OF TERMSAirline or operators of system with nodes developed independently are managed bycentral site seamlessly by central admin facilities and results are nominal and asexpected.AGIE InteroperabilityCapability for AGIE nodes not developed for the implementation to interoperate witheach other.Application InteroperabilityApplications designed to the AGIE standard operate as expected on multiple AGIEimplementations without code modification.Server InteroperabilityServers built by two developers independently operate seamlessly across the AGIEsystem without code modification or complex integration (aside from admin setup).A-4 Components TermsAGIE ApplicationAGIE system application, such as log or admin, which is similar to an externalapplication but has end-to-end security and super privileges (often called justapplication).AGIE FunctionAGIE capability hosted on an AGIE server or occasionally on AGIE client. Serverhosted functions are accessed similar to client using function ID instead of client ID.ApplicationTypically non-AGIE software that uses the AGIE client to send and receivedata/messages and may be multi-threaded or may be multiple applications tied to asingle client.Associated ClientIs connected to an AGIE server.ClientSoftware that implements AGIE client interface and is registered as part of the AGIEsystem.Client TypeDefines the type or class of user associated with clientUser defined by adminAssociated with client access for partitioningMay extend/limit access to: profiles, servers, AGIE networks A client supports one or more software applications and is not tied tohardware implementation (i.e., EFB is hardware specific)Fixed Client

ARINC PROJECT PAPER 830 – Page 84APPENDIX AGLOSSARY OF TERMSIs statically assigned to specified AGIE serverMobile ClientIs able to dynamically attach to one of the AGIE servers in clients’ accessibility listNodeAGIE server or AGIE clientReachable ServerThere is an acceptable path between Originating server ando Destination server for one stage messageso Staging server for two stage messages Staging server and destination server for second stage of message deliveryReachable ClientThe destination server is reachable and the destination client is associatedA-5 Server TermsAGIE ServerSoftware that implements AGIE server defined functions Servers can be:AGIE Name ServerProvide addresses and available paths for clients (like IP DNS lookup)Dynamic ServerAGIE server that supports dynamic associations to Primary server, typically aircraftserverFixed ServerGround server with fixed associations relative to Primary serverHome ServerAGIE server that provides one or more clients “Home” services for storing waitingmessages while the client is not reachablePrimary ServerHolds central knowledgeMessage Destination ServerHost server of message destination clientMessage Origination ServerHost server of message originating clientMessage Staging ServerInterim storage server for messages

ARINC PROJECT PAPER 830 – Page 85APPENDIX AGLOSSARY OF TERMSSecondary ServerPrimary server backupA-6 Messages TermsImmediate MessageMessages that get high priority and synchronous response for success or failure Does not imply any real-time performance in hard numbers How: set urgent, receipt requested, and time-out to zero Will immediately fail before transfer if destination client is not reachableLarge MessagesDefined by operator for force segmentation Maximum system message size = defined by operator, as upper limitMessage ClassCoordination (control messages) or Standard (application data messages)Message Service5 defined message services:1. Point-to-point small messages2. Point-to-point large data3. Reliable point-to-multi-point small messages4. Reliable point-to-multi-point large data5. Publish-subscribeMessage TopicOperator managed description of a sub-set of message types for use with publishsubscribeMessage TypeOperator managed description of message types:Used to define a class or group of messages where messages of a type(objects) are related to the message type (class) with commoncharacteristicsDefines meta-data for all messages of the typePublish-SubscribeClient pushes/publishes message onto AGIE network to staging server, clientssubscribe to message topic; when a new message is published, subscribing clientsare either notified and retrieve message or get pushed message from Pub-SubserverUses Message Topic

ARINC PROJECT PAPER 830 – Page 86APPENDIX AGLOSSARY OF TERMS Supports late binding (operational decision at run-time)PullClient pushes message destination clientSmall messagesDefined by operator, nominally do not require segmenting for all/most links Define for each connection/path profileStore-and-ForwardClient pushes message onto AGIE network, storing data on an AGIE server, thenforwarding to client when availableA-7 Connectivity TermsAssociationConnection between two AGIE nodes that enables operational data traffic flowClient AssociationAssociating client with serverConnectionPath or route between two AGIE serversPaths between AGIE servers:o Are always IP routeso May be more than one path between any two AGIE servers Paths between client and its host server:o May be via an AGIE connection (IP route)o Physical connection via Ethernet (on same LAN)o Inter-process communication (port/socket on same OS)Connection profileStatic container that holds typical link service and performance parameters for that“type” of path/comm link (assumed to be comm link limited)Dynamic pathsPaths that have at least one dynamic link segment to a dynamic or mobile server Not always available to AGIE network Variable availability, bandwidth, performance Between air-ground AGIE serversLinkCommunication link (physical) provided by Datalink Service Provider (DSP)PathA connection between two AGIE servers with a valid IP route There may be more than one path between AGIE serversPath profile

ARINC PROJECT PAPER 830 – Page 87APPENDIX AGLOSSARY OF TERMSInstantiation of connection profile for an active link/path for an AGIE serverServer AssociationAssociating two servers via a connectionStatic pathsFixed with known QoS parameters Usually terrestrial networks between fixed AGIE serversRouteIP route not part of AGIE, but part of network configurationA-8 Priority TermsAGIE PriorityDesignation that a message should be handled “urgent” or in “normal” modeUrgent messages should be handled before normal messagesPriorities are linked to message size and message servicePriorities logically map to server processing, ports, queues, and threads andcan be associated with:User PriorityOptional field in message type definition that allows the operator to refine priorityand provides for higher fidelity mapping to underlying network and connectionA-9 ID TermsAGIE IDsAGIE names for address resolution Must map to unique name-address space for name resolution for each clientAGIE Name DescriptorsProvide name and address information for AGIE nodes (clients and servers)Three part name withClient IDServer IDNetwork IDID separator “&”Example: for airborne data loader “adl&N1234&united”o Client ID = “adl”o Server ID = “N1234”o Network ID = “united”Application IDsAGIE allows clients to support multiple concurrent applications

ARINC PROJECT PAPER 830 – Page 88APPENDIX AGLOSSARY OF TERMS Application IDs are managed by application for multi-threaded applicationoperations (multi-socket)Replicated IDNames that are replicated in the AGIE system/network and are only uniquelyaddressed when combined with Host Server IDUnique IDNames guaranteed unique by operator adminA-10 Misc. TermsDSPDatalink Service Provider is air-to-ground ISP that provides an air-ground IPconnection to AGIEISPTerrestrial Internet Service ProviderOperatorAn airline or other AGIE service provider that is operating an AGIE systemimplementation

ARINC PROJECT PAPER 830 – Page 89APPENDIX BAGIE OPERATIONAL THREADSAPPENDIX B AGIE OPERATIONAL THREADSThis section defines the operational threads listed in Section 3.7.B-1 Application ThreadsThese are threads invoked by end user applications.B-1.1 Application#1 Send Message Thread1. Operationa. Name: send message thread for messaging between applications orfunctions; supports user and coordination messagesb. Initiated by: originating application or AGIE node functionc. May suspend waiting to reach next destination2. Objectivea. Send message using one of the AGIE messaging servicesb. Application to send a message to another application via XML interfacec. AGIE nodes to send coordination messages from AGIE system clients orfunctions (via binary interface)3. Notesa. Complex thread that supports many operational options and featuresb. Supports all message servicesc. May send to multiple recipientsd. May push or pull (send or notify)e. May segment messagef. Supports store-and-forwardg. Uses Client Home or Temp Home as temporary storeh. Supports immediate messagingB-1.1.1 Thread1. Application invokes AGIE client message serviceNote: this is the application message entry point for standard XMLbased user and coordination message services1. Sends XML message service request to client2. After client processing2. Client processes message request1. AMQP receives message in inbound queue1. Sends message to AGIE client service2. AGIE client services processes message request2. Validates application service request3. Fills in initial fields in message header4. Forwards message to AMQP broker3. AMQP transports the message1. Accepts message in client’s AMQP inbound queue

ARINC PROJECT PAPER 830 – Page 90APPENDIX BAGIE OPERATIONAL THREADS2. Routes message to host server inbound queueNote: Interface and all other messages are via client XML interface3. Origination host finishes building messageNote: this is the entry point for compressed XML messages fromAGIE functions1. AMQP broker1. Receives message in incoming queue2. Enqueues incoming message in server inbound data queue2. AGIE service1. Validates XML message request(1) Validates request is well formed(2) Validates message fields with base message type(3) Validates request is allowed (address, message type, etc…)(4) Validates time to live2. Sets appropriate fields in XML message header (priority, TTL, etc…)3. Origination host becomes responsible for reporting4. Removes the message from inbound data queueNote: For coordination messages originated by server functions,incoming message is likely compressed and in coordinationmessage format, not plain XML, and submitted via functionserviceinterface. All other messages are via client XMLinterface.4. Originating AGIE host process target client list1. Parse destination client list from XML message2. If message is Pub-Sub, then1. Set destination as Pub-Sub function2. Set to push and other Pub-Sub service parameters3. Go to #53. Else if a single destination, then1. Set point-to-point service parameters2. Got to #54. Else if multiple destinations, then1. Set point-to-multi-point service parameters2. For each destination in list(1) Create a separate delivery thread for each destination(2) Go to #5 for each destination(3) Delete message and clean up after all threads launched5. Else (no destinations found), then1. Go to#7 with failure “no destinations”5. Perform local AGIE Name Server lookup1. Query Local Name Server for destination

ARINC PROJECT PAPER 830 – Page 91APPENDIX BAGIE OPERATIONAL THREADS2. If destination found on local server or both onboard same aircraft subnetwork,then (direct)1. Set to push2. Set to no-segmentation3. Send message direct to destination4. Go to #143. (Else – not local) Client’s Home is destination1. Get client’s Home address from local ANS6. If destination is not reachable, then1. If “immediate message” or not on aircraft server then1. Go to #7 with failure “Home unreachable”2. Else go to #87. Origination server fails request1. Report fail request to client via coordination message2. Client reports failure to application via XML3. If point-to-multi-point and some destinations ok, then1. End sub-thread for this destination with (partial) failure4. Else (no destinations ok)5. End thread for this destination with failure8. If destination is not reachable, then1. If on aircraft then Aircraft temporary Home processes message1. Store message via AMQP2. Temporary Home takes reporting responsibility3. Suspend thread waiting for client’s main reachable Home4. Restart thread when Home becomes reachable5. Aircraft temporary Home synchs with Main Home6. If applicable, segment message (algorithm needs to be defined)7. Set to push8. Send message to Home via AMQP9. Removes message from queue10. Inserts message in AMQP outgoing queue11. AMQP broker sends message to client’s Home inbound queue9. Main Home processes message1. Home AMQP broker receives message in inbound queue2. Home takes over reporting responsibility3. Validates message is well formed10. If destination is Pub-Sub service, then Home forwards message to Pub-Subfunction1. Pub-Sub function takes over processing2. Pub-Sub takes reporting responsibility

ARINC PROJECT PAPER 830 – Page 92APPENDIX BAGIE OPERATIONAL THREADS3. Build destination client list from subscribers list for each destination in list(via AMQP subscriptions and topic)1. Create a separate delivery thread for each destination and continue11. Final destination processing1. Query Primary AGIE Name Server for destination2. If destination not found or not reachable, then1. Store message2. Suspend thread/sub-thread waiting for target host to becomereachable3. Resume thread/sub-thread when target becomes reachable12. If message is pull, then send message to destination1. Store message2. Build message notification message for destination13. Send message or notification to destination1. Ensure message format is still valid2. Insert each segment or entire message in AMQP outgoing queue3. AMQP sends message to its destination’s incoming queue14. Destination server processing1. AMQP receives message in incoming queue2. Validates message is still valid3. If destination is function1. Map and forward message to server function2. Function takes over processing3. End thread (coordination function message)4. Else (destination is client): If client is not-reachable, then1. Suspend thread waiting for client association2. Resume thread when client is reachable5. Insert message in AMQP outgoing queue to client6. AMQP sends message to client’s incoming queue15. Client processes message1. AMQP receives message in incoming queue2. Determines the message is still valid3. Unwraps compressed/compacted message4. Converts message to XML version5. Re-assemble message as necessary (waiting for complete message)6. If complete message1. Forwards message to application over application ID interface2. Report delivery status to host16. Application receives message or notification17. End of Delivery – (message or notification)Note: For messages terminating in server functions, it is assumedthe resultant coordination message is consumed by function

ARINC PROJECT PAPER 830 – Page 93APPENDIX BAGIE OPERATIONAL THREADSvia function-service interface and any follow up or reporting ishandled via a separate thread.18. Destination server processes end of delivery19. If required logs, then1. Build status log coordination message2. Send message to log client20. If status not requested, then1. End thread/sub-thread21. Build delivery status coordination message1. Build status coordination message22. Send to responsible server1. Insert message in AMQP outgoing queue2. AMQP sends message to responsible server’s incoming queue23. Responsible server (Home or Pub-Sub) collects status reports1. AMQP receives message in incoming queue2. If one-to-many, then1. Add this destination delivery status2. If more destinations to report, then(1) End this destination sub-thread24. Deliver report to origination client1. Build final status coordination message2. Set to no reporting (ensure no recursion)3. Set origination client as destination4. Go to #3B-1.2 Application #2 Pull Message from Server Thread1. Operationa. Name: pull message from storage (not local host) threadb. Initiated by: application or AGIE node functionc. Trigger: End system received notification of waiting message anddetermines to pull itObjectivea. Allow application or function pull message after notification whenmessage is on a distant AGIE server (Home or Pub-Sub)Operationsa. Pull messageb. Delete message (not wanted by application)Inputs/outputsa. Message ID and storage locationOperational usesa. Allows applications to determine if and when they pull a waiting messageor delete it without incurring delivery cost

ARINC PROJECT PAPER 830 – Page 94APPENDIX BAGIE OPERATIONAL THREADSB-1.2.1 Thread1. If application request, then1. Application makes client pull message request1. Client builds pull message request coordination message(1) Includes message ID and storage address (Home, Pub-Sub)2. Submits pull message request over XML interface3. Invokes App#1 thread2. Else (function request)Note: this is database entry point1. Function builds pull message coordination message1. Includes message ID and storage address (Home, Pub-Sub)2. Submits pull message request over binary interface3. Invokes App#1 thread@step#33. Storage server sends message to host1. Storage function on message storage server receives coordinationmessage in incoming AMQP queue2. Set appropriate parameters in message (push, etc…)3. Sends message to destination by invoking App#1 thread@step#34. Host reports status as required by invoking App#1 thread@step#20B-1.3 Application #3 Manage In Transit Message Thread1. Operationa. Name: Manage, control or status in transit message threadb. Initiated by: originating application or AGIE server function2. Objectivea. Allow a message originator to request status, modify priority, or kill an intransit message and return notification and log if applicableb. Operationsi. Kill message with delete and clean upii. Get status of message and leave in queueiii. Update priority (modify queue or path selection)c. Operational usesi. Allows external and AGIE applications and server functions to kill,expedite, or get status on in transit messagesB-1.3.1 Thread1. If application request, then1. Application makes manage message request via XML1. With message ID, destination, op (kill, change priority, status)1. Client builds XML message request for host1. Builds XML message2. Inserts message in client’s AMQP outgoing queue3. AMQP sends message to its host’s inbound control queue2. Else (function)

ARINC PROJECT PAPER 830 – Page 95APPENDIX BAGIE OPERATIONAL THREADS1. Function makes manage message request1. With message ID, destination, op (kill, change priority, status)2. Builds manage message binary coordination message3. Inserts message in client’s AMQP outgoing queue4. AMQP sends message to its host’s incoming queue3. Host finishes building message1. AMQP receives message in incoming queue2. Fills in fields in coordination message3. Validates message information and format4. Host determines responsible server1. May be Temp Home, Home, or origination server – direct delivery only2. If message was direct (destination on this server) and destination Homenot reachable, then1. This server is responsible server3. Else if message was direct and destination Home is reachable, then1. Destination Home is responsible (handed off responsibility)4. Else if non-direct and destination Home not reachable, then1. Temp Home on aircraft is responsible5. Else destination Home is responsible5. Host sends message to responsible server1. Invokes App#1@step#36. Responsible server processes message1. Responsible reporting function receives message from AMQP queue2. Build manage message response coordination message1. Set parameters (no reporting, priority, etc…)2. Address to requester3. If message kill request, then1. Delete message and cleanup2. Set delete status in coordination message4. Else if change priority, then1. Pull message from queue2. Make necessary priority updates3. Resubmit message in AMQP queues4. Set priority changed status in coordination message5. Else current message status6. Set message status in coordination message7. Send status message invoke App#1@step#3B-1.4 Application#4 Request AGIE Ping Thread1. Operationa. Name: request status for AGIE node or application thread (also calledping)

ARINC PROJECT PAPER 830 – Page 96APPENDIX BAGIE OPERATIONAL THREADSB-1.4.1 Threadb. Initiated by: application or AGIE node function2. Objectivea. Provide applications and AGIE functions ability to determine networkconnectivity, AGIE node, and application access status3. Approach is to make AGIE Name Server request to another nodea. Accepts minimum QoS requiredb. Accepts optional flags include: notification requestc. Returns status of node or failure mode: 1) success or 2) failuredue to no access to main network, destination server, client, 3)other QoS link exists (with connection profile names)d. May spin off AGIE status update response thread4. Operational usesa. Application or function requests status of/access to a client or applicationwith minimum QoS requiredb. Function requests status of/access to server or checks networkconnectivity to Primary with minimum required QoSc. Call back eliminates constant polling for updated access1. If application initiated, then1. Application requests AGIE ping to destination client via XML interface2. Client makes request to server/host1. Builds XML message with destination and QoS2. Inserts message in client’s AMQP outgoing queue3. AMQP sends message to its host’s incoming queue2. Else (function or AGIE application)1. Builds status request coordination message with destination and QoS viacompressed interface2. Inserts message in functions AMQP outgoing queue3. AMQP sends message to its host’s incoming queue3. Host finishes building message1. AMQP receives message in incoming queue2. Validates message and format with valid parameters3. Build coordination message “ping response”4. If found on local server via ANS lookup, then1. Fill in success parameters to client in ping response message2. Go to#85. Else if no access to Primary and no call back request, then1. Fill in failure parameters in ping response message2. Go to#86. Else if no access to Primary and call back requested, then1. Suspend thread waiting for access to Primary2. Resume thread when access to Primary continue7. Forward request to Primary ANS

ARINC PROJECT PAPER 830 – Page 97APPENDIX BAGIE OPERATIONAL THREADS1. If address found, then1. Fill in success parameters in ping response message2. Go to #82. (Not found) If no call back request, then1. Fill in failure parameters in ping response message2. Go to#83. Else (call back requested) then1. Suspend thread waiting for access to Primary2. Resume thread when access to Primary3. Fill in success parameters in ping response message8. If successful access to client, then1. Make application ping coordination message response with success9. Return address and status via status invoke App#1@step#3B-1.5 Application#5 Log Event Thread1. Operationa. Name: log event through AGIE logging interface threadb. Initiated by: application, client or server function2. Objectivea. Provide all AGIE components with common method and interface forlogging events3. Approacha. Use standard log interface with client/function ID “log”b. May have multiple log clients (i.e., “security.log,” “message.log”)c. Use standard or user defined log message typesd. Admin flags message types for logging (message, attachments, status)e. Address using standard names: “log” for local server log, “log&Primary”for log on primary server, etc...f. Naming allows logging on ground vs. aircraft to reduce costsg. Uses store-and-forward message sendingh. AGIE log client accepts standard AGIE log messages addressed to itslogging interface and passes them to external (non-AGIE) function forpersistent store via client interface to undefined application4. Operational usesa. Allows logging of events in multiple named logs using standard AGIEclient interface and log message type formatsb. Aircraft server may auto-route messages to ground storagec. Assumes small message, background priority, single stage, point-topointrouted to ground client (not required)B-1.5.1 Thread1. If originating requestor is application, then1. Application invokes client log message service

ARINC PROJECT PAPER 830 – Page 98APPENDIX BAGIE OPERATIONAL THREADS2. Sends request via XML to client3. Client processes message request1. Validates client request2. Creates XML message of log message type3. Fills in initial fields in message request4. Adds payload to log message5. Inserts message in client’s AMQP outgoing queue6. AMQP sends message to its host’s incoming queue2. Else function initiated1. Function builds log coordination message type2. Inserts message in AMQP outgoing queue3. AMQP sends message to host’s incoming queue3. Origination host finishes building message1. AMQP receives message in incoming queue2. Validates message request1. Validates request is well formed2. Validates message fields with base log message type are legal3. Sets appropriate fields in message header (priority, etc…)4. Host sends coordination message to log client via App#1@step#35. Log application processes in persistent storageNote: When invoking App#1 thread and there is any temporarystorage, it is assumed the availability or persistent storage intransit is accomplished outside of AGIE.B-1.6 Application#6 Manage Message Subscription Thread1. Operationa. Name: manage message subscription by message type and topic threadb. Initiated by: application2. Objectivea. Provide application with capability to subscribe or unsubscribe tomessage topic3. Operationsa. Subscribe or unsubscribe to a topic4. Inputs/outputs uses Pub-Sub subscription coordination messagea. Accepts subscription request5. Operational usesa. Allows application to select what topics it wishes to subscribe to or endsubscription requestb. Topics are strings which can be processed using dot notation andwildcardsc. Message type and message parameters determine push or pullB-1.6.1 Thread1. Application requests Pub-Sub subscription update

ARINC PROJECT PAPER 830 – Page 99APPENDIX BAGIE OPERATIONAL THREADS1. Includes op (subscribe or unsubscribe) and wild card topic string2. Invokes client message service by sending XML request to client2. Client processes message request1. Validates client request2. Creates XML message of Pub-Sub subscription message type3. Fills in initial fields in message request4. Inserts message in client’s AMQP outgoing queue5. AMQP sends message to its host’s incoming queue3. Host finishes building message1. AMQP receives message in incoming queue2. Validates message request1. Validates client request is well formed2. Validates message fields with Pub-Sub subscription message type3. Validates client’s request is allowed (address, message type, etc…)3. Sets appropriate fields in message header (priority, etc…)4. Host sends message to Primary Pub-Sub function via App#1@step#35. Primary processes Pub-Sub coordination message request1. Receives the coordination message from AMQP2. Builds Pub-Sub response coordination message3. If subscribe to topic request, then1. Expands target (wild card string)2. Looks for all matching topics3. Adds client to subscription list for those topics4. Adds all new subscriptions to coordination message4. Else if unsubscribe request1. Removes application from publication list for topic2. Adds unsubscribe success to coordination message5. Sends Pub-Sub response message by invoking App#1@step#3B-2 Client ThreadsThese are threads invoked by AGIE client.B-2.1 Client#1 Associate Client with AGIE Host Thread1. Operationa. Name: client with AGIE host threadb. Initiated by: client2. Objectivea. Allow client to find best AGIE host and associate with it3. Triggera. Likely client automatically invokes this thread on startupb. Client re-attempts association by polling or is triggered by non-AGIEfunction (likely based on updated network status)

ARINC PROJECT PAPER 830 – Page 100APPENDIX BAGIE OPERATIONAL THREADSB-2.1.1 Thread4. Operationsa. Find an AGIE hostb. Associate with best hostc. Updates AGIE Name Serverd. Pulls or pushes stored messages on Home and/or destination host5. Inputs/outputsa. Client is configured by software with AGIE Name Server list of availableAGIE host Names that the client is authorized to associate with (list isordered best first) which have entries in IP DNS or equivalent IP addresslookup6. Operational usesa. Mobile clients may associate on ground or in aircraftb. Uses standard IP Name Server capabilities1. Client is triggered to initiate association by outside source (applicationsoftware, device boot up, etc…)2. Get authorized AGIE host list for client1. Client list is best first mapping of AGIE servers and IP names3. While more in list1. Make top entry “best host”2. Request IP address of best host from IP DNS (or equivalent)3. If found and reachable go to#54. If none found then failed to associate1. End thread5. Client sends association request to host1. Build association request message via XML interface2. Send request to AGIE server association function by secure TCPsession6. If host refuses association, then1. Host notifies client of failure via XML interface over secure TCP session2. Go to #3 (next best host)7. Host makes association1. Exchanges association parameters with client via secure TCP session2. Builds host-side of association3. Host sets up AMQP mapping to client (client connect string)4. Notify Local AGIE Name Server of new association5. Local ANS updates Primary AGIE Name Server6. Build new association coordination message7. Send coordination message to Primary ANS function by invokingApp#1@step#38. Host pulls waiting messages1. Host notifies Home (or Temp Home) of new association2. Build pull message coordination message

APPENDIX BAGIE OPERATIONAL THREADSARINC PROJECT PAPER 830 – Page 1013. Send coordination message by invoking App#1@step#39. Temp Home/Home function resumes sending each waiting message byresuming thread at App#1@step#810. End threadB-2.2 Client#2 Un-associate Thread1. Operationa. Name: un-associate client or host threadb. Initiated by: client or host2. Objectivea. Allow clean un-association of client from an AGIE host and application(close all sessions, etc…)3. Triggera. Client requests un-association (client or application driven)b. Host requests un-association4. Operationsa. Close sessions, flush queues, break lower level connectivityb. Updates AGIE Name Server system5. Operational usesa. Allows client, host or application to communicate it is leaving theassociationb. Allows quick (no timeouts) updates of client status throughout the AGIEsystemc. Allows cleanup of network and transport layer connectionsd. HOWEVER, AGIE works (perhaps less efficiently) if association is justlost and no un-association is requestedB-2.2.1 Thread1. External event triggers determination of client or host to break association1. Application shuts down (e.g., mobile leaving network or device shuttingdown or user logging off), OS command, etc…2. If client-side request, then1. Client notifies host via un-associate XML message2. Builds un-associate XML message3. Sends coordination message via App#1@step#33. Host processes un-association message request1. Notify local AGIE Name Server of association status change viacoordination message via App#1@step#31. Local ANS notifies Primary ANS via forwarding the coordinationmessage via App#1@step#32. Terminates association4. Client terminates association1. Informs applications of un-association by tearing down application IDsessions

ARINC PROJECT PAPER 830 – Page 102APPENDIX BAGIE OPERATIONAL THREADS2. Cleans up client parameters3. Ends associationB-3 Server ThreadsThese are threads invoked by AGIE server.B-3.1 Server#1 AGIE Node Ping Response Thread1. Operationa. Name: respond to pending “ping” status request from unfulfilled pingthreadb. Initiated by: AGIE Name Server2. Objectivea. Response to a latent request for a status update by an application orAGIE node when AGIE status changes3. Triggera. AGIE status change triggers event (new association or path)4. Inputs/outputsa. Returns same values as Application#4 “Ping” thread5. Operational usesa. Allows application or server to wait on trigger vs. continual polling forconnectivity update and destination access changeB-3.1.1 Thread1. Trigger is AGIE Name Server is informed of new access to AGIE nodes(association or path created)2. AGIE Name server sends new status update to Primary and Aircraft Primaryserver3. If on onboard then1. Check Temp Aircraft pending ping list2. Sees if new association matches pending ping destination3. If yes, then returns ping status report1. Builds ping status report coordination message2. Sends coordination message via App#1@step#33. Delete pending request4. End thread4. Primary checks pending ping list1. See if new status allow matches pending ping destinations2. For each pending ping request1. Check AGIE Name Server access to destination2. If found then(1) Build ping status report coordination message(2) Send coordination message via App#1@step#3(3) Delete pending request3. End thread

APPENDIX BAGIE OPERATIONAL THREADSARINC PROJECT PAPER 830 – Page 103B-3.2 Server#2 Process expired messages Thread1. Operationa. Name: process expired messages threadb. Initiated by: server responsible for message2. Objectivea. Respond to message expiry by deleting message, notifying originatingclient, and if applicable, generating a log entry3. Triggera. Message in server queue times out4. Inputs/outputsa. Sends message status to originating client if applicableb. Logs message and status if applicable (invokes log event thread)5. Operational usesa. Cleans up message queues when message times outNote: A variation on this thread will be needed to clean up manydifferent temporal queues and databases, such as pendingping timeouts, Pub-Sub duration, etc… These are not listedas major threads at this time and are left to implementation tosort out (should not require interoperation or interfaces to bedefined).B-3.2.1 Thread1. Destination server periodically exams messages in queue for expiration1. For each expired message inform responsible server1. Delete message from AGIE queues2. Build status coordination message3. Set time out or failure to deliver4. Send coordination responsible server by invoking App#1@step#32. A clock triggers examination of messages in pending queues onstorage/responsible server3. Server examines each message for expiration4. For each expired message1. Delete message from AGIE queues2. Set message deleted/time out status1. Build status coordination message2. Set time out or failure to deliver3. For one-to-many messages, add individual destination delivery statusto coordination message4. Send coordination message to originating client/function by invokingApp#1@step#3B-4 Network Management ThreadsThese are threads invoked by non-AGIE network management function.

ARINC PROJECT PAPER 830 – Page 104APPENDIX BAGIE OPERATIONAL THREADSB-4.1 NMF#1 Manage Connections Thread1. Operationa. Name: manage connection threadb. Initiated by: network management function (e.g., MAGIC)2. Objectivea. Provide an interface for AGIE to build manage paths from NMFconnections updatesi. Supports new or removed connectionsii. Distributes static path profilesiii. AGIE provides interface to network management functioniv. NMF notifies nearest aircraft AGIE server of new or lost connectionsv. AGIE maps these connections to paths using available path profilesvi. GIE distributes path profiles to local and Primary AGIE Name Server3. Operational usesa. Provides an AGIE defined interface to undefined NMF functions thatbuild network layer connections and provide network layers status fornewly created or lost connectionsb. Nearest server on aircraft maintains path profiles for accessing itc. Primary maintains path profiles to accessing all nodesd. Static path profiles were distributed using database distributionB-4.1.1 Thread1. NMF function calls AGIE path update function on aircraft Primary on pathstatus change via XML interface over secure TCP session2. If remove path is requested, then1. Path profile is removed2. Local ANS is updated1. Local ANS updates Primary ANS(1) Builds path update coordination message2. Set removed path and applicable parameters3. Send message to Primary ANS function via App#1@step#33. End thread3. Else new path is created4. Aircraft Primary creates new path profile from the NMF provided profile1. Aircraft Primary notifies Local ANS5. Local ANS updates local cache1. Build path update coordination message2. Add new path data3. Send message to Primary ANS function via App#1@step#36. Aircraft Primary notifies database update function1. Database update function sends database updates as applicable viaAdmin#1@step#37. Temporary Aircraft Home1. Sends waiting messages to Home servers

APPENDIX BAGIE OPERATIONAL THREADSARINC PROJECT PAPER 830 – Page 1052. Shuts down operation until Home is not reachable8. AGIE Primary1. Primary AGIE Name Server updates AGIE-wide ANS parameters withnew path2. Primary ANS updates client and node access status3. Primary informs Home servers of newly reachable nodes9. Each affected Home sends waiting messages to newly reachable clients viaApp#1@step#8B-5 Admin ThreadsThese are threads invoked by AGIE admin client.B-5.1 Admin#1 Manage Primary Databases Thread1. Operationa. Name: admin manages AGIE databases threadb. Initiated by: admin application2. Objectivea. Provide interfaces and functions for the admin to manage AGIE controldatabasesi. Admin client uses standard and user defined coordination messageswith attachments to send each database via unique message typeii. Admin sends database updates to Primary, Primary distributes themto all AGIE serversiii. Admin determines how and when to activate updated databases3. Operational usesa. Gets AGIE databases from admin through Primary to all serversb. Allows full or partial updatesc. Databases must be protected outside of AGIE and to admin clientB-5.1.1 Thread1. Admin application sends database update command to admin client onPrimary via XML over secure TCP session1. Message must be encrypted2. Message may contain full or partial updates (new, modified, or deletedentries)3. Includes server target list2. Admin client sends database to database function1. Sets appropriate parameters in XML template2. Sends message to database update function on Primary via messagingin App#1@step#33. Primary database function sends updates to all servers on target list4. For each server on target list1. Build coordination database update message1. May be full or partial

ARINC PROJECT PAPER 830 – Page 106APPENDIX BAGIE OPERATIONAL THREADS2. Set push or pull for sending message or notification3. Encrypt message and data as required4. Send coordination message/notification to database function on servervia App#1@step#35. Remote server database function receives the coordination message fromAMQP inbound control queue3. For pulled message notifications1. Pulls message using App#2@step#22. Updates database3. Builds database update report coordination message4. Sends report to Primary database function via App#1@step#36. Trigger database usage via XML request, immediately or by timed start7. AGIE starts using the database8. End thread

APPENDIX CAPPENDIX CAMQP THREAD MAPPING AND DIAGRAMSAMQP THREAD MAPPING AND DIAGRAMSTODO – James add mapping and diagrams.ARINC PROJECT PAPER 830 – Page 107

ARINC PROJECT PAPER 830 – Page 108APPENDIX DAPPENDIX CAMQP THREAD MAPPING AND DIAGRAMSAGIE INTERFACE DEFINTIONSTODO –Add XML definitions for each interface.