RE: [nemo] Rewording of RO work in the charter

["Davis, Terry L" <[e-mail]>]

T.J.

You'll probably wish that you hadn't asked for this...

These would be our ideal mobility solution.  I realize that meeting all
of these is probably an extreme stretch.

Take care
Terry

=================================================================
Generally the aviation mobility requirements are:

1- Ability to "dock" with numerous Internet service providers utilizing
different media; satellite (KU & L), EVDO, 802.11/802.16 airport;
hardwired Ethernet "gatelink".

2- Ability to be multihomed to different providers over different links
simultaneously.  The desired aircraft state will be to have two links
active always.

3- Ability to assign traffic for specific providers links only (safety
or operational certified providers)

4- Ability to re-profile traffic to match available link capacity and
constraints when handing off between links.

5- Ability to seamlessly hand off existing network connections without
dropping the session (we do this today).

6- Ability to maintain security through link hand off.

7- Ability to continue to receive multicast traffic after hand off.

8- Route optimization such that on hand off to a new link,
connection/session routing is optimized to the new ground site.

9- Ability to maintain QoS on hand off with the capacity of the new link
(You may hand off to a link with a smaller capacity or higher error rate
or from an EVDO low latency link to a satellite high latency link)

10- Ability to support both IP-v6 and IP-v4 mobile platforms from an
IP-v6 network.

11- Ability to receive priority multicast/broadcast messages.

12- Ability to establish connections to multiple onboard networks over a
single link and hand off them simultaneously.  (We expect the aircraft
to have at three independent onboard isolated networks; air traffic
control, airline operations, and passenger services.

13- Ability to initiate encrypted tunnels on all links with IPSec before
passing traffic.


> -----Original Message-----
> From: T.J. Kniveton [mailto:[e-mail]]
> Sent: Friday, April 21, 2006 3:13 AM
> To: ml-nemo WG
> Subject: [nemo] Rewording of RO work in the charter
> 
> Folks,
> 
> I have been watching the conversation started by Marcelo a couple of
> weeks ago, regarding the rewording of the (n,n,n) item in the
> charter. (Sorry I haven't been commenting lately).
> 
> We need to figure out how to massage the concepts being batted around
> so that we have something tractable that we can work on and complete.
>  From the discussion so far, I tend to think:
> 
> 1) We need somewhat more concrete idea of the requirements for the
> type of situation we want to solve. I agree with Andrew that we don't
> want to get bogged down in this, and I do believe Terry gave us a
> list for the Conexion scenario quite a while ago. Perhaps he or
> Andrew could give an updated list.
> 
> 2) We need a bit more analysis still on the RO problem space, based
> on some idea of requirements for the solution to be worked out
> (according to charter items). Specifically, the effects of having a
> "Mobile ISP" vs. "ISP-independent mobile home networks", the
> implications of that for the global BGP tables, how likely it is to
> get custom agreements between a mobility provider and ISPs it (or its
> customers) uses, etc.
> 
> 3) Route optimization - "Performance" as Marcelo called it - avoiding
> long tunneling (geographically) - or avoiding expensive links. This
> is what we have discussed so far, and we need a stronger boundary so
> that we can define what is to be solved in these specific
> circumstances. Otherwise this walks down the road toward many other
> long-standing issues. My view is that having a good list of
> requirements for the RO situation of interest would be helpful here.
> 
> 4) Aviation - question of "if" to use Mobile IP... NEMO base does use
> it because it made sense. It's possible we have another deployment
> case where it does not make sense, but we still want a solution for
> Network Mobility. However, we have to be careful here.
>    There are some general network mobility problems.. such as
> multiple ISPs, having high-cost links, and how/whether to inject
> routes into the BGP tables. I believe Terry already gave us a list of
> requirements for this type of situation - can we review that?
> 
> 5) Regarding HAHA - As Pascal mentioned, this wasn't supposed to be
> "the only" or even "the" solution for RO. It is simply something that
> addressed a shown need, and so I considered it to be something that
> could be added for future work. But according to the list items
> above, the group is not including or excluding any certain solution
> at this point. We need more definition of what and how to solve, and
> the implications of various approaches first. I would like to hear
> the RO-analysis authors chime in on this one.
> 
> Besides Aviation, I have asked numerous times for anyone who is
> actually deploying NEMO or NEMO-like technology to give us industry
> input for requirements. Aside from aviation, I have heard a little
> bit regarding Japanese auto makers, but not much else. I also used to
> know things about some large cell phone makers that might be doing
> these things, but never enough to make a good list of requirements.
> 
> Remember, our goal here is to reshape the charter to solve problems
> so that NEMO can be deployed. If there are deployments that are
> facing these issues, they can be brought forward to be studied at
> this phase.
> 
> In conclusion, I would like to have a bit more discussion, and then
> maybe people can offer suggestions on how specifically to reword
> charter language and/or change milestones so that these things can be
> accomplished.