ATN Directory Vision: An Infrastructure for Supporting AMHS and Ground to Ground Communication

AMHS (Air Traffic Services (ATS) Message Handling Services), as specified in the ICAO ATN (Aeronautical Telecommunications Network) SARPs, is the new standard for ground to ground messaging communications, which is being adopted rapidly and will eventually replace existing AFTN and CIDIN systems.

The ATN SARPs also specify Directory Services (in Sub-volume Seven). This ATN Directory Service is closely linked to AMHS, and is essential to deploy many of the services defined in AMHS.

What is the ATN Directory

The ATN Directory is specified in volume 7 of the SARPs. It provides an infrastructure to support various aspects of the ATN, and in particular to support AMHS and Extended ATS Message Service capabilities. The ATN directory is based on the ITU X.500 specification, which is extended for various ATN capabilities. X.500 was specified to support telecommunications systems, and so is ideal for the ATN application. Key elements of X.500 are:

• Hierarchical Naming. This allows authority to be naturally delegated to ATN participants, and to allow distributed deployment that follows the same hierarchy.
• Standardized access protocols, enable client/server management, and straightforward integration into ATN applications.
• Distributed and replicated directory provision, using multiple DSA (Directory System Agents), make X.500 ideal for supporting a widely distributed system such as ATN.
• Standard schema (object classes, attributes and naming) which can be used as a basis for core applications.
• Extensible schema. This extensibility has been used effectively in the ATN directory to extend the core X.500 schema to provide ATN specific functionality. This extensibility can also be used by ATN Directory vendors and customers to add further specific functionality. As well as including about 30 standard objects, the ATN Directory include the following ATN specific objects, mostly extensions of standard objects:

• • Atn-AmhsUser
  • Atn-OrganizationalUnit
  • Atn-OrganizationalPerson
  • Atn-OrganizationalRole
  • Atn-ApplicationEntity
  • Atn-AmhsDistributionList
  • Atn-AmhsUserAgent
  • Atn-AmhsGateway
  • Atn-Aircraft
  • Atn-Facility
  • Atn-IdrpRouter
  • Atn-DirectorySystemAgent
  • Atn-organization
  • Atn-CertificationAuthority
  • Atn-AmhsMD

It can be seen from the list of objects supported, the ATN functions that can be supported by the ATN Directory. This includes:

• The objects necessary to build a managed hierarchy to contain a wide range of ATN objects.
• Objects needed to support AMHS. This is a major component of the ATN directory definition, and the primary focus of this paper.
• Objects useful to support the OSI lower layers (e.g., Atn-IdrpRouter). This is not discussed here.
• Various ATN relevant objects (e.g., Atn-Aircraft; Atn-Facility).

How can the ATN Directory be Used

Having briefly set out the capabilities of the ATN directory, it is useful to consider how it is used. The following subsections set out the eight primary applications of the ATN directory identified by Isode.

AMHS: Extended ATS Message Service Support

AMHS defines the Basic ATS Message Service, which provides a level of service equivalent to the existing AFTN and CIDIN services. AMHS also defines a number of value added services, as part of the Extended ATS Message Service, which build on the core AMHS infrastructure. Some of these services require the ATN directory as a basis for deployment. These are:

• Security services, and in particular digital signature of content.
• Ability to have additional information transferred over the AMHS, and in particular large binary attachments.

The primary reason for these services requiring the directory, is that it is necessary to verify whether the recipient has these capabilities prior to sending a message. This is important, as it will prevent the potentially serious service implications of a message being sent with features that the recipient is unable to handle. Directory is also used to handle recipient security parameters.

In addition to supporting these services, verification of recipient address is a service in its own right. This gives the advantage of being certain of recipient address correctness, before it is submitted, leading to a higher quality of service. The directory will also make it easier to search for new recipient addresses.

These new services are important for extending the basic value of AMHS, and for the addition of new future services.

Address Book for AMHS

An address book is a local directory of information, which may belong to a user or be shared by an ATC organization. The key difference between an address book and a directory is that information in the address book is managed by the owner of the address book, rather than the owner of the information. For example, an ATC User might maintain an address book of frequently used contacts.

