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.temp...@boeing.com _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
