|
|
Isode supplies M-Vault X.500, which is a directory server that conforms to the ICAO SARPs specification for directory service. This provides:
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.
|
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 to be used:
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.
|
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.
|
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.
|
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 white paper 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.
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.
|
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.
|
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:
|
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:
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.