ACP/WG N/SGN1

WP913

Page 1 of 5

ACP/WG N/SGN1

WP705

AERONAUTICAL COMMUNICATIONS PANEL(ACP)

Working Group N - NETWORKING

SUBGROUP N1 – Internet Communications Services

7th meeting

Malmo, Sweden, March 27 – March 31, 2006

Working Paper

Aircraft mobility

This is an informational paper that describes the ATN SARPs mobility solution phrased in IP terms. The paper describes, that moving to IP the ATN mobility solution can be implemented but not deployed with commercially off the shelf products. The WP was prepared by Christian Kaas-Petersen of Ericsson.

The ATN SARPs and the CAMAL documents describe how it shall be possible for a work station (an application) on the ground to reach a workstation (an application) in an aircraft even while the aircraft is moving from A to Z. In this description, the ATN network is built using ISO specified protocols CLNP, ISIS, and IDRP. For the mobility solution to work, special routing policies must be applied at those routers using IDRP to exchange routing information with neighboring routing domains.

With the strategic decision to move from CLNP to IP, it is of interest to formulate the mobility solution in terms of IP. For this presentation IPv4 is used in the examples, but IPv6 would be no different, because IPv4 and IPv6 use the same routing mechanisms. The equivalent of IDRP is BGP, and so for mobility to work, special routing policies must be applied to the BGP routers. The good news is that these policies can be defined in terms of IP; the bad news is that these policies are not found in commercially available IP routers.

The ATN mobile solution assumes at the outset the definition of an all-aircraft prefix. I shall take this all-aircraft prefix to be 10.0.0.0/8. This is just an example, because it is a bad choice seen from IP as this prefix is considered a private prefix and this prefix must never be used in the global Internet. Anyway, this all-aircraft prefix is then broken down in a hierarchical way in the following way: Each airline is given a subnet of the all-aircraft prefix, say Quantas is given 10.1.0.0/16, SAS is given 10.2.0.0/16, and so on. Then SAS will split their subnet up in subordinate subnets, one such subordinate subnet per aircraft. For example the aircraft Harald Viking may be given 10.2.17.0/24. Work stations on board Harald Viking will be allocated an IP address from the 10.2.17.0/24 prefix, say the work station in the cockpit hosting the CPDLC application is given the IP address 10.2.17.51.

One first question is who owns the all-aircraft prefix? In some sense it is owned by ICAO because it is defined for the good of mobility of all aircrafts. On the other hand, ICAO may not be the administrator of the prefix, ie handing out a prefix to airlines applying for a subnet and overseeing the prefixes are used in the intended manner. A second question is whether a prefix for the global Internet can be obtained? The IPv4 address space is not yet exhausted, but really convincing arguments must be put forward in order to acquire a slash-eight (/8) prefix. If a prefix for the global Internet can be obtained the mobility solution may be possible in the global internet, otherwise the mobility solution will only be possible in an enterprise network, ie a network which is totally disconnected from the global Internet.

The mobile solution presupposes the network on the ground is divided up in routing domains, within which the RIP or ISIS or OSPF protocol are used, and between two such routing domains the BGP protocol is used. Further each aircraft is considered a routing domain, and so BGP is used between the ground and the air. So BGP is used between two ground routing domains and also between a ground and an aircraft routing domain. I’ll consider the two uses of BGP in turn.

BGP is used between ground and aircraft primarily because the amount of bytes exchanged between two BGP-speaking routers is small. This is made possible, because BGP uses TCP, and TCP is a reliable transport mechanism. The reliability is used such that a BGP router need only send its routes (ie prefixes) once. However, establishing the TCP session between the ground and the aircraft is not straightforward, because the two endpoints do not know each other’s IP address, a necessary condition for the TCP connection to be established. In the SARPs this is circumvented by a protocol on the lower layers is used to exchange such addresses, but such a solution is a form of layer violation, and an IP solution must be found. It could as simple as one endpoint using DHCP to ask for the address. When each endpoint knows the IP address of the other endpoint, the BGP connection can be established. The aircraft will send its prefix to the ground, while the router on the ground will send a default router to the aircraft.

