Impacts of IP on ATN Applications

ACP-WG-I-03/WP-11

8 October 2007

AERONAUTICAL COMMUNICATIONS PANEL (ACP)

WG I – Internet Protocol Suite – 3rd MEETING

Aarhus, Denmark, 8-12 October 2007

Impacts of IP on ATN Applications

Presented by the Greg Saccone

Summary

This paper looks at the approach to modifying the ATN applications to ensure that they can operate over the developing IP subnet. 1. Introduction

This paper looks at the approach to modifying the ATN applications to ensure that they can operate over the developing IP subnet. In assessing the changes, a few guidelines were established:

- No operational-type changes to the applications by this group. These should of course be handled by operational bodies.

- Any changes to the application should have a migration path from current implementations (i.e. no ‘big bang’ changes). This means that native IP solutions can be considered, but the group should define how current implementations will be migrated.

- Operational and technical requirements that were in place for the development of the original ATN are still considered valid. It is assumed that any performance characteristics that were established still apply. If there are requirements that the group feels no longer apply, they will be considered on a case-by-case basis.

- The applications should be subnet-independent. Specifications of the applications should be applicable to both OSI and IP-type subnets if at all possible.

- Any changes to encodings need to be thoroughly investigated. The ASN.1 PER format appears to still be valid, and is preferable in the air-ground case due to bandwidth limitations.

2. Application Interface (Upper Layer Communication Service)

Currently, Figure 1 of the Detailed Technical Specifications of the IPS only refer to the application’s interface to the IPS as via an “OSI/IP convergence” function, which is conceptually contained within the application. The ATN/IPS guidance material states that the application interface to the TCP/UDP layers is made via RFC 3493, the Basic Socket Interface Extensions for IPv6. Likewise, there is a reference for an application interface to the IP layer via RFC 3542, which is the Advanced Sockets Application Program Interface for IPv6.

This is correct from a programming point of view, but from an applications point of view, if another layer of abstraction is not placed between the application and lower layers, it would mean that every application would need to be modified to interface directly to the transport and/or network layers. This is undesirable, as it intimately ties the applications to the lower layers. It is preferable to separate the applications from the lower layers.

Therefore, there is still need for a ULCS-type functionality which defines a more generic way for the applications to access the lower layer services. It would seem the best way forward would be to modify the ULCS to support the IPS technical specifications. This

2 would have the benefit of requiring almost no changes to the applications themselves. The suggested updated diagram for the Detailed Technical Specifications for the IPS is shown in Figure 1 below. The connections to the IPS would be made via sockets as defined in the previously referenced-to RFCs, but these references would need to be moved to the ULCS. The ATN/IPS guidance would be modified to reference the new ULCS.

Figure 1. Updated Architecture Diagram

The ULCS will need to be able to determine whether it is communicating with TCP/IP or OSI type transport, and would need to map the parameters accordingly, the main ones being the Class of Communications and Security parameters.

The Class of Communications could conceivably be mapped to the Traffic Class field, but this needs to be confirmed with the group. The security required parameter does not need to be explicitly mapped to a corresponding IPv6 parameter, as security is just an indication of whether or not security will be used.

If the group agrees, proposed modifications for the ULCS will be investigated and presented at the next meeting.

3. Air-Ground Applications

The current air-ground applications are separated from the lower layers by the ULCS. As mentioned previously, if the ULCS can be modified to accommodate the new IPS lower layers, then the applications themselves can be left as is, with the exception of CM.

3 Currently CM carries the NSAP as a parameter, as well as some OSI-specific information.

CM will most likely need to change to allow carriage of IPv6-type addresses and/or security information. Information may also need to be added depending on the mobility solution chosen. Ideally, CM would be independent of the mobility solution. Changes to CM for mobility will not be considered at present until mobility solutions are further defined. Provisions for exchanging IPv4 and IPv6 addresses will be added to the ASN.1 in the interim, and presented to the group at the next meeting.

4. Ground-Ground Applications

