Publication and Maintenance of the ICAO Register of AMHS MD

Publication and Maintenance of the ICAO Register of AMHS MDsACP/WGN and SGN3 meetings (Montreal, May 2004)

ACP WGN03-WP27

ACP/SGN3 WP/2-3

17/05/04

AERONAUTICAL COMMUNICATIONS PANEL(ACP)

Working Group N - NETWORKING

SUBGROUP N3 – GROUND-GROUND Applications

Montréal, April 2003 (SGN3 second meeting, WGN third meeting)

Agenda Item 3 : ATS Message Handling Services

Publication and Maintenance of the ICAO Register of AMHS MDs

Presented by Jean-Marc Vacher

Summary

The ICAO Secretariat has collected from ICAO Member States and Organizations information aimed at building the “ICAO Register of AMHS MDs and addressing information”.

The goal of this paper is to propose a set of practices and procedures aimed at publication and maintenance of the Register by the ICAO Secretariat, in co-operation with States continuing to provide up-to-date information.

TABLE OF CONTENTS

1Introduction

2Goal of the register

3ROLE OF the ICAO Secretariat

3.1Role and tasks

3.2Issues to be considered

4Register lifecycle

5examples of publication format

6Procedures for register maintenance

7Recommendations to the meeting

8Appendix A: description of procedures

8.1Schedule: General description

8.2Notation

8.3Description of procedures

8.3.1Proposed update

8.3.2Actors

8.3.3Purpose of the procedure

8.3.4Description

8.3.5Trigger

8.3.6List of tasks

8.3.7Pro forma

REFERENCES

[1]Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN), ICAO Doc 9705, Third Edition - Sub-Volume III, Ground-Ground Applications

[2]Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN), ICAO Doc 9705, Third Edition - Sub-Volume VII, ATN Directory Services

[3]Comprehensive ATN Manual (CAMAL), ICAO Document 9739, Second Edition (draft to be published)

[4]RFC2849 The LDAP Data Interchange Format (LDIF) - Technical Specification

1Introduction

The ICAO Secretariat has collected from ICAO Member States and Organizations information aimed at building the “ICAO Register of AMHS MDs and addressing information”.

The ACP Working Group N and its subgroup N3 (ground applications) are committed to provide support to the ICAO Secretariat in the establishment of this Register.

The goal of this paper is to make use of the collected information, and to propose a set of practices and procedures aimed at publication and maintenance of the Register by the ICAO Secretariat, in co-operation with States continuing to provide up-to-date information.

2Goal of the register

The goal of the Register is to facilitate the implementation of the ATS Message Handling System (AMHS), and the migration from AFN/CIDIN to AMHS, through the official publication of up-to-date information needed to construct the AMHS addresses of users in this new messaging system.

The published Register shall be the collection of addressing information provided by each ICAO Member State or Organization. This will enable each State or Organization to determine the most appropriate addressing scheme and address attributes for its own AMHS Management Domain, within the framework defined by the ICAO Manual of Technical Provisions for the Aeronautical Telecommunications Network (Document 9705, Edition 3).

Each AMHS user or user system (ATS Message User Agent, AFTN/AMHS gateway) will construct a recipient AMHS address using on the one hand the AFTN addressee indicator of the considered user, and on the other hand the Register information to derive additional MHS address attributes (e.g. PRMD-name, organization-name).

It will be possible to use the published information in different ways:

-human AMHS users will be able to directly use the published information to manually construct AMHS addresses of the recipients to whom they wish to send AMHS messages. They will derive AMHS addresses from former AFTN (or CIDIN) address indicators, based on detailed AMHS address attributes retrieved from the Register;

-AMHS system operators and/or administrators will also be able to facilitate the above task for AMHS users, up to the point of making it completely invisible if desired. For this purpose, the information published in the Register may be entered in three main ATN/AMHS system categories belonging to each AMHS Management Domain:

