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

[[e-mail]]

Terry,

You forgot two.

Low cost.

Zero delay.   :-)


Actually, I was at the last Internation Civil Aeronautics Organization 
(ICAO) working group meeting on IPv6.   I may be very possible that a 
combination of routing using OSPFv3 for IPv6 and NEMO with MONAMI 
policy based routing can get most of what is required by aeronautics - 
actually perhaps all if some requirements are modified to match the 
paricular flight portions. As it is today,  many of the delay 
requirement cannot be met by satellite because the delay requirements 
are the same for take-off and landing (surface area) as the are for 
enroute (plane in general flight at 30,000 ft).   Obviously these 
requirments should not be the same.

Today, most of the requirment are not met for all conditions and have 
never really been adequately tested under all conditions and all loads. 
   For example, make-before-break is not really done as one has to 
reset frequency on the radio during some handover situations.  This is 
a break before make situation.

The requirment to send Air Traffic Control (ATC) over one link and Air 
Operations Control  (AOC) over another is also not done - to the best 
of my knowledge.  If I got the story right, much of the AOC was done 
before the ATC and then the ATC started using AOC links.  The airlines 
don't want to pay for multiple links and generally do not operate 
multiple links.  So what are requirements established years ago is 
actually not done in practice.


Will




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