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

More documents

Recommendations

Info

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.
Page 2 and 3: ARINC PROJECT PAPER 830TABLE OF CON
Page 5 and 6: ARINC PROJECT PAPER 830 - Page 11.0
Page 7 and 8: ARINC PROJECT PAPER 830 - Page 31.0
Page 9 and 10: 2.0 AGIE PURPOSE AND OBJECTIVESARIN
Page 17 and 18: 2.0 AGIE PURPOSE AND OBJECTIVESAGIE
Page 19 and 20: ARINC PROJECT PAPER 830 - Page 153.
Page 33 and 34: 4.0 AGIE FUNCTIONAL SPECIFICATIONAR
Page 37: 4.0 AGIE FUNCTIONAL SPECIFICATIONAR
Page 81 and 82: 6.0 AGIE PROTOCOL INTERFACESARINC P
Page 87 and 88: ARINC PROJECT PAPER 830 - Page 83AP
Page 89 and 90:
ARINC PROJECT PAPER 830 - Page 85AP
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
APPENDIX BAGIE OPERATIONAL THREADSA
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
APPENDIX CAPPENDIX CAMQP THREAD MAP
show all

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

Create successful ePaper yourself

Delete template?

Save as template?