Address books can add value, particularly in the early stages of deployment of an ATN directory where there is only partial coverage. Placing information into an address book, means that the ATN application can use the address book instead of the directory to determine information. This transitional use of address book would mean that initially information would be maintained in address books, but in the long term, this would be replaced by information stored and managed in the “natural” location in the ATN Directory.

Use of the directory to implement an AMHS address book is natural because:

• It can use much of the information framework defined by the ATN directory.
• It can use common client access mechanisms.
• It can enable easy sharing of information within an ATC organization.

AMHS Routing

AMHS servers need to route messages. Directory is a natural location to store this information, as it allows client/server management, good horizontal scaling, and efficient sharing of configuration information.

AFTN Address Mapping

Eight digit AFTN addresses are pervasive in the AFTN system and in end user interfaces. In order to make effective use of AMHS systems and inter-working with AFTN/CIDIN, it would be valuable to have a means to convert from 8 digit AFTN addresses to X.400 O/R Address or X.500 Directory Name, and the reverse mappings.

AFTN/AMHS Configuration

In the same way that AMHS systems can be configured using directory, it is also possible to configure an AFTN/AMHS gateway and AFTN systems using directory.

White Pages

The ATN directory will provide a generic white pages service to allow lookup of information. It may be used to enable ATN users to look up email, telephone and other information about users registered in the ATN directory. This service will be straightforward to provide, as it can use the same management infrastructure as the data for Extended ATS Message Service.

Security and PKI Support

Security of the ATN is defined in part 8 of the ATN SARPs. This security is based on X.509 PKI. Its approach to compression leads to new security attributes defined as a part of the ATN Directory specification.. Although X.509 PKI can be deployed independently of the directory, large scale deployment is greatly facilitated by use of directory.

ATC Resources

The ATN directory allows storage of information on ATC resources, such as facilities and aircraft. This could provide a useful service to ATC users, and could also add value to AMHS applications (e.g., verification of aircraft information, in flight planning applications).

Extended ATS Message Service: The Key Focus

It can be seen that there are many ways in which an ATN directory can be used. Support of the Extended ATS Message service in AMHS appears to be the application with the highest value. Because it requires a global directory deployment, there are a number of issues that need to be solved in order to provide this solution. Because of this, the next section focuses on a directory to provide support for the Extended ATS Message Service.

Specific consideration is also given to supporting AFTN Address Mapping. Although not essential to operating the Extended ATS Message Service, provision of this mapping will greatly facilitate transition from AFTN to AMHS. This mapping also benefits from cooperation between ATN directory operators.

Building a Global ATN Directory

The Scope of the Problem

The ATN directory needed to support extended SARPS will need to hold an entry for every AMHS user in the world. This has been estimated to be around 80,000 users. In terms of directory size, this is not a particularly large directory. Directory deployments often have millions of entries.

The ATN directory would need to cover most countries in the world. In some countries, there will just be a single participating organization. In others, there will be a small or moderate number. This might lead to 500 organizations participating in the ATN directory. This is not a particularly large directory deployment, and does not present any significant technical difficulties. The distributed and varied nature of the different participants is anticipated to be the most challenging aspect of building this system.

Distribution and Replication

When an organization deploys an ATN directory service, it will become a part of the organization’s core operational infrastructure. For this reason, it is likely that most organizations will wish to operate local directory servers in a redundant (replicated) configuration. Having the directory servers remote from the core ATM application and AMHS servers would render the system vulnerable to network failures and performance degradation. This would be unacceptable.

An ATC organization will also wish to manage its own ATN Directory data on its own directory servers. Reasons for this:

• Local data will be the data that is most frequently accessed, so it is highly desirable to have this mastered locally.
• Updates will usually be made by staff in the local organization, and it will be most efficient and secure to perform this update on local servers.
• An ATC organization may choose to extend its data for local purposes, and this will only be practical as part of a local directory implementation.
• An ATC organization may have local security, access, and data management policies, which are different to other ATC organizations.

These requirements lead to each ATC organization operating one or more directory servers (DSAs) and managing their own data on these servers.

These basic requirement means that the ATN Directory will be quite highly distributed, with most ATC organizations operating their own directory servers, except in cases where they outsource their whole AMHS and ATN Directory operation to an organization such as SITA. The ATN directory will be a highly distributed directory, eventually with hundreds of servers worldwide. A single central directory is not going to meet the operational needs of ATC organizations, because of resilience, performance, and management reasons.

