Hi Joe, The areas I described are very much wrapped around mobility, and for AERO mobility is handled through dynamic neighbor cache updates over the AERO interface. It is very important that these mobility events do not get propagated into dynamic routing protocols like OSPF, which would clobber low data rate data links like LDACS and many varieties of SATCOM. Dynamic neighbor cache updates in the same manner as described in RFC4861 are the method employed by AERO.
Thanks - Fred From: Joe Touch [mailto:[email protected]] Sent: Tuesday, December 06, 2016 2:48 PM To: Templin, Fred L <[email protected]>; Lucy yong <[email protected]>; Brian E Carpenter <[email protected]>; [email protected] Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels On 12/6/2016 2:43 PM, Templin, Fred L wrote: Hi Joe, I am looking at multilink nodes like manned aircraft and unmanned aerial vehicles that may have many active aviation data links, e.g., SATCOM, LDACS, 4G, AeroMACS etc. The links will be either available or unavailable at various phases of flight. But, AERO lays down a single IP layer interface (the aero0 interface) so that the aviation data links are seen as underlying interfaces each having one or more addresses. These underlying addresses are then seen as the L2 addresses for the AERO interface. You can accomplish the same thing using virtual interfaces using dynamic routing. See the following: J. Touch, T. Faber, "Dynamic Host Routing for Production Use of Developmental Networks<http://www.isi.edu/touch/pubs/icnp97/>," in Proc. ICNP '97, Atlanta, Oct. 1997, pp. 285-292. Underlying interfaces may come up and go down dynamically during a flight, and their addresses may change dynamically, e.g., if they hand over from cell tower A to cell tower B. It is AERO's job to take care of any mobility related links and always keep neighbors informed of the current L2 addresses and availability. But, it all still looks like a single interface (aero0) to the IP layer. You can do the same thing using IP forwarding without needing to bury the forwarding decisions inside the link. Joe
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
