[lisp] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

"Templin, Fred L" <Fred.L.Templin@boeing.com> Fri, 05 May 2017 21:51 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08CE1270A3 for <lisp@ietfa.amsl.com>; Fri, 5 May 2017 14:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.521
X-Spam-Level:
X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvbjbXUv-4hV for <lisp@ietfa.amsl.com>; Fri, 5 May 2017 14:51:29 -0700 (PDT)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E9B126BF7 for <lisp@ietf.org>; Fri, 5 May 2017 14:51:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v45LpSvg043706; Fri, 5 May 2017 14:51:28 -0700
Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v45LpMsc043672 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for <lisp@ietf.org>; Fri, 5 May 2017 14:51:22 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 5 May 2017 14:51:21 -0700
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 5 May 2017 14:51:21 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "lisp@ietf.org" <lisp@ietf.org>
Thread-Topic: A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network
Thread-Index: AdLF4mwFxtjCXUvzS2SxYgfVqmzg3w==
Date: Fri, 05 May 2017 21:51:21 +0000
Message-ID: <c80f1b7cd4b348589116c2556a469d59@XCH15-06-08.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/mgoxZa-Q-xipyTdaPRh7Koq1oPg>
Subject: [lisp] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 May 2017 21:51:31 -0000

LISP'ers,

Since the closing of the Routing Research Group (RRG), I have been focused
on furthering the development of my own technologies that began there,
and really haven't paid much attention to LISP - even to the point that I never
even took the time to read the LISP specs. That has changed over the past
couple of days, and now I think I have something to discuss that should
interest this group.

I am involved in a working group that is designing an IPv6-based Internetwork
for the worldwide civil aviation air traffic management system. The network
will be known as the Aeronautical Telecommunications Network with Internet
Protocol Services (ATN/IPS). It will involve air traffic controllers communicating
with aircraft that use aviation data links with low bandwidth and high delay
properties (with some links having bandwidth as low as 32Kbps!). Each aircraft
will receive a /56 IPv6 prefix taken from a shorter ATN/IPS service prefix
(e.g., 2001:db8::/32).

Aircraft may undergo mobility events throughout their various phases of flights,
such as handing off between cell towers, switching from a terrestrial data link
to a satellite link, etc. So, the network needs to be designed to handle most
mobility events at the intra-site level and only propagate mobility events to
the network core when there is a major movement between sites. To that
end, I have published a document titled:

"A Simple BGP-based Mobile Routing System for the Aeronautical
Telecommunications Network":
https://datatracker.ietf.org/doc/draft-templin-atn-bgp/

This document describes a simple BGP-based hierarchy in an overlay network
using tunnels. But after my reading over the past couple of days, I have come
to realize that it is an example of a LISP+ALT topology.

However, for this specific use case I see a possible departure from the
recommendations of RFC6836. Namely, the packets produced by aviation data
links need to be treated as precious commodities that are to be delivered
with the highest degree of reliability possible, which means that they must
not be dropped due to an on-demand mapping table lookup. This means
that the packets should be routed over the LISP+ALT topology unless or
until a mapping is discovered. RFC6836 recommends against this in the
general sense, but I believe what we have here is an exception.

The packets produced by aircraft need to be treated as precious commodities
by the network since there is no way to tell if the aircraft will be able to
retransmit if the packet is dropped - each packet should be considered
as potentially the aircraft's very last transmission before falling silent.

So, what I think we should consider is whether there is a class of packets
that should *always* be routed over the LISP+ALT topology, i.e., instead
of serving as data probes. This could also give rise to a hybrid topology
where safety-of-flight-critical packets are unconditionally forwarded over
the ALT topology while lower priority packets are forwarded from ITR to
ETR in the true LISP sense.

Please have a look at my document and consider this use case I am
describing. Please post comments to the list.

Thanks- Fred
fred.l.templin@boeing.com