• the preferred option is to enter the Register information into a Directory Server implementing the Document 9705 requirements for Directory support of AMHS. The entered directory information may in turn be retrieved by ATS Message User Agents or by AFTN/AMHS Gateways, e.g. using AFTN addressee indicators as an input to construct AMHS addresses, as explained in the ICAO Comprehensive ATN Manual (Document 9739 Edition 2, draft available electronically from , part 3, sections 6.2.1.5.10 to 6.2.1.5.20). Other (i.e. non-ATN) directory systems may also be used for the same purpose provided that they also facilitate the users’s task of constructing AMHS addresses;
• the same information may also be entered directly into ATS Message User Agents, to be used locally as part of a “local address book”. However the task of maintaining the information up-to-date might be more difficult than if it is stored in a central directory server as suggested above;
• this information is also required in AFTN/AMHS gateways, to populate the address look-up tables that are an essential function of such gateways. Direct input of the Register information into the gateway look-up tables is possible, but retrieval from a Directory Server is also a valid option.

AMHS addresses are subject to changes, additions and withdrawals, as in any communication system. Therefore the ICAO Register of AMHS MDs and addressing information should not be seen as a static document (or collection of information), but rather as an evolutive database. This is particular true in the initial time of AMHS deployment, in which changes are likely to occur, e.g. because of States migrating from an XF addressing scheme to a CAAS addressing scheme when starting up operational AMHS services.

For each of these changes, the Register will have to be updated. It is suggested that the update frequency be in accordance with the AIRAC cycle (every 28 days). This means that the information entered in AMHS systems, as described above, will have to be updated accordingly.

3ROLE OF the ICAO Secretariat

3.1Role and tasks

The ICAO Secretariat should play a central role in the registration and publication process of the Register of AMHS MDs and addressing information, in the same way as ICAO manages and publishes ICAO Location Indicators in Document 7910[1]. This would be in continuation with the work that was started with the publication of State Letter referenced SP 54/1-03/39 concerning the establishment of the Register.

In general terms, the tasks that are required from the Secretariat in this area are the following:

• collection of updates to the Register proposed by ICAO Member States,
• verification of the proposed updates, to ensure that they are institutionally and technically valid,
• input of the validated updates in the publishable, electronic version of the Register,
• publication of the Register.

3.2Issues to be considered

The issues to be considered appear to be related to two main aspects, in conjunction with the fact that the Register information is made available to Member States for operational purposes (creation of AMHS addresses by systems contributing to the Aeronautical Fixed Service):

• The management of the Register information represents a workload, which is likely to be low but cannot be neglected. Cyclic publication dates will have to be met, in accordance with the lifecycle described in section4 below. This is critical to States because they will require up-to-date information, in accordance with the AIRAC cycle, for proper message routing and delivery in the AMHS. It should be ensured that resources are available so that publication date constraints can be met;
• Integrity of Register information is essential, because of the operational nature of this addressing information. Accidental or intentional corruption of the Register information would lead to AMHS dysfunctions. This implies that exchanges between Member States and ICAO for the collection of updates are secured, either technically or procedurally. This also implies that the ICAO publication medium for the Register be protected from loss of integrity.

However, it should be noted that there is no “real-time” constraint associated with the Register update and publication, given that the publication cycle is based on a 28 days period. Likewise, there is no strong availability constraint placed on the Register publication. The service could incur e.g. maintenance disruptions of up to one day, provided that the proposed cycle milestones described in section 4 are met.

Finally, the question of confidentiality of the Directory information should be discussed, particularly in view of the intention to publish the Register on the ICAO web site.

4Register lifecycle

The Register lifecycle, including the publication, utilization and maintenance processes is illustrated below.

Figure 1: Lifecycle of the ICAO Register of AMHS MDs and addressing information

5examples of publication format

The tools and publication formats depend upon ICAO web publication standards. There is consequently no intention to constrain such formats in this paper.

Nevertheless, principles can be established, and examples given, to show how the Register could be easily implemented.

