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

Whitepapers

How AMHS Users Benefit from Directory

Summary

This paper assumes a very basic understanding of AMHS and ATN Directory. For those unfamiliar with AMHS and ATN directory, a simple introduction is given in the Isode introduction to the Aviation industry. A simple explanation of the nature of the ATN Directory and its deployment in support of AMHS is given in the Isode White Paper Deploying the ATN Directory with AMHS: What you can do now.

This paper looks at how an AMHS end application, such as an AMHS Terminal sending and receiving flight plans, will utilize and benefit from the directory.

Model of Directory Usage

An AMHS user is someone using an end application communicating over AMHS. A typical example is an AMHS Terminal used by an operator to handle flight planning. This AMHS user will communicate with other AMHS users. The basic model of AMHS use of ATN Directory is that AMHS users are represented by entries in the ATN Directory. For example:

This example shows a simple directory hierarchy (Directory Information Tree (DIT)). Each blue circle represents an entry in the directory, which may contain information about the object in question. The top level of the DIT is countries represented by standard two letter codes (e.g., C=FR is France). Under the fictional C=TY, the CAA is TYCAA, and this is represented in the DIT as O=TYCAA (O= means “organization”). Users are listed under O=TYCAA, with Common Name (CN=) from names. This example illustrates users named descriptively and with an eight letter AFTN name which can be represented by the following directory names:

• CN=YYYABCDE, O=TYCAA, C=TY
• CN=Operations Manager, O=TYCAA, C=TY

This hierarchical naming enables every AMHS user in the world to have a unique directory name.

Each CAA will operate directory servers containing information on their own users. These servers will be interconnected to form the global ATN Directory, so that users of the ATN Directory will be able to see entries for all users (and not just those for the local CAA).

When sending an AMHS message to that other user, the AMHS client application (the AMHS Terminal in this example) is aware of the recipient's entry in the ATN Directory. The AMHS client will use the directory in two ways:

1. To help locate the user (recipient discovery).
2. To validate the recipient and recipient capabilities.

This second function is the one that is mandated by AMHS. Both functions are described in more detail below.

Verification Layer

Recipient verification is the key AMHS use of the ATN Directory. This function will not be usually be directly visible to the end user. It will take place prior to a message being submitted to the X.400 Message Transfer Service. There are two elements of this verification

Recipient Name Verification

This core check is to determine the validity of the recipient, by finding the recipient's entry in the ATN Directory. The benefit of making this check is that it will detect messaging address errors prior to a message being sent. This will mean that an operator can immediately correct the address. If this check was not done, the error would show up later when a non-delivery report is sent back. The name verification will improve overall service resilience, by performing this check prior to submission.

Recipient Capability Verification

The AMHS client will also read information from the entry, about the capabilities of the recipient AMHS User. Some examples:

1. Maximum message size. This directory attribute is defined in X.400. It allows the client to check that the message being sent is not too large to be handed by the recipient.
2. Extended ATS Support. This directory attribute is defined in the AMHS SARPs (Standards and Recommended Practices) and indicates that the recipient supports the Extended ATS Service of AMHS, and so it is safe to use features of this service. If this attribute is not present, messages should be restricted to the Basic ATS Message Service.
3. MTCU Capabilities. This directory attribute is defined in the AMHS SARPSs and indicates that the recipient is not a direct user of AMHS, but messages are sent though an MTCU (Message Transfer and Conversion Unit) to an AFTN or CIDIN recipient. Information in this attribute describes the capabilities of the MTCU, which will constrain the details of messages that may safely be sent to this recipient.
4. BUFR Support. This directory attribute should be defined as part of a specification for carrying BUFR (Meteorological) messages over AMHS. It would enable the sender to ensure that BUFR messages were only sent to BUFR capable recipients.

The key point about recipient capability checking is that it will enable the sender to be confident that messages can be correctly handled by the intended recipient. It will enable new services based on AMHS (that will initially only be supported by some recipients) to be introduced in a robust manner.

When the Recipient is Not in the Directory

It may be that the message recipient does not have a directory entry that is accessible by the AMHS client. Reasons for this may be:

• The recipient is in a country (CAA) where no directory is operated.
• The recipient’s CAA operates a directory, but it is not connected to the directory being accessed by the AMHS Client. This would be an unfortunate situation, and illustrates the importance of CAAs interconnecting directories when they interconnect AMHS links.

In this situation, recipient verification by the AMHS client is not possible, and so the message must be sent without verification. In this situation, AMHS requires use of the Basic ATS Message Service (no advanced features). This is desirable, to maximize interoperability. It can be seen that directory deployment is a necessary pre-requisite to deployment of advanced ATS applications.

Recipient Discovery

Recipient discovery takes place prior to recipient verification. This use of directory is visible to the end user, and is a clear benefit of using the ATN Directory. An AMHS client may obtain recipient information in three different ways, discussed in detail below:

1. Local (No Directory)
2. Global (ATN) Directory
3. Remote Recipients in the Local Directory

Local (No Directory)

There is no requirement for an AMHS client to get recipient information from a directory. This information may be remembered, or obtained from a local online address book (e.g., by the user scrolling to and selecting a recipient).

Global (ATN) Directory

The ATN Directory is an ideal mechanism for the AMHS client to select a recipient. The AMHS client can simply browse or search the ATN directory, using the natural Country/Organization(CAA)/User hierarchy.

When the ATN Directory is used for recipient discovery, verification is performed at the same time.

A good client works in a way that makes it easy for the user to select frequently used recipients. It may also cache information locally, to prevent repeated access to the directory to obtain the same information.

Remote Recipients in the Local Directory

When a CAA deploys a directory, a first step will be to provide the CAA's own part of the ATN Directory. This data will be managed by the CAA in conjunction with AMHS configuration and will add immediate value to the local AMHS deployment.

As the local ATN Directory is connected to other directories, this will provide local users with access to more and more recipients directly through the ATN Directory.

It will be desirable for local users to have convenient access to information about recipients not (yet) in the global ATN directory. This could be achieved by local means (as described above). An alternate approach is to use the directory as "address book" storage for remote recipients not in the ATN directory. This will have the benefits of a client/server approach, and in particular will allow the address book to be shared between multiple local users.

Conclusions

This paper has shown that the ATN Directory adds value to an AMHS Deployment. Because of the usefulness of having information on local users available in the directory, we believe that when a CAA deploys AMHS, it should deploy its local part of the ATN Directory at the same time. When CAAs interconnect AMHS, they should also interconnect their directories, using a combination of directory chaining (X.500 Directory System Protocol) and directory replication (X.500 Directory Information Shadowing Protocol) to optimize overall performance.