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

From: "T.J. Kniveton" <[email-masked]>
Date: Fri, 21 Apr 2006 03:12:40 -0700

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.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 21 Apr 2006 13:48:54 +0300

Hi T.J.

thanks for the summary

as i see it, w.r.t. RO problem i think we need three steps:

- First identify potential scenarios where RO is interesting.
   In this part, i think we have clearly identified that there
   is a very strong use case for globally moving networks.
   It would be nice, as you point out, if other folks
   from other use cases come up and speak up their needs

- Second, for each of the identified use cases, define
   a requirements set for the RO operation/solutions
   for that specific use case
   In particular, for the only identified use case, the
   gloablly moving netwroks, a reqs docuemtns is needed
   imho. As you point out, there seems to be preliminary
   work in this space, so i guess we have somewhere to
   start from

- Third, propose solutions for the use cases identified
   that are compliant with the identified scenarios

I guess the first step needs to be done here and now, in order to 
determine in which problems we will be working on, and the second and 
third steps should be reflected in the charter as specific charter 
items, for each of the use cases we identify during this charter 
disucssion.

So, again, this is the moment imho for people with other use cases to 
bring them to the list

regards, marcelo

El 21/04/2006, a las 13:12, T.J. Kniveton escribió:

> weeks ago, regarding the rewording of the (n,n,n) item in the charter. 
> (Sorry I haven't been commenting lately).
>
> 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.
>
> 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.
>
>   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?
>
> 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.
>
> 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.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Apr 2006 16:38:56 +0200

> Network Mobility. However, we have to be careful here.

I agree we need to be careful.  The WG was founded on a Mobile IP basis.
  However, the WG has somehow monopolized the word "Mobile Router" too.

I'd say that use of Mobile IP on the Mobile Router makes sense in many
circumstances.  But it's not the only means that people have tested and
deployed Mobile Routers.  A hub equipment manufacturer sells a "Mobile
Router" that doesn't do Mobile IP, but does IP and 2 wireless interfaces
and an Ethernet.  It's "Mobile" in that it attaches to wireless networks
that allow it to move.

If one is ready to accept that the session continuity and permanent
reachability at a Home Address is not necessarily a strong requirement
in some cases (at least not in terms of permanent _IP_ address) then a
different framework for Mobile Router protocols can be planned.

Another point is that when we started the WG we were saying it makes no
sense to put a NAT on the MR.  However, experience shows that some
testbeds with MRs do just that - run NAT and DHCP on the Mobile Router.

Other problems can come from the PAN world.  There's really a growing
number of small devices with multiple wireless interfaces running IP.
But in only a few cases do they communicate at IP level.  They mostly
use the IP capability to talk straight to the infrastructure.  If they
could go through a common Mobile Router (which itself could change from
Mobile Router to simple LFN) then the IP routing will be involved.

> the BGP tables. I believe Terry already gave us a list of
> so that NEMO can be deployed.

I would be interested in working on topics solving how "Mobile Routers"
are deployed, not necessarily "NEMO".

> If there are deployments that are facing these issues, they can be
> brought forward to be studied at this phase.

Some issues I see about deployments is that session continuity and 
reachability at a permanent address is not seen as an equivalent to 
Mobile IP, and different technologies offer it sometimes.

Alex

---

From: "Davis, Terry L" <[email-masked]>
Date: Fri, 21 Apr 2006 08:17:04 -0700

TJ

I'll try to put out an update next week on aviation considerations.

Take care
Terry

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Friday, April 21, 2006 7:39 AM
> To: T.J. Kniveton
> Cc: ml-nemo WG
> Subject: Re: [nemo] Rewording of RO work in the charter
> 
> T.J. Kniveton wrote:

---

From: "Davis, Terry L" <[email-masked]>
Date: Fri, 28 Apr 2006 21:45:49 -0700

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.

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 29 Apr 2006 21:24:00 +0300

Hi Terry,

This is exactly what we need imho, thanks!

Are you considering to put this in a ID?, i think this would be very 
useful

Some comments below...

> of these is probably an extreme stretch.

maybe...

perhaps it would be good to clasify these requirements according to 
their importance. I mean i guess that there are some of them that are 
critical and that a solution that doesn't fulfill those is a 
non-starter, while maybe there are others that are more like 
nice-to-have and you can maybe can live without (don't know, just 
asking)

> simultaneously.  The desired aircraft state will be to have two links

I am kind of confused w.r.t. the role of the providers in these two 
points above...

I mean in the first point, i understand that the goal is ubiquity, 
meaning that the mobile network is able to obtain internet connectivity 
using different technologies available. So when you talk about multiple 
provider you mean multiple "first hop" providers.

However, the second one, is perhaps more general, an it seems that you 
are considering other issues like general fault tolerance, where you 
want two independent paths to the Internet, wihtout a single point of 
failure in the Internet connectivity provision, and you also seems to 
be able to distribute the load among the different ISPs

In summary, the first one is about having multiple access links to the 
fixed internet while the second one seems to refer to the capability of 
having multiple ISPs that provide indepndent paths to the internet , am 
i reading this correctly?

> or operational certified providers)

again, are talking about the access link only or the actual ISP to the 
internet?

> constraints when handing off between links.

i guess we have two different cases here: when the new bandwidth is 
enough for carrying the ongoing communications and when it is not. In 
the first case, i guess that the goal is to distribute the load along 
the different access links so that all can be fitted. On the second 
case, i guess that what you want os to reduce the generated traffic for 
instance by using the congestion avoidance mechanisms, like TCP slow 
start...

> 6- Ability to maintain security through link hand off.

i guess that you want this in general no only during handoff :-)

what level of security are we cosnidering here? is it acceptable the 
"do not introduce new vulnerabilities that are not present in the fixed 
internet" criteria good enough or more is needed?

> or from an EVDO low latency link to a satellite high latency link)

sorry not following this one... could you expand?

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

this means that the access network is IPv6 and that you have nodes 
within the mobile network that are v4 and v6?

> control, airline operations, and passenger services.

this seems quite critical also...

but how this differs from having three mobile networks colocated in the 
same plane?

> 13- Ability to initiate encrypted tunnels on all links with IPSec 

thanks, marcelo