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

[marcelo bagnulo braun <[e-mail]>]

Hi Terry,

I have been reading the email that you sent to the ppml list about 
aviation requirements and PI addressing (which was very clarifiyng BTW) 
and i have another question about the requirements below. In 
particular, you seem to have 3 different networks on board... does all 
the requirements affect all the three networks? because i mean for 
instance in the case of the closed network, i guess that it is easier 
to provide some of the features since the peers are clearly located and 
cannot be anywhere in the global internet and any solution would only 
affect the close network/routing system...


thanks, it is a really interesting problem statement this one that you 
have here

regards, marcelo

El 29/04/2006, a las 7:45, Davis, Terry L escribió:

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