When an ATN directory query is made relating to data in a remote ATC organization, a simple approach will lead to the query being resolved by a remote DSA. It is also possible to replicate data (using X.500 DISP (Directory Information Shadowing Protocol)) so that there is a copy on a local server. The requirements of extended SARPs for address verification prior to message submission, will lead to frequent directory access and demanding performance and robustness requirements. Given the relatively small total data size of the ATN directory (80,000 entries), there are no particular scaling issues that need addressing to achieve this. Therefore, it will often make sense to have data in the ATN directory highly replicated.

Building from the Bottom Up

The long term picture of the ATN Directory is of a system with hundreds of servers that is highly replicated. It is important to understand how this system will be built up. If there is a requirement to put the whole system in place before it provides useful service, then it will fail. This section describes a ‘bottom up’ approach to deployment, where individual ATC organizations can deploy ATN directories and add immediate value. It then describes how these directories can be linked.

An individual ATC organization can deploy an ATN directory, and gain immediate value for an integrated AMHS service. This is because the AMHS application can use the local directory to support extended SARPS for all local traffic. This will give an immediate application of the extended SARPs and benefit from the directory.

The local ATN Directory will hold the local portion of the ATN Directory DIT, needed to support AMHS. If it is also used to handle local address books, this can give some of the benefits of extended SARPs for these recipients.

These local ATN Directories can be extended by integration of two ATC organizations. The first step will be for both of these organizations to deploy AMHS, including ATN Directory. These organizations will interconnect their AMHS services. In order to gain the extended SARPs benefits, they will also then interconnect their directories. This will be straightforward.

• These local ATN Directories will be set up as ‘First Level Directories’. This means that they behave as a global directory.
• The local ATN Directories will have their managed DITs named in a SARPs conformant manner, that will not conflict with the other ATN directory.
• The directories can be given ‘knowledge’ of each other, and configured using ‘Directory cross references’ so that they behave as a single coherent directory service.

After this interconnection is set up, local users will be able to resolve queries relating to data in both directory services. Performance may be optimized by setting up replication agreements between the organizations, so that copies of the remote data is held locally. This will generally be beneficial.

Central and National Directory Servers

The bottom up approach described above means that a directory can be built without any central or national directory service. This is seen as highly desirable. As the number of deployed directory servers grow, the basic bottom up model means that each ATC organization with a directory will need to establish agreements with every other such organization.

Provision of a central ATN directory server (e.g., by Eurocontrol) would mean that a new directory would only need to establish a direct relationship with this single central directory, and that all other relationships could be handled indirectly through this central server. Direct relationships with other servers could still be established, but would only be needed as a performance optimization. Note that this directory would not actually hold much data (other than replicated data). Its key role would be in connecting other directory servers.

A similar approach could be taken with national directories, where a single national directory could co-ordinate all of the national directories (e.g., in the UK, directory servers operated at smaller locations could be coordinated through NATS).

While not a necessary step for building a global ATN Directory, establishing a central directory server in parallel or soon after directories in individual ATC organizations would enable the ATN Directory to grow more easily.

Lower Layers

The ATN SARPs specify a profile of the Transport and Network layers to be used as a part of the ATN. This profile is referred to in this document as ‘OSI Stack’. The OSI Stack has a number of ATN specific features, which are not available in many OSI Stack implementations.

The formal SARPs specification of the ATN Directory and AMHS is that the OSI Stack is used for all communications. Isode supports use of the OSI Stack in its AMHS and ATN Directory products.

X.400 and X.500 products may also be operated over TCP/IP, using the RFC 1006 standard (which has been updated as RFC 2126), and this is how they are generally deployed. All X.500 products are believed to support RFC 1006. Isode recommends deployment over RFC 1006 rather than OSI Stack, where this is an option.

Use of RFC 1006 is being chosen for many AMHS deployments, and it is likely that this will be the case for many ATN Directory deployments. Support of OSI Stack may be important in some deployments, and in particular for interconnection with other ATC Organizations where use of OSI Stack is the only means available.

Access: DAP and LDAP

The ATN Directory specifies use of X.500 DAP as the directory access protocols. Isode supports this protocol, and also provides a client development toolkit to develop applications using X.500 DAP.