The Register needs to be posted on the ICAO web site in at least two, and ideally three forms:

• an easily readable, user-friendly format for web publishing (e.g. HTML or LDAP browsing), and
• an electronic file (or a set of) that can be imported into an AMHS system or a Directory system. LDIF (LDAP Data Interchange Format, specified in RFC 2849) should be preferred for the latter. For importation into other AMHS systems not including a standard directory function, formats such as tab-separated or CSV text files could be easier to manage for systems not implementing LDAP.
• ideally an ICAO-managed electronic directory database, X.500 or LDAP-based would also enable the creation of a central Register consistent with States technical systems. However it is uncertain whether the operation of such a database fits into the terms of reference of the ICAO Secretariat (or of another central ICAO body).

Apart from recommending a directory format if feasible, the format used for storage of the Register internally to ICAO is not a matter for recommendation. At present, the working file building the Register is a Microsoft Excel folder, but many other options can be envisaged. The only constraint is that creation of the formats for posting should be as simple as possible. The Excel format meets this goal, with native HTML and CSV storage functions.

A software tool enabling export of data from the ICAO internal storage format to the LDIF format should be either procured (preferably using freeware or Open Source software) or developed.

6Procedures for register maintenance

The procedures to be developed for the maintenance of the Register, in accordance with the lifecycle described above, are listed in the table below.

The “initiator” is the entity that takes the initiative of starting the procedure. The “trigger” is the main event that causes the procedure to be started. In some cases, calendar considerations related to the AIRAC cycle may also participate in the triggering decision. Work optimization to perform the procedure on a set of proposed updates (rather than on a single one as described below) may also be taken into consideration.

procedure name / initiator / involved parties / description / trigger
proposed update / State
(AMHS MD) / originating State, ICAO Secretariat / action by which a State submits to ICAO a Register update reflecting an intended amendment of the State’s AMHS address space / State decision to amend its AMHS address space in accordance with ICAO Global and Regional practices
verification of a proposed update / ICAO Secretariat / ICAO Secretariat / verification by the ICAO Secretariat that the amended address information is valid from an institutional and technical viewpoint and can be published / reception of proposed update
co-ordination of update / ICAO Secretariat / originating State, ICAO Secretariat / action by which the ICAO Secretariat co-ordinates with the submitting State to modify the proposed update, so as to make it valid in case of initial non-validity / diagnostic by ICAO Secretariat that the initially proposed update is invalid
entry of validated update / ICAO Secretariat / ICAO Secretariat / actual update by the ICAO Secretariat of the Register engineering version with the (validated) amended address information provided by the State / diagnostic by ICAO Secretariat that the initially proposed update is valid
web publication of Register / ICAO Secretariat / ICAO Secretariat / replacement by the ICAO Secretariat of the published version of the Register with the engineering version that includes the validated updates / AIRAC date + 14 days
input of Register information / AMHS MDs / AMHS MDs / action by which AMHS MDs and organizations operating Directory Systems in support of AMHS update (but do not activate) the Register information entered in their systems / publication of a Register update
application of Register update / AMHS MDs / AMHS MDs / activation of updated information in operational AMHS systems / AIRAC date (next cycle)

If this principle is agreed, each of these procedures should be described in a more detailed fashion. An example of detailed description for the “proposed update” procedure is given in Appendix A to this paper.

7Recommendations to the meeting

The meeting is invited to provide comments, if any, about the publication principles and maintenance procedures described above, and to recommend their adoption, after amendment as appropriate, by the ICAO Secretariat, for the purpose of managing and operating the ICAO Register of AMHS MDs and addressing information.

The meeting is further invited to task SGN3 with the continuation of this work so as to provide the ICAO Secretariat with a detailed set of procedures at the earliest opportunity.

8Appendix A: description of procedures

Publication and Maintenance Procedures are sequences of operations which are specified in detail in this section and which involve the use of the ICAO Register of AMHS MDs and addressing information, both in its officially web-published version and in its engineering version maintained by the ICAO Secretariat..

