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

From: "Davis, Terry L" <[email-masked]>
Date: Mon, 1 May 2006 08:43:46 -0700

Will

Comments below...

Also thoughts on Marcelo's suggestion for an ID?

Take care
Terry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, April 30, 2006 7:36 PM
> To: Davis, Terry L
> Cc: T.J. Kniveton; ml-nemo WG
> Subject: RE: [nemo] Rewording of RO work in the charter
> 
> Terry,
> 
> You forgot two.
> 
> Low cost.
> 
> Zero delay.   :-)
> 

We are considering contracting with Stephen Hawking to re-write some of
the basic laws of physics to solve this problem with geo-stationary
satellite links; FTL communications! ;-)

> 
> 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.
> 
Are you going to be in Copenhagen on the 15th at that meeting?

> 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.
>
If the normal state of the aircraft becomes having two ATC/AOC capable
links available at most times, make-before-break is not necessarily a
requirement as the traffic can be routed over the other link during a
handoff.
 
>
> 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, I see this being done by using separately addressed networks
carried over the same links.  I don't see any of us using entirely
different links for ATC, AOC, and Passenger services.  I do see some of
the links being reserved for ATC/AOC use essentially the limited
capacity bands.
 
> 
> Will
> 
> 
> 
> 
> Quoting "Davis, Terry L" <[email-masked]>:
> 
> > 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:[email-masked]]
> >> 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.

---

From: [email-masked]
Date: Sun, 30 Apr 2006 22:35:51 -0400

Terry,

You forgot two.

Low cost.

Zero delay.   :-)

never really been adequately tested under all conditions and all loads. 

Will

Quoting "Davis, Terry L" <[email-masked]>:

> These would be our ideal mobility solution.  I realize that meeting all
> 1- Ability to "dock" with numerous Internet service providers utilizing
> 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
> 4- Ability to re-profile traffic to match available link capacity and
> 5- Ability to seamlessly hand off existing network connections without
> 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
> 12- Ability to establish connections to multiple onboard networks over a
> single link and hand off them simultaneously.  (We expect the aircraft
> 13- Ability to initiate encrypted tunnels on all links with IPSec before
> passing traffic.
>
>
>> I have been watching the conversation started by Marcelo a couple of
>> 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.
>> type of situation we want to solve. I agree with Andrew that we don't
>> get custom agreements between a mobility provider and ISPs it (or its
>> customers) uses, etc.
>>
>> 3) Route optimization - "Performance" as Marcelo called it - avoiding
>> is what we have discussed so far, and we need a stronger boundary so
>> requirements for the RO situation of interest would be helpful here.
>>
>> 4) Aviation - question of "if" to use Mobile IP... NEMO base does use
>> routes into the BGP tables. I believe Terry already gave us a list of
>> "the only" or even "the" solution for RO. It is simply something that
>> at this point. We need more definition of what and how to solve, and
>> bitregarding Japanese auto makers, but not much else. I also used to
>> charter language and/or change milestones so that these things can be
>> accomplished.
>
>
>