LDAPv3 (Lightweight Directory Access Protocol version 3) was developed to provide a simple means of accessing an X.500 directory. Isode supports LDAPv3 and has a long association with this standard. Most of the capabilities of an X.500 directory are available through LDAP. LDAP is widely supported, and it is superficially very attractive to add LDAP support to the ATN Directory. Isode does not recommend use of LDAP with the ATN Directory for the following reasons:

1. AMHS, the major ATN Directory application, uses the X.400 P3 and P7 protocols, so it is natural to use DAP in conjunction with these.
2. The ATN Directory will be a highly distributed, based on X.500 distributed operations. A DAP client can participate in the distributed operation using a combination of chaining and referrals. An LDAP client would be restricted to chaining only, which is an undesirable restriction, which may restrict service in some situations.
3. If LDAP were to be used, its use with ATN directory would need be standardized. This would require additional specification. The major problem would be in the area of address syntaxes, and in particular syntaxes such at atn-mtcu-characteristics, and the X.400 O/R Address and related syntaxes which are defined in X.402. In order to use LDAP with the ATN directory, these would need to be standardized. The two options are:
   1. Use ASN.1. The difficulty with this is that most LDAP client toolkits are very oriented towards string defined attributes.
   2. Define string syntaxes. This is a lot of work to define, and would then force applications to develop tools to handle these syntaxes. Experience with military directory shows that it is hard to get consistent vendor implementation of complex string syntaxes.

In summary, Isode views that there are clear disadvantages to using LDAP, and so recommends DAP access to the ATN Directory.

AFTN Address Mapping

In addition to direct support of the Extended ATS Message Service, it is also useful to consider support of AFTN Address Mappings.

ICAO have specified a mechanism to achieve this in Chapter 6 (ATS Message Handling) of the Comprehensive Aeronautical Telecommunication Network (ATN) Manual (Part III. Applications guidance material), section 6..2.1.5.10-17. The approach specified is not a standard, but is for guidance.

The key to performing the mapping is the information held in the DIT under the Organization ‘ICAO-MD-Register’. Essentially, every organization that operates AMHS and/or ATN directory will have an entry in this part of the DIT, corresponding to their AFTN address prefix. This can be four digits for an organization, or two digits for an entire country. This entry specifies the necessary information to algorithmically generate an O/R Address. It also indicates the part of the DIT (Directory Management Domain) that supports this part of the AFTN address space, so that the full mapping can be achieved by a single directory.

There are two key operational considerations to supporting this mapping:

1. A central directory needs to be established to support the ICAO MD Registry, that will manage the registration of organizations. This will be a relatively small directory, eventually holding a few hundred entries (one for each X.400 Management Domain (MD) participating in the global AMHS network). This directory might be operated on behalf of ICAO.
2. The data from this registry needs to be highly replicated, so that it will be available locally in order to make the mapping efficient. Use of X.500 DISP is key to achieving this.

Long term deployment of this function would depend on a central system. Given the small size of the directory, it would be quite practical and sensible for an individual CAA to manage a private version of this mapping tree, prior to central provision.

Isode’s Plans

This section summarizes Isode’s plans in relation to the ATN Directory.

Isode Recommendations on Standardization

Deployment of a global ATN Directory has various standardization implications, which have been referred to in this document. These recommendations are summarized here.

An Approach to Demonstrate ATN Directory

This paper has shown how an ATN Directory can be deployed, in particular in support of extended SARPs in AMHS. This section notes briefly how this might be demonstrated, and suggests a three stage demonstration.

1. Use of a replicated Isode directory server, to show (either directly or through a demonstration AMHS API):
   1. Verification of AMHS users, using the ATN directory.
   2. Determining AMHS capabilities (MTCU characteristics) as the basis for an AMHS application to support extended SARPs security and body parts.
   3. Demonstration of AFTN Address mapping to O/R Address and Directory name, using a central mapping registry.
2. Integration of the Isode directory server with a partner AMHS application, showing:
   1. Support for extended SARPs capabilities over directory
   2. Interworking between two logical deployments of the AMHS application.
   3. Directory integration across the two deployments, working both with and without replication.
3. Interworking between two independent AMHS applications, showing extended SARPs with directory support.
4. Use of a central directory, to show that two ATC organizations can have a coherent ATN directory service, using interconnection through the central directory (i.e., no direct links).