Internet Engineering Task Force C. Bauer Internet-Draft S. Ayaz Intended status: Informational DLR Expires: January 5, 2009 July 4, 2008 ATN Topology Considerations for Aeronautical NEMO RO draft-bauer-mext-aero-topology-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 January 5, 2009. Bauer & Ayaz Expires January 5, 2009 [Page 1] Internet-Draft ATN Topology July 2008 Abstract The intention of this draft is to provide an overview of the topology of the Aeronautical Telecommunications Network to help with the analysis of the possible options of NEMO RO within this context. The intention is to allow taking the existing NEMO RO solution space analysis document and cross-check it with the aeronautical environment presented within this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Topology of the ATN . . . . . . . . . . . . . . . . . . . . . 5 3.1. Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Global Structure . . . . . . . . . . . . . . . . . . . . . 6 3.3. Points of Attachment . . . . . . . . . . . . . . . . . . . 7 3.4. Location of Home Agents . . . . . . . . . . . . . . . . . 9 3.5. Trust Relationships . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Bauer & Ayaz Expires January 5, 2009 [Page 2] Internet-Draft ATN Topology July 2008 1. Introduction 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, especially on the topology of the Aeronautical Telecommunications Network (ATN), to what is provided in the requirements document and to allow checking the feasability of the possible RO solutions, based on both the requirements and the additional information provided within this document. 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(SARPs) the ATN. 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 ICAO is currently producing 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. Definition of the mobility support for aircraft within this new ATN architecture is underway in the ICAO and will form the basis of new ATN manual [icao9896]. It is expected that the reader is familiar with the two before mentioned documents and the NEMO Support Terminology [RFC4885]. We will use the term Mobile Router (MR) to refer to an aircraft and vice versa if we write aircraft we are referring to an MR. It should be noted that some aircraft might be considered as only a mobile host in the MIPv6 sense. As this document is related to NEMO RO we are restricting the scope to aircraft for which NEMO is an applicable solution. Bauer & Ayaz Expires January 5, 2009 [Page 3] Internet-Draft ATN Topology July 2008 2. Terminology ACSP An Air Communications Service Provider which operates an access network for aeronautical purposes that includes 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 (gACSP) and additional smaller, local ACSPs (lACSP). 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. Although ICAO has an influence on ANSPs, these organizations also have their own (network) policies. 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 even 'subnetwork' (e.g. the VDL Mode 2 subnetwork). This expression is equivalent to the more common 'access technology' terminology in other industries or the IETF. Bauer & Ayaz Expires January 5, 2009 [Page 4] Internet-Draft ATN Topology July 2008 3. Topology of the ATN The aim of this section is to provide a description of the topology of the ATN, based on how it partially already exists and how it is planned. 3.1. Nodes 3.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 both ATS and AOS traffic, as the access technologies/access networks provide support for both services. 3.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 and might usually not 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. Both ATS and AOS CNs are fixed, non-moving nodes. 3.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. 3.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 3.4. Bauer & Ayaz Expires January 5, 2009 [Page 5] Internet-Draft ATN Topology July 2008 3.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' 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 Bauer & Ayaz Expires January 5, 2009 [Page 6] Internet-Draft ATN Topology July 2008 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). 3.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 show the direct routing path between the communication peers and in combination with Figure 1 should allow to illustrate the complete picture of 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. 3.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 (CLNP and 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 Bauer & Ayaz Expires January 5, 2009 [Page 7] Internet-Draft ATN Topology July 2008 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 my means of a transit 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 the aircraft can attach to. In this case the ANSP is also a local ACSP. Although the infrastructure is provided by the ACSP, it is owned by the ANSP and therefore also under administrative control of the latter (and therefore an operational domain of its own). 3.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. In any case, the communication model is different from ATS where the CNs change from time to time and are Bauer & Ayaz Expires January 5, 2009 [Page 8] Internet-Draft ATN Topology July 2008 geographically close to the MR, whereas 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 in a subnet that belongs to the airline, and the routing path from the 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 operational domains could be between ACSP #1 and AO. For example this could be even further generalized into having the possibility that the ACSP the MR attaches to is a local ACSP which in turn is only connected to the ANSP. In this case, the routing path would be MR -> ACSP -> ANSP -> ACSP #2 -> 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 ACSP to provide connectivity for the subnet the CN is connected to. 3.4. Location of Home Agents An important discussion is the location of the HA(s) that is also directly related to the advertisement of the MNPs. There are two possible options: Bauer & Ayaz Expires January 5, 2009 [Page 9] Internet-Draft ATN Topology July 2008 1. An airline has a HA which is serving the 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 second choice is more reasonable for two reasons. First, for airlines having a relatively small number of aircraft it will not be cost effective to deploy HA(s), in opposite to the ACSP that can act as a Mobility Service Provider. Second if the HA(s) are deployed at the ACSP and a local mobility management protocol like [I-D.ietf-netlmm-proxymip6] is deployed the aircraft will be "at home" as long as it is directly attached to that ACSP (as in Figure 2) and hence there will be no tunnelling overhead from the MR point of view. Nevertheless it is theoretically also possible that large airlines might act as their own Mobility Services Provider operating Home Agents themselves. 3.5. Trust Relationships Important for the RO scheme are the relationships between the different nodes and networks, and we therefore provide a short overview related to this. 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 Aeronautical Communication Service Providers are certified, but other aircraft might be compromised and/or misbehave. As can be seen from Section 3.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 acting as Mobility Services Provider. 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 controversial and the time to deploy it and its availability is difficult to predict. Having certificates between the aircraft and all potential CNs within ANSP networks is therefore difficult to answer with a clear 'yes', although in the Bauer & Ayaz Expires January 5, 2009 [Page 10] Internet-Draft ATN Topology July 2008 very long term such a PKI is supposed to exist, albeit problems with these certificates are still possible. It should be noted that ANSPs often have their own additional local (network) policies, that might impose additional restrictions. It is therefore important to consider cases where, even when a PKI is available, the certificates might not accepted by the ANSP nodes, due to local policies, expiry, etc.. 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 is partially already available today (e.g. X.509 certificates in Secure ACARS). Bauer & Ayaz Expires January 5, 2009 [Page 11] Internet-Draft ATN Topology July 2008 4. Security Considerations This document only presents terminology and topological information. There are no security issues in this document. Bauer & Ayaz Expires January 5, 2009 [Page 12] Internet-Draft ATN Topology July 2008 5. 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. Bauer & Ayaz Expires January 5, 2009 [Page 13] Internet-Draft ATN Topology July 2008 6. References 6.1. Normative References [I-D.ietf-mext-aero-reqs] Eddy, W., Ivancic, W., and T. Davis, "NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks", draft-ietf-mext-aero-reqs-02 (work in progress), May 2008. [I-D.ietf-netlmm-proxymip6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-18 (work in progress), May 2008. [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. 6.2. Informative References [icao9705] ICAO, "Manual of Technical Provisions for the Aeronautical Telecommunications Network (ATN), Third Edition", June 2002. [icao9896] ICAO, "Draft Manual for the ATN using IPS Standards and Protocols", February 2008. [link2000] Eurocontrol, "Link2000+ Network Planning Document", May 2007, . Bauer & Ayaz Expires January 5, 2009 [Page 14] Internet-Draft ATN Topology July 2008 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 January 5, 2009 [Page 15] Internet-Draft ATN Topology July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Bauer & Ayaz Expires January 5, 2009 [Page 16]