Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

isode.com / whitepapers /

Mapping Data between AFTN Addresses and AMHS O/R Addresses

Summary

There is a requirement for AFTN/AMHS Gateways and for some AMHS Clients (particularly those that have direct AFTN support, or where there is migration from AFTN) to map between AFTN Addresses and AMHS Addresses. These mappings are effectively global, and it is highly desirable to store these mappings in the directory. In the future, it is anticipated that ICAO or a central organization will manage these mappings, and distribute them so that they can be used by ANSPs.

Prior to the availability of such a service, Isode is making available mapping tables in LDIF (LDAP Data Interchange Format), which can be easily loaded into a directory server. This data can be used for:

1. Testing and demonstrating AFTN/AMHS address mappings.
2. As the basis for mapping configuration in an operational service.

Isode has used the most recent data available from ICAO to produce these tables, and will update them based on information received. Isode encourages users of these tables and others to send corrections and additions.

Why Directory Mapping?

An AFTN/AMHS Gateway or MTCU (Message Transfer and Conversion Unit) needs to map between AFTN Addresses and X.400 O/R Addresses. It is also convenient for an AMHS Terminal to make such mappings, to provide a convenient interface to the user and to aid transition. This is explained in the Isode whitepaper Addressing in AMHS: Building a solution that works for the End User.

The mapping that needs to happen is universal.

The directory is the ideal place to store this information, and this is set out in the Isode ATN Directory Vision white paper. By putting the mapping information in the directory, it can be easily accessed by all components that need to make use of the mapping information. Information in the ATN Directory can be replicated using X.500 DISP (Directory Information Shadowing Protocol), so it is easy to automatically share this information between sites and organizations.

The directory schema and algorithm used was designed by the Eurocontrol SPACE project. The design envisaged by this project requires data distributed around the world, and is an excellent long term vision.

The Eurocontrol SPACE mapping algorithm can also work with a much simpler Directory Information Tree (DIT), with all of the mapping information contained within a single sub tree, to support AMHS XF and CAAS form addressing (but not "Other Form"). For countries using XF form AMHS addressing, there is no difference. For CAAS form addresses, there is a two stage mapping. In the distributed model, information for the second stage of the mapping is held with the country. In the single subtree model, it is held within the subtree. An example of the single subtree, shown using Isode's Sodium (Secure Open Data, Identity and User Manager) GUI is shown below:

The "World" is the top of the DIT, and C=GB is the Great Britain (UK) country information. The mappings are under o=Isode-MD-Register. There are two types of mapping:

1. Those associated with countries using XF style AMHS addressing. They have an entry associated with the two letter ICAO defined country codes (used as the first two digits of an AFTN address). All mapping information for these countries is held in this entry or in a subtree.
2. Those associated with countries using CAAS style AMHS addressing. These also have a C= (Country) entry under the mapping subtree. These country subtrees contain additional information needed to correctly handle the mapping. The expansion of the CAAS tree for Argentina is shown below.

There are several advantages of using a single subtree:

1. All of the mapping data can be conveniently held in a single part of the DIT.
2. There is only one X.500 naming context needed.
3. The subtree can be placed anywhere in the DIT, allowing for multiple mapping tables to exist, and for deployments to choose which mapping data to use.

The Structure and Format of Distributed Data

The Isode data is distributed under a top level name of "O=Isode-MD-Register". This is to make clear the relationship to the "O=ICAO-MD-Register" defined by the SPACE project, and also to make clear that this data is not the same.

The data is distributed in a file format, structured according to the LDIF (LDAP Data Interchange Format). This is an easy to read text structure that can be loaded into a directory. A small part of the file is shown below:

version: 1

dn: atn-icao-country-code=OA, o=Isode-MD-Register
objectClass: top
objectClass: atn-AmhsMD
atn-icao-country-code: OA
atn-global-domain-identifier: /C=XX/ADMD=ICAO/PRMD=OA
atn-Amhs-addr-scheme: XF

dn: atn-icao-country-code=PA, o=Isode-MD-Register
objectClass: top
objectClass: atn-AmhsMD
atn-icao-country-code: PA
atn-global-domain-identifier: /C=XX/ADMD=ICAO/PRMD=PA
atn-Amhs-addr-scheme: XF

Note that the syntax of some attributes in this file, such as "atn-global-domain-identifier", are defined according to a proprietary Isode format, as there is no standard representation. This means that the LDIF file can be loaded into an Isode M-Vault X.500 directory, and this will result in a SARPs compliant implementation. Modifications to the file may need to be made, in order to load it into a non-Isode directory.

Using the Distributed Format

Basic use of the distributed data can be achieved by simply loading it into a directory. If it is desired to load the data under a different location to O=Isode-MD-Register, then a global text substitution can be made. To load under C=TY, O=Private-Mappings, make a global substitution of "o=Isode-MD-Register" to "o=Private Mappings, c=TY".

The Isode ATN Directory Client API provides routines that implement the Eurocontrol SPACE mapping algorithm, and access the directory in a SARPs compliant manner using X.500 DAP.

Isode provides a test program to use these mappings, which also demonstrates use of the ATN Directory Client API. The source of this program is available as part of the documentation of the API and is available here. An executable program may be supplied in a future Isode release. It can be seen that the API calls allow the user to specify the location in the DIT where the mappings are held.

Operational use of this mapping is expected to be built into MTCUs and AMHS Terminals.

This data is immediately useful for demonstrations and testing. This data may also be useful as a basis for service deployment, prior to distribution of this data by ICAO or other organizations.

Isode provides this data for the limited purposes and duration as set out above free of charge and without warranty, and users of this data must make their own appropriate checks and validation prior to any use or deployment of the data. It is the user's responsibility to ensure that the data is fit for the purpose for which the user intends to use it. By using this data the user accepts that it is provided without warranty or liability on the part of Isode and the user waives all rights of recourse against Isode in respect of the data.

Isode does not warrant that the data will be error free.

The Data

You can download the current version of the mapping file by following the link on the relevant support page here.