[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/