One document matched: draft-bauer-mext-aero-topology-00.txt
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, <http://www.eurocontrol.int/link2000/gallery/
content/public/files/documents/NPD_3.4.pdf>.
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]
| PAFTECH AB 2003-2026 | 2026-04-22 13:22:49 |