8.1Schedule: General description

Procedures are executed on a fixed schedule. This schedule is based on a fixed cycle of exactly 28 days, each cycle being fixed by a so-called “AIRAC Date” which is always a Thursday. In this cycle, specified actions shall be performed on given days or within a range of days.

The days in a cycle are numbered 1, 2, …, 27, 28. Day 28 is always an AIRAC Date – see Figure 2.

Figure 2: Illustration of the 28-day cycle

8.2Notation

Procedures are specified formally in Section 8.3. At present section 8.3 contains only the description of the “proposed update” procedure, as an example, but it is intended to complement it with other descriptions. This section describes the notation used for the specifications.

A procedure is a single action or a set of actions performing a well-defined task which has a unique starting and a unique end point.

An actor is an organization involved in the procedure.

A task is a unit of work performed by an actor.

A trigger is an event which causes an action to be started, e.g. a fixed time, an external event or an event created by another procedure.

A procedure description consists of the following parts:

-a graphic defining the elements of the procedure,

-a list of the actors,

-a description of the purpose of the procedure,

-a verbal description of the procedure,

-a list of triggers,

-a list of tasks and decisions and

-a set of proforma (where appropriate).

The following additional elements are used in the procedure definition:

A delay is a scheduled time period between the commencement of two sequential actions.

In a decision the operator shall select among alternatives according to given criteria.

END indicates the end of the procedure.

A Goto, e.g. Goto x, is an unconditional jump to the indicated connector in another part of the graphical description.

Figure 3 illustrates the use of these graphic elements.

Figure 3: Example of graphical notation used to specify procedures

8.3Description of procedures

8.3.1Proposed update

8.3.2Actors

There are two actors involved in the “proposed update” procedure:

• the single active actor of the “proposed update” procedure is the State / ATSO implementing an AMHS MD and willing to amend its AMHS address space,
• the ICAO Secretariat is present as a passive actor, being the recipient of the proposed update developed by the ATSO.

8.3.3Purpose of the procedure

The purpose of this procedure is to provide a framework for the submission of an update to the address space of an AMHS MD, to be applicable within one AIRAC cycle from submitting the update to ICAO. This means that the update refers to Version N of the Register, and is applicable from the applicability date of Version N+1.

Potential updates include:

• the modification of the PRMD-name used by the considered AMHS MD (this should be as unfrequent as possible since PRMD-names as required to be stable);
• modification of the addressing scheme selection (from XF to CAAS – recommended) and from CAAS to XF (not recommended);
• modification of the CAAS detailed table;
• addition of an entry in the Register to deal with specific cases (e.g. Kosovo recently);
• deletion of an entry in the Register (this is unlikely to happen but it should still be envisaged for efficient Register maintenance).

8.3.4Description

Upon the decision to amend the AMHS address space of a State / ATSO, the specification of the amended addressing scheme is developed by the staff in charge of managing the considered AMHS MD. Changes in the information already published by ICAO as part of the Register version currently published are specifically identified, and the update is formulated using a submission form provided by ICAO (retrieved from the ICAO web site).

Upon publication of Version N of the Register, the proposed update (if prepared in advance) is checked for applicability before being submitted. This is to make sure that changes between Version N-1 (available when the update was being prepared) and Version N (to which the update shall apply) do not compromise the proposed update.

After this verification the proposed update is formally sent to the ICAO Secretariat before day 14 following the publication of Version N. Security measures must guarantee the integrity of the proposed update transmission from the State / ATSO to ICAO.

8.3.5Trigger

The trigger for the “proposed update” procedure is the decision to amend the AMHS address space of the AMHS MD implemented (or to be implemented) by a State / ATSO. Such a decision may result from internal (e.g. MD-topology reorganization) or external (e.g. ICAO Regional decision for a new system being operationally started) events. The identification of such events is beyond the scope of this procedure.