September 2005


Much discussion on ATN Directory has set out a big vision as to how directories can interconnect globally and solve a wide range of problems. Isode set out such a picture in its [ATN Directory Vision] whitepaper.

This paper gives a much more pragmatic and short term view and looks at:

  • What products and systems an ANSP (Air Navigation Service Provider) can purchase and deploy today.
  • The directory infrastructure that would result in supporting such products, and in particular how the DIT (Directory Information Tree) might be laid out.
  • What products are expected to become available soon (over the next six months) that could be used with such an infrastructure.
  • Consideration as to how such an infrastructure could interconnect with other similar directories and short term deployment choices that will facilitate such future interconnection.
Creative Commons License

What You Can Get Now

ATN Directory Servers and Management

Isode supplies M-Vault X.500, which is a directory server that conforms to the ICAO SARPs specification for directory service. This provides:

  • Distribution of servers, including data replication using X.500 DISP.
  • Management tools.
  • Schema support to the ATN defined schema.
  • Specific evaluation help for ATN Directory.

In order to illustrate deployment, this paper will use an example from the fictional country C=TY (in X.500/LDAP, every country has a two letter code, such as US (USA), DE (Germany), FR (France)). In the example, there is a TY Civil Aviation Authority (TYCAA) and a military one. The DIT (Directory Information Tree) is illustrated for these examples.

In this example, the CAA is represented as an organization directly under the country level, and the Military Aviation Authority as an Organizational Unit under the Air Force Organization.

White Pages Service

An immediate service that can be offered based on the ATN Directory is a “white pages” service, giving telephone, email and other information about organizations and users in the directory. While X.500 DAP (Directory Access Protcol) is the SARPs compliant mechanism, LDAP (Lightweight Directory Access Protocol)is a practical alternative where unstructuted information is accessed.

Isode's M-Vault X.500 directory server supports both DAP and LDAP. LDAP enables a wider range of "off the shelf" client products

  1. A desktop LDAP Client, such as MaXware Directory Explorer.
  2. Direct LDAP integration with an integrated Web information system.

Users will be named in the directory, for example for the CAA:

Here, entries for users are placed directly below O=TYCAA, and named with Common Name (CN). Some users are names with eight letter AFTN addresses, which gives immediate familiarity for existing users. Others are named using logical descriptions.

Directory Configured AMHS Servers

Isode’s AMHS Servers may be configured by use of directory. Isode recommends this approach, and this is being adopted by most Isode customers. There are significant benefits to using directory based configuration, described in Isode’s white paper Isode Management Architecture: Client/Server and Directory.

Where an organization is using directory based configuration of messaging, this (complex) information will generally be held in a single sub tree of the directory. In general, it will make sense for an organization to place its AMHS configuration information within the organization. For example, where the CAA is using directory based AMHS Configuration the following structure might be used:

The whole AMHS configuration is stored in an “OU=Messaging Configuration” sub tree, which can be replicated over each of the local TYCAA directory servers, to provide high information availability to the AMHS servers.

SARPs Compliant Directory Integration

Isode provide an ATN Directory Client API that provides a simple integration API for directory information, and enables applications to connect to the ATN directory in a SARPs compliant manner using X.500 DAP (Directory Access Protocol). This product enables applications to search for and read information from the ATN Directory.

AFTN/AMHS Address Mapping

Most ATC users are familiar with AFTN addressing, and unfamiliar with the X.400 O/R Addresses used by AMHS. The Eurocontrol SPACE project defined a mechanism to use the ATN directory to map between these addresses. This will be a very useful capability for end users. It is described in more detail in the Isode whitepaper [Addressing in AMHS: Building a solution that works for the End User].

The long term plan envisaged by the designers of this scheme is that the data defining the mappings would be in a directory sub tree placed in a single global location (O=ICAO-MD-Register) and highly replicated. This is shown below:

Before such a global registry exists, it will be desirable for CAAs to use the directory to manage this information locally. This can be done by placing the mapping information in a local sub tree. Here, for TYCAA, the mapping information is placed in a sub tree named “OU=AMHS/AFTN Mappings”:

As a part of Isode’s ATN Directory Client API, there are calls to perform mappings between AFTN addresses and AMHS X.400 O/R Addresses. This can use mapping information in any specified location in the DIT. For example, the military aviation authority could make use of data managed by the CAA.

What You Can Add Soon

The previous section shows what can be purchased and deployed immediately. The infrastructure described above can be used directly by two types of directory enabled products. Isode expects that both of these will be available from Isode partners within the next six months.

Directory Enabled AFTN/AMHS Gateways (MTCUs)

An AFTN/AMHS gateway needs to map between X.400 and AFTN addresses.

Holding this information in the directory, as described above, is a useful approach, as it enables mapping information to be easily shared.

Directory Enabled AMHS Terminals

An AMHS Terminal (User Agent) is the client that an end user will utilize to access the ATS Message Service. The first generation of directory enable AMHS Terminals are expected to offer at least the following directory based capabilities:

  1. AFTN Address mapping: so that users can work with familiar AFTN addresses, and have X.400 O/R Addresses hidden.
  2. Full verification of local addresses before message submission.
  3. Directory browsing for address selection.

Connecting to Other Countries

The scenario described so far relates to a single country deployment. When another country/CAA has a similar deployment, these can be easily interconnected. By setting up cross references between the directory servers in the two countries, the information in each directory will effectively be joined in a single distributed directory. This structure will then enable:

  1. White pages access to information in both countries.
  2. End user address verification for users in both countries.
  3. Sharing of address mapping information between the countries to share management effort (if desired).

Assume that we are adding another country C=ZZ. This might give a DIT across the two countries of:

Looking at the picture in terms of DSAs (Directory System Agents), you can see a server for each country, with a cross reference between each:


This paper has shown what can be achieved with the ATN directory now, and the benefits that can be obtained with components that are available now. It also shows the value that can be added in the relatively short term, and how the service can be extended as other countries make similar deployments. There is a clear case for ANSPs to start planning directory services now.