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 REQ | | | --------------> | | | LOGON RSP | | | <-------------- | | ... | | | | Message | | | <-------------- | | | ACK | | | --------------> | | ... | | | | | 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 REQ | | ------------------> | | LOGON RSP | | <------------------ | ... | | | Message exchanges | | <-----------------> | ... | | | | | 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 | +----------+ +----------+ +---------+ +--------+ | | | | Register Client | | | | -----------------> | | | | Register Confirm | | | | <----------------- | | | ... | | | | | | | 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, . [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]