On the ground BGP is used between routing domains. For the mobility solution to work, I’ll take the example prefixes from before. SAS has been given the prefix 10.2.0.0/16, and this prefix is known at SAS’s home base. From this home base, the 10.2.0.0/16 prefix is spread to the ground network. So initially any work station wanting to talk to a work station in an SAS aircraft will have its packets sent to the SAS home base, but the aircraft is not there, and so the packets are dropped. When Harald Viking is attaching to the ground, its 10.2.17.0/24 prefix is spread in the first routing domain, and then spread only to those routers from which the more general prefix 10.2.0.0/16 has been seen. This way, the home prefix is spread out in the entire ground network, and each aircraft prefix is spread only in the direction towards the home. The way to spread prefixes is not normal BGP behavior. Normal BGP behavior is to spread a prefix in all directions. If this normal way to spread a prefix shall be modified in any way, the BGP router must have defined one or more policies. The typical policies is to aggregate a prefix and a somewhat more special policy is to deaggregate a prefix, but still both aggregates and deaggregates are spread in all directions away from the source. The policy defined above for having aircraft mobility is working counter to this: the aircraft prefix shall be spread only in one direction, and this direction is dynamically learned. Such policies are not possible on commercially available IP routers.

Further, a number of other tricks must be applied in order to get BGP to work on the air ground link. The convention is that between routing domains, the two domains must have a unique domain number (denoted an autonomous system number). An autonomous system number is of two bytes, and so it is impossible to give a unique number to each aircraft, even in an enterprise network. Also the propagation time of a prefix may have to be considered: typically a BGP router learning a prefix will await 15 to 30 seconds before propagating it to its peers, giving a long delay before the aircraft prefix is known at the home base.

The reason for all this mobility is that the work stations in the aircraft and in the air traffic control centers can send messages to each other. Even if routing is working perfect, only a prefix is known in the network. So the air traffic control center knows the 10.2.17.0/24 prefix is available, but does not know that 10.2.17.51 is the IP address of the work station in the cockpit of Harald Viking. Either a use of DNS, resolving say cpdlc.sas751.sas.dk or cpdlc.sas751.aero to 10.2.17.51, can be used, or mandatory addresses can be required, for example requiring 10.2.17.1 to be the work station in the cockpit. From the cockpit, the work stations on the ground are similarly unknown.

Even if these issues on routing and on endpoints are resolved, there remains the issue of security labels, that is some traffic shall take one route to a destination while other traffic take another route to the same destination. This feature of having two routes to the same destination depending on the traffic is not available in IP. To build such two routes additional information concerning prefixes must be carried with OSPF or BGP routes, but that is not possible. There can be two motives for having such two routes: quality of service or secure links. Concerning the quality of service, the IP solution is differentiated services where IP packets are labeled, and intermediate routers handle high priority labeled packet ahead of packet with lower priorities or with no priorities. This is an improvement on the best effort approach which was initially the only possibility in IP, but still the IP network does not give any guarantees of delivery. Concerning the secure links, the IP solution is to use IPsec including IKE between the two endpoints in need of confidentiality or authenticity.

Using BGP and IP requires a number of special consideration particularly on the air-ground link, and the for the ground network the mobility solution has to be redefined, because it is not possible to define the policies as specified in the SARPs on commercially available routers. I’ll finish with a proposal for how the aircraft mobility can be obtained. Let the entire ground network be one routing domain running OSPF. It should be possible to define a suitable hierarchical address plan, and then divide the entire routing domain in some OSPF areas, one OSPF area for each part of the hierarchy. Still BGP will be used between the ground and the aircraft, but on the ground the prefix will be injected in OSPF as externally learned routes. This has several benefits: externally learned prefixes are spread in the entire domain, and each external prefix is spread separately. The spreading is fast, less than 1 second per hop, and because the prefix is spread allover, no special policies have to be configured. Because the aircraft prefixes are spread as external information the OSPF routers have very little work to do to update its routing table.

Page 1 of 5