Internet Engineering Task Force C. Bauer
Internet-Draft S. Ayaz
Intended status: Informational DLR
Expires: March 13, 2010 September 9, 2009
ATN Topology Considerations for Aeronautical NEMO RO
draft-bauer-mext-aero-topology-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 13, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Bauer & Ayaz Expires March 13, 2010 [Page 1]
Internet-Draft ATN Topology September 2009
Abstract
The aviation industry is in the process of moving from legacy and
ISO-based protocols to an IP-based environment. This task will
require adoption, modification and/or creation of IETF related
protocols. The intention of this draft is therefore to provide an
overview of the operational environment and the topology of the
Aeronautical Telecommunications Network to the IETF.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Access Technologies . . . . . . . . . . . . . . . . . . . . . 6
3.1. Wifi/Gatelink . . . . . . . . . . . . . . . . . . . . . . 6
3.2. WiMAX . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. SATCOM . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Long range air-to-ground . . . . . . . . . . . . . . . . . 7
4. Topology of the ATN . . . . . . . . . . . . . . . . . . . . . 8
4.1. Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Global Structure . . . . . . . . . . . . . . . . . . . . . 9
4.3. Points of Attachment . . . . . . . . . . . . . . . . . . . 10
4.4. Location of Home Agents . . . . . . . . . . . . . . . . . 13
4.5. Trust Relationships . . . . . . . . . . . . . . . . . . . 13
5. ATN Applications . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. ATS Applications . . . . . . . . . . . . . . . . . . . . . 15
5.2. AOS Applications . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
8. Changes from -00 . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Bauer & Ayaz Expires March 13, 2010 [Page 2]
Internet-Draft ATN Topology September 2009
1. Introduction
The ATN is a global network interconnecting ground-ground networks
and air-ground access networks used for Air Traffic Services (ATS)
and Airline Operations Services (AOS). As part of the ICAO
Convention, ICAO has published Annex 10 which standardizes the ATN
(SARPs). The current ATN technology and architecture are defined by
the ATN Manual documents published by ICAO [icao9705], based on the
ISO protocol CLNP, using a modified version of the IDRP interdomain
routing protocol to support mobility of aircraft. This version of
the ATN is only partially deployed at the present time. Meanwhile an
ICAO working group has produced an amended version of the manual that
allows the ATN to be an internetwork based on IPv6 for both ground-
ground and air-ground communications. States have already begun
deployment of the ground portion. For supporting mobility of
aircraft within this new ATN architecture the Mobile IPv6 protocol
familiy has been chosen and referenced within the new ATN manual
[icao9896].
This draft tries to provide an overview of the aeronautical
operational environment, the access technologies currently sed for
planned for usage in the future as well as application layer
signalling.
Most discussions are currently focussed on NEMO Route Optimization
work and this draft tries to help with the analysis of the possible
options of NEMO RO within this context. The Network Mobility Route
Optimization Solution Space Analysis [RFC4889] provides a
comprehensive overview of the possibilities how RO can be performed.
The selection of the right solution has to be based on the
requirements, which were defined for aviation in
[I-D.ietf-mext-aero-reqs]. The aim of this document is to provide
additional information about the aeronautical environment, apart from
what is alreaedy provided within the requirements document.
Ultimately, this should help in selecting the most suited solution
for the NEMO RO problem.
Bauer & Ayaz Expires March 13, 2010 [Page 3]
Internet-Draft ATN Topology September 2009
2. Terminology
ATS, AOS, PIES
The three different service classes as introduced in the
requirements document [I-D.ietf-mext-aero-reqs]. PIES is
considered as non-safety related, whereas ATS is safety-related.
While AOS is at the moment an atomic service class, it is foreseen
that in the future its applications are going to be split into
safety- and non-safety related subclasses.
ATS message exchanges have to fulfill strict latency requirements,
therefore making an RO mechanism necessary. While this is also
true for safety-related AOS messages, the delay requirements are
not as strict as for ATS.
ACSP
An Air Communications Service Provider operating access networks
for aeronautical purposes, including air/ground data links.
Currently there are two global ACSPs utilizing terrestrial and
satellite link technologies for providing ATS/AOS services.
However in the future there might be several global ACSPs (gACSPs)
and additional smaller, local ACSPs (lACSPs). The usage of the
word ACSP is generic and can refer to either a local or a global
ACSP, depending on the context.
gACSP
Global ACSP - see definition of ACSP. A global ACSP has a world-
wide network that spans over several continents.
lACSP
Local ACSP - see definition of ACSP. A local ACSP owns a network
that is limited to a continental region or a certain nation and
its boundaries. Examples for this are Air Navigation Service
Providers that operate their own air-ground access network.
ANSP
An Air Navigation Service Provider that manages the air traffic
within a country or geographic region. Generally each ANSP has
its own (ground-ground) network, and in addition the ANSP might
also be an ACSP within that geographical region by operating its
own air/ground access network, which might be due to security/
policy or cost reasons. In this case we can call the ANSP a local
ACSP.
Bauer & Ayaz Expires March 13, 2010 [Page 4]
Internet-Draft ATN Topology September 2009
Note: At least in Europe these are the only two existing business
models as of now.
ICAO regulations and SARPs have to be respected and considered by
the ANSP, nevertheless these organizations also have their own
(network) policies. It should also be stated that ANSPs are
usually governmental or at least state-owned institutions.
Data Link(s)
In the aviation environment it is common to call the air interface
(layers 1 and 2 of the OSI model) 'data link' or sometimes also
'subnetwork' (e.g. the VDL Mode 2 subnetwork). This expression is
equivalent to the more common 'access technology' terminology in
other SDOs or the IETF.
Bauer & Ayaz Expires March 13, 2010 [Page 5]
Internet-Draft ATN Topology September 2009
3. Access Technologies
In the following we provide a short overview of IP-carrying
technologies that are currently used or foreseen to be used in the
future. In general there are regulatory aspects that limit the type
of traffic that can be sent over certain frequencies, according to
ITU-R regulations and allocations. Non-safety related services can
not be carried over Aeronautical Mobile (Route) Service and
Aeronautical Mobile Satellite (Route) Service bands.
3.1. Wifi/Gatelink
The well-known IEEE 802.11 family is already in use at airports today
for AOS, operating in standard frequency bands. The AEEC, an
aeronautical SDO, has specified Gatelink standards (802.11b/g, DHCP,
DNS) that have the following characteristics:
1. Gatelink 822: 802.11i with WPA/WPA2
2. Gatelink 763: 802.11i with EAP-TLS (mutual authentication with
client certificates) and RADIUS as AAA protocol
Apart from the Gatelink standard, airports are also using "normal"
802.11 equipment (e.g. WPA2 with static passwords). Airport
authorities can operate the Wifi system themselves whereas at certain
airports the access points are even operated by the airlines
themselves.
3.2. WiMAX
It is planned to use the IEEE 802.16e standard for airport surface
communications to carry ATS and safety-related AOS messages in a
dedicated (safety-related) frequency band (at 5 Ghz with 60 Mhz
bandwidth). The investigation and specification of this AeroWiMAX
system is currently work in progress.
At the same time WiMAX systems within the standard frequency bands
(2.5 Ghz, 3.5 Ghz, etc.) could also be used for non safety-related
AOS applications and passenger internet access within airports.
The WiMAX security provisions might be reused for the aeronautical
version of the standard.
3.3. SATCOM
Satellite communication systems are already in use today:
Bauer & Ayaz Expires March 13, 2010 [Page 6]
Internet-Draft ATN Topology September 2009
1. Connexion by Boeing: used to provide (IPv4) connectivity for PIES
with a bandwidth of several Mbits/s. Not available anymore.
2. Inmarsat Swift-Broadband: Used for PIES and AOS communications,
although not certified for safety-related services. Bandwidth is
in the range of up to several 100 kbits/sec. Carries IPv4.
The currently available satellite systems that are certified for
safety-related services are not providing native IP connectivity.
Certain satellite operators are currently planning next-generation
satellite constellations that will natively support IP and will most
likely also be certified for safety-related services.
3.4. Long range air-to-ground
The following technologies are terrestial systems relying on a
network of base stations that can be used for communication when the
aircraft is on cruise altitude.
1. L-Band Digital Aeronautical Communications System (L-DACS): two
proposals for L-DACS are currently work in progress and one of
them will be chosen for safety-related services (ATS and
partially AOS). Bandwidth will probably be in the range of 1-2
Mbits/sec. Security provisions are not available (as of now).
2. Aircell: based on the 3GPP2 CDMA EV-DO standard and provides
several Mbits/sec. It is currently only used for PIES (non-
safety related).
Bauer & Ayaz Expires March 13, 2010 [Page 7]
Internet-Draft ATN Topology September 2009
4. Topology of the ATN
This section provides a description of the topology of the ATN, based
on how it partially already exists and how it is planned.
4.1. Nodes
4.1.1. MR
The generic term 'airborne router' is also used in the aviation
environment for the mobile router. It is reasonable to assume that
in the future there is one IP based mobile router that handles ATS
and a seperate one for AOS and PIES traffic. Certain AOS messages
might most likely also be routed over the ATS router (as it is
already the case today). As in the future, at least from a strictly
regulatory point of view, it is foreseen that AOS will be split into
safety and non-safety related parts. In that case, the safety-
related applications of AOS might be handled by the ATS router
whereas non-safety related AOS applications rely on the the PIES
router.
There are currently discussions related to potentially integrating
ATS with AOS/PIES. It is not clear yet however how this integration
could take place and whether it will happen at all.
4.1.2. ATS/AOS CNs
ATS CNs are Air Traffic Service Units (ATSUs) that refer to the
controllers managing the air space. These nodes are located within
the ANSP networks and are in general dynamic - as the aircraft
traverses different regions of the world, the CN (the responsible
ATSU) changes as well and is geographically close to the aircraft.
The CNs mentioned here are the communication peers from the IP point
of view and do not necessarily have to be the "real" end system.
An AO refers to an Airline Operations domain where AOS CNs are
located. This is generally the airline headquarters/operations
center or an airport. These nodes are relatively static throughout a
flight; a number of 2 CNs can usually be expected. The connection
options between the subnets at the airport and the airline
headquarters can be manifold:
1. The subnet at the airport uses an Internet connection provided by
the airport authority and establishes an IPsec VPN tunnel to the
headerquarter
2. The subnet at the airport uses an Internet connection provided by
a commercial Internet Service Provider and establishes an IPsec
Bauer & Ayaz Expires March 13, 2010 [Page 8]
Internet-Draft ATN Topology September 2009
VPN tunnel to the headerquarter
3. The subnet at the airport uses a connection provided by a gACSP
to the headerquarter
Both ATS and AOS CNs are fixed, non-moving nodes.
4.1.3. MNNs
The MNNs of the ATS and AOS domains on board an aircraft are, as
mentioned in [I-D.ietf-mext-aero-reqs], LFNs and potentially even
LMNs. They are operated by and are under control of the airline,
although ICAO regulations and standards affect the ATS systems.
4.1.4. HA
We are considering HA(s) that are serving the ATS and AOS domain.
The location of these entities is discussed in Section 4.4. With the
network-seperation between safety and non-safety related services,
there will most likely also be two Mobility Service Providers
operating different HAs.
4.2. Global Structure
As already explained in Section 2, access networks to which an
aircraft may attach to are operated by either an ACSP or an ANSP.
How these operational domains are related to each other in
topological terms is explained below.
+---+ +---------+ +---------+ +----------+
| | <--> | ANSP #1 | <-------+ | ANSP #4 | <--> | lACSP #3 |
| | +---------+ | +---------+ +----------+
| | v ^
| | +---------+ |
| | | ANSP #3 | <--+ +-----+
| | +---------+ +---------+ | |
| | <--> | ANSP #2 | ^ +--+ v
| | +---------+ | | +----+ +---------+
| | v v | | <--> | ACSP #4 |
| +------------------------------+ +-----+ | +---------+
| gACSP #1 | <--> | gACSP #2 |
+----------------------------------+ +----------+
Figure 1: Global topology of the ATN.
The topology shown in Figure 1 is not representing the current real
structure of the ATN, it is merely trying to show the basic
hierarchical and interconnection layout. The prefixes 'g' and 'l'
Bauer & Ayaz Expires March 13, 2010 [Page 9]
Internet-Draft ATN Topology September 2009
before ACSP refer to global and local ACSPs respectively, whereas a
missing prefix indicates that this ACSP can be either global or
local. The difference between local and global is further elaborated
below.
At the borders of ACSP and ANSP networks BGP routers are peering with
each other and advertising routes. ANSPs have connections to other
ANSP network(s) and to at least one gACSP.
It is important to note that ACSP access networks can be either local
or global. An example for a local ACSP is an airport data link
operated by the airport company (e.g. lACSP #3 in the figure),
although this is not existing by the time this was written. As of
today, two global ACSPs (gACSP #1 and gACSP #2) exist which have a
world-wide network; they are comparable to the tier 1 service
providers in the Internet. An ANSP can reach every other ANSP via
these ACSPs in case they do not have a peering with each other or if
there is no route over other ANSPs. ACSP #4 could be either local
(airport) or global (not directly part of the ATN but interconnected
via a gACSP).
It should also be mentioned that the direct interconnections between
the ANSPs are, at the moment, only used for ground-ground
communications and it is not yet clarified whether these connections
might also be usable for the purpose of transit services/data
forwarding of air-ground communications in the future.
Although at the moment planning only foresees ANSPs being connected
to a single gACSP, it is possible that in the future a connection to
more than one gACSP will be available (site multihoming as for ANSP
#3 in the figure).
Redundancy, at least for ATS, is an important topic: it is not just
limited to redundant routers, but also includes redundant lines (from
a physical ).
4.3. Points of Attachment
Basically an aircraft can attach to either an ACSP or an ANSP access
network. There are three possibilites for how this attachment may
look like and how it affects the routing path between MR and CN. The
figures below show the direct routing path between the communication
peers. In combination with Figure 1 this should allow to illustrate
the the different possible paths implied by a certain RO solution, as
well as the implications and limitations due to the placement of the
functional RO entities.
Bauer & Ayaz Expires March 13, 2010 [Page 10]
Internet-Draft ATN Topology September 2009
4.3.1. ATS
The routing paths in the Figures below only depict ATS traffic, where
the CNs are located inside the ANSP access network.
+----+
| MR | <--+
+----+ |
v
+---------+
| ACSP #1 |
+---------+
^
| +--------+
v | +----+ |
+------+ | CN | |
| ANSP +----+ |
+---------------+
Figure 2: MR-CN communication via an ACSP.
Figure 2 shows a deployment that already exists today (not IP based
though). The ANSP is not operating the access network in his country
himself but contracts an ACSP for providing connectivity to aircraft.
The data traffic from the MR flows through an access router of the
ACSP and then, possibly via additional hops inside the ACSP, goes to
the boundary router located at the ANSP where the packets are
forwarded to the CN that resides inside this network.
+----+
| MR | <--+
+----+ |
v
+---------+ +---------+
| ACSP #1 | <--> | ACSP #2 |
+---------+ +---------+
^
| +--------+
v | +----+ |
+------+ | CN | |
| ANSP +----+ |
+---------------+
Figure 3: MR-CN communication via two ACSPs.
Figure 3 shows another potential deployment where the ACSP the
aircraft is attached to is not directly connected to the ANSP.
Routing between the MR and the CN is achieved by means of a transit
Bauer & Ayaz Expires March 13, 2010 [Page 11]
Internet-Draft ATN Topology September 2009
provider such as ACSP #2.
+----+
| MR | <------+
+----+ |
v
+--------------+
| ANSP +----+ |
| | CN | |
| +----+ |
+--------------+
Figure 4: MR-CN communication directly via ANSP.
The option shown in Figure 4 is another existing deployment. The
ANSP is operating its own access network to which aircraft can attach
to. In this case the ANSP is also a local ACSP. Although the
infrastructure might be provided by the ACSP, it is owned by the ANSP
and therefore also under administrative control of the latter (and
therefore topologically a part of the ANSP network).
4.3.2. AOS
The routing paths in the figures below depict AOS traffic only, where
the CN might be located at the airline headquarters, the destination
airport or somewhere else. The communication model is significantly
different from ATS where the CNs change from time to time and are
geographically close to the MR; for AOS the rate of CN changes is
lower and the geographical distance can also be larger.
+----+
| MR | <--+
+----+ | +-----------+
v | +----+ |
+---------+ | AO | CN | |
| ACSP #1 | <-...-> | +----+ |
+---------+ +-----------+
Figure 5: MR-CN communication with access router at the ACSP.
The scenario in Figure 5 is similiar to that presented in Figure 2
where the aircraft attaches to an ACSP access network and the traffic
is directly routed to the CN. The location of this node is in
general usually in a subnet that belongs to the airline, and the
routing path from ACSP #1 to the CN could be direct (subnet of CN is
directly connected to ACSP #1). The dots in this figure (and the
subsequent ones) indicate that several networks/operational domains
could be between ACSP #1 and AO. For example this could be even
Bauer & Ayaz Expires March 13, 2010 [Page 12]
Internet-Draft ATN Topology September 2009
further generalized into having the possibility that the ACSP the MR
attaches to is a local ACSP that in turn is only connected to a
gACSP. In this case, the routing path would be MR -> lACSP -> gACSP
-> AO -> CN.
+----+
| MR | <--+
+----+ | +-----------+
v | +----+ |
+---------+ | AO | CN | |
| ANSP #1 | <-...-> | +----+ |
+---------+ +-----------+
Figure 6: MR-CN communication with access router at the ANSP.
Figure 6 is based on Figure 4 with the MR attaching to an access
network that is operated by an ANSP. The number of hops between the
ANSP and the CN is not fixed, as there might be additional networks
in between, e.g. if the airline contracts an lACSP to provide
connectivity for the subnet the CN is connected to.
4.4. Location of Home Agents
As of now, there are no requirements by ICAO on where Home Agents
should be located. There are basically two options:
1. An airline has a HA which is serving aircraft belonging to that
airline.
2. One of the global ACSPs provides HA(s) for the airline if they
have an agreement with them.
The solution with the gACSP as Mobility Service Provider is inline
with the current business model. While airlines are not paying
anything to ANSPs for communication services, there is a business
contract between an airline and an ACSP for using the access networks
for transmitting AOS packets.
Nevertheless it is also possible that (large) airlines might act as
their own Mobility Services Provider operating Home Agents
themselves, something that could become likely for airlines that do
not have AOS communications and therefore no contract to a gACSP.
4.5. Trust Relationships
The basic trust model is comparable to the "Public Wireless Network
with an Operator" model that is presented in [RFC3756], with aircraft
being "client nodes". Aircraft can trust the infrastructure as
Bauer & Ayaz Expires March 13, 2010 [Page 13]
Internet-Draft ATN Topology September 2009
Aeronautical Communication Service Providers are certified, but other
aircraft might be compromised and/or misbehave.
As can be seen from Section 4.2, the two global ACSPs (as of today)
are playing an important role. Both ANSPs and airlines have
commercial contracts with (at least one of) them. Certificates can
be assumed between the aircraft and the ACSP, at least for the one
that the airline has a contract with.
The relationship between aircraft and ANSP - including ATS CNs within
this network - is different, as these parties do not have commercial
contracts with each other. Although there is some form of trust (the
aircraft trusts the instructions coming from an ATSU), it is
difficult to extend it on having certificates between these entities
for the near future. Discussions related to a world-wide 'end-to-
end' PKI for aviation are currently in progress, but no timeplan is
available as of now. Having certificates between the aircraft and
all potential CNs within ANSP networks is therefore difficult to
answer with a clear 'yes', although in the very long term such a PKI
is supposed to exist, albeit problems with these certificates are
still possible (e.g. lack of participation of certain countries).
It should be noted that ANSPs often have their own additional local
(network) policies that might impose restrictions (e.g. blocking of
ICMP messages). In this case performing RO might prove to be
problematic, but still an optimized path has to be established as
communication services between the aircraft and the CN have to be
provided (that meet the delay requirements).
In addition some ANSPs even have the policy of not allowing encrypted
traffic inside their network. It is also worth noting that in the
future ANSPs, at least in Europe, will have to provide communication
services to all equipped aircraft, independent of their contractual
status with any of the ACSPs. This is complicating the basic trust
model mentioned in the beginning as authenticating the aircraft (e.g.
on layer 2) might become difficult to realize.
The situation between an aircraft and its AOS CNs is different, as
both are operated by the same entity. Certificates between these
nodes could be expected, and are partially already available today
(e.g. X.509 certificates at application layer).
Bauer & Ayaz Expires March 13, 2010 [Page 14]
Internet-Draft ATN Topology September 2009
5. ATN Applications
In the following we provide an overview of ATS and AOS applications.
5.1. ATS Applications
5.1.1. Current State
The Controller Pilot Data Link Communications (CPDLC) is used for
communication between the Air Traffic Controller and the cockpit.
The application layer message exchange is shown in Figure 7, as
currently used in Europe [link2000manual].
+----------+ +-------+ +-------+
| Aircraft | | cATSU | | nATSU |
+----------+ +-------+ +-------+
<logon> | |
| LOGON REQ | |
| --------------> | |
| LOGON RSP | |
| <-------------- | |
... | |
<application exchange> |
| Message | |
| <-------------- | |
| ACK | |
| --------------> | |
... | |
<operational handover> |
| | LOF |
| | ----------> |
| NDA | |
| <-------------- | |
| | NAN |
| | ----------> |
| START-REQ | |
| <---------------------------- |
| | START-RSP |
| ----------------------------> |
| END | |
| --------------> | |
| | CDA |
| ----------------------------> |
| | |
Figure 7: CPDLC communications for ATS.
The communication model is as follows: the aircraft has to perform a
Bauer & Ayaz Expires March 13, 2010 [Page 15]
Internet-Draft ATN Topology September 2009
logon procedure to the ATSU (Logon Request and Logon Response).
Afterwards, the ATSU has flight data available and can unambiguously
identify the aircraft with the help of locally available information.
Application message exchanges can be initiated by either the aircraft
or the ATSU. They are usually completed with an Ackwnowledgement
from the aircraft.
With the aircraft moving to airspace that is controlled by another
ATSU, an operational handover is performed. The current ATSU (cATSU)
forwards aircraft logon context information via the Log-On Forwarding
(LOF) message to the next ATSU (nATSU) over the ground network.
Afterwards the cATSU sends a Next Data Authority (NDA) message to the
aircraft that authorizes the incoming connection request from the
nATSU, followed by a NAN message to the nATSU that triggers the
START-Request message. The aircraft confirms by means of a START-
Response message. The END message from the aircarft to the cATSU
then informs the old ATSU (cATSU) of session termination. The
Current Data Authority (CDA) message from the aircraft to nATSU
confirms the authority transfer.
5.1.2. Deployment
While basically there are several ATSUs per ANSP/country, the two
currently deployed systems where CPDLC is in operational use both
rely on a centralized model. This means that from the network layer
perspective there is only a single ATN end system (CN). This end
system acts as a application layer gateway distributing the
information flow to the 'real' end systems.
This model is not mandated by anyone, the decision on how to deploy
CPDLC is up to the ANSP. It is likely to assume that in the future
there will be deployments with one ATN end system per ATSU
(decentralised).
5.1.3. Future Architecture (SWIM)
There are currently ongoing efforts on defining future applications
within the scope of various System Wide Information Management (SWIM)
efforts. However, at the current stage it is too early to provide
useful information related to application architecture and
signalling.
5.2. AOS Applications
Airline communications is different as the communication peers of the
aircraft are not so frequently changing as in ATS.
Bauer & Ayaz Expires March 13, 2010 [Page 16]
Internet-Draft ATN Topology September 2009
5.2.1. Current State
A variety of communications protocols are in use for AOS, such as the
Aircraft Communication Addressing and Reporting System, (ACARS), VDL
Mode 2 (also used by CPDLC) and even IP based access networks for
certain applications.
In general, the communication procedure is similar to that of ATS:
the aircraft first performs a log-on operation and only then
information between the communication peers is exchanged. A generic
diagram of the exchanged signalling is shown in Figure 8. Note that
the logon procedure can also be implemented as an IPsec tunnel
establishment.
+----------+ +------+
| Aircraft | | CN |
+----------+ +------+
<logon> |
| LOGON REQ |
| ------------------> |
| LOGON RSP |
| <------------------ |
... |
<application exchange> |
| Message exchanges |
| <-----------------> |
... |
<logoff> |
| |
| LOGOFF REQ |
| ------------------> |
| LOGOFF RSP |
| <------------------ |
| |
Figure 8: Old AOS communications.
5.2.2. Future Architecture (AGIE)
There is currently an effort in an aeronautical SDO in defining a
common interface for application information exchanges between an
aircraft and ground-based airline systems [agiedraft]. The
architecture consists of an airborne proxy and a ground gateway and
provides store-and-foward semantics with TCP as transport protocol.
FTP is used for large file transfers.
Signalling is shown in Figure 9. The airborne client/applications/
end systems register with the aircraft proxy. In case data has to be
Bauer & Ayaz Expires March 13, 2010 [Page 17]
Internet-Draft ATN Topology September 2009
transmitted to the ground, the client will inform the proxy about its
data transfer intent via a Downlink Request message. The proxy then
retrieves the files from the client and indicates the succesful
completion of the data transfer. The proxy then sends a Downlink
Request message to the Ground Gateway, followed by the transfer of
the data itself via the Downlink message. The gateway then indicates
the availability of new data to the CN on the ground that can then
retrieve the files. As soon as the CN received all files, a cascade
of Downlink Response messages is returned to the airborne client.
+----------+ +----------+ +---------+ +--------+
| Aircraft | | Aircraft | | Ground | | Ground |
| Client | | Proxy | | Gateway | | CN |
+----------+ +----------+ +---------+ +--------+
<registration> | | |
| Register Client | | |
| -----------------> | | |
| Register Confirm | | |
| <----------------- | | |
... | | |
<application exchange> | | |
| Downlink Request | | |
| -----------------> | | |
| Retrieve Files | | |
| <----------------- | | |
| Transfer Complete | | |
| <----------------- | | |
| | Downlink Request | |
| | & Downlink | |
| | -----------------> | |
| | | Downlink Ind |
| | | -----------------> |
| | | Retrieve Files |
| | | <----------------- |
| | | Transfer Complete |
| | | <----------------- |
| | | Downlink Response |
| | | <----------------- |
| | Downlink Response | |
| | <----------------- | |
| Downlink Response | | |
| <----------------- | | |
| | | |
Figure 9: AGIE-based AOS communications.
The procedure for uplink messages, that is sending data from the
ground to airborne end systems, is similar.
Bauer & Ayaz Expires March 13, 2010 [Page 18]
Internet-Draft ATN Topology September 2009
Connections are not end-to-end as end systems only establish
connections with proxy and gateway respectively. Proxy and gateway
posses caching capabilities for enabling store-and-forward behaviour,
e.g. if a preferred link is not available, the proxy can delay
sending data to the ground.
Both gateway and ground client use X.509v3 certificates for mutual
authentication within TLS.
It should be noted that the information provided above is based on a
draft version of the AGIE.
Bauer & Ayaz Expires March 13, 2010 [Page 19]
Internet-Draft ATN Topology September 2009
6. Security Considerations
This document only presents information related to aeronautical
information systems. There are no security issues in this document.
Bauer & Ayaz Expires March 13, 2010 [Page 20]
Internet-Draft ATN Topology September 2009
7. Acknowledgements
Special thanks to Eivan Cerasi and Wesley M. Eddy for suggestions to
improve this document.
We would also like to thank (in alphabetical order) Max Ehammer,
Klaus-Peter Hauf and Phil Platt for their comments and related
discussions.
The authors have been partially supported by the European Commission
through the NEWSKY project. The views and conclusions contained
herein are those of the authors and should not be interpreted as
necessarily representing the official policies or endorsements,
either expressed or implied, of the NEWSKY project or the European
Commission.
Bauer & Ayaz Expires March 13, 2010 [Page 21]
Internet-Draft ATN Topology September 2009
8. Changes from -00
Slightly restructured document and included information on access
technologies and applications.
Bauer & Ayaz Expires March 13, 2010 [Page 22]
Internet-Draft ATN Topology September 2009
9. References
9.1. Normative References
[I-D.ietf-mext-aero-reqs]
Eddy, W., Ivancic, W., and T. Davis, "Network Mobility
Route Optimization Requirements for Operational Use in
Aeronautics and Space Exploration Mobile Networks",
draft-ietf-mext-aero-reqs-04 (work in progress),
August 2009.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004.
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007.
[RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network
Mobility Route Optimization Solution Space Analysis",
RFC 4889, July 2007.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
9.2. Informative References
[agiedraft]
AEEC, "Aircraft/Ground Information Exchange (AGIE)
Specification", Project Paper 830 ANFS Munich draft,
December 2008.
[icao9705]
ICAO, "Manual of Technical Provisions for the Aeronautical
Telecommunications Network (ATN)", Third Edition,
June 2002.
[icao9896]
ICAO, "Manual for the ATN using IPS Standards and
Protocols (Doc 9896)", 1st edition (unedited),
February 2009.
[link2000]
Eurocontrol, "Link2000+ Network Planning Document",
May 2007, <http://www.eurocontrol.int/link2000/gallery/
content/public/files/documents/NPD_3.4.pdf>.
[link2000manual]
Bauer & Ayaz Expires March 13, 2010 [Page 23]
Internet-Draft ATN Topology September 2009
Link2000+ Operational Focus Group, "ATC Data Link Manual
for Link 2000+ Services", May 2005.
Bauer & Ayaz Expires March 13, 2010 [Page 24]
Internet-Draft ATN Topology September 2009
Authors' Addresses
Christian Bauer
German Aerospace Center (DLR)
Email: Christian.Bauer@dlr.de
Serkan Ayaz
German Aerospace Center (DLR)
Email: Serkan.Ayaz@dlr.de
Bauer & Ayaz Expires March 13, 2010 [Page 25]