AMHS is based on the X.400 standard, and is able to run over IP using RFC1003 (TP0 over TCP/IP). The usage of AMHS over IP is easier to accomplish for AMHS than for the air-ground applications since AMHS addressing information is not passed between the applications themselves, nor are any application changes required to implement IP (the IP addresses will need to be added as addresses for peer MTAs, which is a local configuration change as opposed to an application change). The issue then becomes one of ensuring that neighboring AMHS systems are able to communicate over IP.

However, interest has been expressed to investigate a native-IP type solution. In order to consider this under the assumptions of modifying the applications for IP, a transition path needs to be identified. There are currently RFCs which describe the mapping between IP-type email (SMTP) and X.400-type email, notably RFC 2156 “Mapping between X.400 and RFC 822/MIME”. This RFC specifies a gateway-type functionality and defines how services would be mapped from SMTP to X.400. If followed, this may allow interoperability between a more standard email application and an OSI-based AMHS. However, some of the notable issues that arise are that not all of the service elements supported in X.400 have an equivalent SMTP function. This means that gateway translations could lose important information, and also that standard email-type applications may not be able to indicate necessary required service elements for AMHS functions.

If a native IP augmentation for AMHS is to be further investigated, there would need to be a detailed mapping of the various elements of service for AMHS onto RFC822. If there are areas that are not easily mapped, there may need to be modifications to the standard email protocol to address this. It is suggested this investigation be done for the next meeting.

AIDC uses the ULCS, so would have the same considerations as the air-ground applications. The data for AIDC is ASN.1 encoded; a native IP application would either need to use the ASN.1 or provide a gateway functionality similar to that as described for

4 AMHS above. Since there are no current RFCs that describe AIDC, this would result in a custom application mapping. Also, since AIDC is a specialized ATS function, it does not map inherently to an existing native IP application.

5. Other Considerations

There has been mention of the usage of XML-type formatting instead of ASN.1. While XML is an easily-readable text-based format, it is not necessarily bandwidth-efficient. This is particularly an issue for the air-ground applications. Additionally, the use of XML would have a major impact on existing aircraft architectures.

If a gateway-type implementation for AMHS is used, then XML may be used on the ground-ground links. However, performance considerations would need to be investigated, as there would need to be gateway functions to translate application data between XML and ASN.1.

It should also be noted that many ASN.1 compilers have XML-conversion functions.

6. Where to Capture

The IPS Technical Manual as well as the implementation guidance will need to be modified to accommodate the application changes. However, these references will be higher-level descriptions; the detailed application changes themselves would not be contained in these manuals.

Therefore, an important aspect is where these changes to the ATN applications will be recorded. Traditionally, they would make up a part of the 9705 or 9880 documents. One issue is that the first edition of 9880 has already been finished for some of the affected volumes. This would mean additional changes and republishing. Another issue is that publication of other volumes is dependent on whether or not ICAO will support the future 9880 volumes. If not, this would leave some of the applications without a home.

Another issue is that other standards bodies are creating changes to the applications, mainly regarding message set-type details (e.g. the ICAO ADG making changes to ADS). These bodies will need a place to provide this information so that it too can be maintained and referenced.

Current options to record this information:

- ICAO continues in its capacity as a publisher of SARPs, and the modified ATN applications are published under 9880 (assumed with assistance to ICAO from the States)

- ICAO stops publishing detailed technical information; in this case an external standards body would need to publish the information, and these bodies would need to be referenced by the ICAO SARPs. Examples could include RTCA or

5 AEEC.

- Others?

7. Conclusions

The following work is recommended for continuing to modify the ATN applications for use over the IPS:

1. A new diagram showing the ULCS be added to the current Technical Manual

2. The ULCS be modified to use the IPS; this will minimize impacts on the air-ground applications and AIDC

3. Based on the ULCS modifications, the air-ground applications and AIDC need to be revisited to ensure there are no changes required

4. The CM application may need additional modification; initially, carriage of IP-type addresses will be investigated, and as mobility solutions mature, additional changes required (if any) can be assessed

5. The X.400-SMTP conversion RFCs need to be investigated more in-depth. In particular, the required elements of service need to be looked at to ensure that the RFCs address the mapping needed, and recommendations made

6. The publication plan needs to be coordinated amongst different groups within ICAO and industry to find the best place to capture additional technical requirements.

The meeting is invited to note the contents of this paper, provide any comments and endorse the work package.