Title: Naming of Multiple AEs PDR Reference: 97120001 Originator Reference: UL-DR 126 SARPs Document Reference: ULCS SARPs Status: FORWARDED to WG3/SG3 PDR Revision Date: 30-Mar8 PDR Submission Date: 16-Dec-97 Submitting State/Organisation: STNA Submitting Author Name: PICARD, F Submitting Author E-mail Address: PICARD_Frederic@stna.dgac.fr Submitting Author Supplemental Tel +33 5 62 14 55 33 Contact Information: Fax: +33 5 62 14 54 01 SARPs Date: Proposed ICAO Version 2.2 (WG3 Redondo Beach, Oct 97) SARPs Language: English Summary of Defect: AE titles defined for the ATN AE contain as a variable element the system identifier (i.e. the 24-bit address for air AEs and the ICAO ground facility designation for ground AEs). That means that in an aircraft, only one AE of one type can be addressed, not necessarily in the same system. This principle works a priori for all air-ground applications. The problem comes with applications which may have different instances simultaneously on different systems. This is obviously the case of the System Management Application which may have one Agent per machine. So for example, in an aircraft installed with one BIS and one ES, the AET used by the ground manager should allow the identification of each airborne agent. With the current AET format, it is not possible. The problem is similar for ground systems (several SM AEs may co-exist with a ICAO Ground Facility). Assigned SME: Sub-Volume 4 SME SME Comment: The AE Title (AET) is defined as: {iso.identified-organisation.icao.atn-end-system-air[or ground]..operational.} In general, if there were different instances of the same application on the same end system, then this could be catered for by using Invocation Identifiers in the addressing. However, if there are multiple system management agents in an ATN end system, with each responsible for a different set of MOs, then arguably they are not 'the same application' and would need distinguished addresses. But we should not expect the ground system to know the systems management configuration of the aircraft. There could for example be a single Agent acting as a proxy for ALL airborne management information. It would be possible to extend the ATN UL naming for systems management by allocating additional AE qualifiers for SMA (currently only the single value 5 is allocated). But is this really a requirement? Following discussions in the SME team (Email exchanges and WG3/SG3 meeting on 18.02.98) it is proposed that this PDR should be FORWARDED for consideration in WG3 for Package 2, for the following reasons: This PDR exposes a more general problem, in that it is not possible to address explicitly multiple instances of ANY CNS/ATM-1 application in an ATN end system. There may be requirements in Package 2 for multiple CM applications (say) to exist in an aircraft. Also, it is inherent in the CM protocol that there is only one address per application type, and that sub-arcs below AEQualifier in the naming hierarchy are not catered for. If a CM-Logon is performed to exchange further addresses, then previous addresses are overwritten. Further, ATN Routers may have identifiers taken from alternative name spaces. In such cases the name-address mapping specified in the ULCS SARPs will break down when trying to communicate with SM Agents in Routers. To summarise, WG3 needs to resolve the following Package 2 issues: a) Package 1 ATN naming and addressing does not handle multiple instances of the same application type b) CM does not allow for naming arcs below AEQualifier c) Routers can have names from different naming trees d) How to register additional AE types, either ICAO or external (e.g. CTS, SAM) Proposed SARPs amendment: (to be investigated by WG3/SG3) SME Recommendation to CCB: FORWARDED CCB Decision: FORWARDED (CCB/5 13-Mar-98)