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

[Dino Farinacci <[e-mail]>]

> LISP’ers,

Fred, thanks for the email. Sorry for the delay on my response.

> 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.

Well a lot of machinery has been added for the various new and modern use-cases coming up these days.

> 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).

Okay.

> 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:

Note, have a look at draft-farinacci-lisp-predictive-rlocs-02. It has been called for adoption for a working group document. With this mechanism, we minimize packet loss an wouldn’t have to have a control-plane topology carry data packets as you are suggesting below.

> "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.

Well if you extend the LISP-ALT from the map-resolvers/map-servers to the xTR, then you have that push mechanism available. And then you know where an ETR is for a given EID. 

> However, for this specific use case I see a possible departure from the
> recommendations of RFC6836. Namely, the packets produced by aviation data

Because the topology was provisioned and capacity planned for moving small Map-Request messages that had different delivery requirements then packet 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.

I don’t think you need to. I think the reason you suggest that is because a LISP-ALT topology knows “where topologically” an EID is. But if you have that, you could just encapsulate to the last-hop BGP xTR. So the LISP-ALT topology wouldn’t be needed for packet data.

> The packets produced by aircraft need to be treated as precious commodities

That is what everyone says. Just not your industry.  ;-)

> 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.

Is there a multicast requirement?

> 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.

Give us your opinion about the suggestions above.

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

I did. We used this idea in many places to have a “push-based” overlay using the BGP protocol. I probably have implemented 3 different variants of it. So it is a well-known tool.

Thanks,
Dino

> 
> Thanks- Fred
> [e-mail]
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp