Subject: RE: [nemo] RE: Question about RO taxonomy

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 16 Jun 2004 14:39:09 +0100

> -----Original Message-----
> From: Jung-Hoon Cheon [mailto:[email-masked]]
> Sent: mercredi 16 juin 2004 03:48
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]
> Subject: RE: [nemo] RE: Question about RO taxonomy
> 
> 
> >> I have a question about RO taxonomy.
> >> In particular, I consider "nested mobile network" case.
> >>
> >> In your draft, you only consider a DSR or an AODV as a internal
> >> routing protocol.
> >> That point is my question.
> >> Why don't you consider MANET protocol of proactive method?
> >>
> >> In general, reactive method has better performance when the node
has
> >> high mobility.
> >> However, if there is a mobile network including nested mobile
network
> >> like a your example,
> >> each mobile network may has low mobility.
> >>
> >> Is there any special reason on that?
> 
> > You're right:
> 
> > The assumption was that the nodes were highly mobile regarding each
> > other. Depending on the degree and the type of mobility, various
MANET
> > approaches apply. If they are moving together as a 'solid', a
classical
> > proactive solution does the trick.
> 
> > You can use OSPF at home, make the MRHA tunnel a not so stubby area
and
> > make the MR an ASBR... In that case you can run the protocol you
want in
> > the solid cloud and exchange the routes with the HA. I'm not sure we
> > have a use case for such a deployment, though.
> 
> Most vehicles are moving along route(on the road or in the air).
> a mobile network with nested mobile networks seems a solid cloud.
> 
> Consider several buses with high school students are moving on the
road.

I wonder why you only consider high school students for that ;) 

> Each bus is a mobile network separately.
> When a student in a BUS 1 who want to communicate with other student
> in a BUS 2, each mobile router can imagine that they located in same
mobile
> network.
> 
> At that time, to get information for rechability,
> proactive solution is easier than reactive approches.
> Of course, proactive solutions may load heavy work on mobile routers.
> 
> > Maybe we can modify the text to make it more open (and vague
actually :)
> > Do you feel it's needed?
> 
> IMHO we apply MANET protocol as a internal routing protocol case by
case.
> I wonder why did you only consider reactive solutions for that.

Note that the word 'reactive' is never used. DSR and AODV are listed
because both protocols are already extended to connect to the
infrastructure via a gateway, which is the subject of the chapter, and
not because they are reactive. DSR had the gateway for a long long time,
and, if I'm right, Ryuji is an author of the draft that extends AODV in
the same fashion. So both are listed as example, but are not intended as
a restriction in any fashion :)

In your example of a convoy, the (proactive) OSPF evolution that is
being debated at the MANET WG seems to apply perfectly. You can make
each bus an area, and the inter bus radio can be an area 0. Students do
not have to be 'mobile', and the convoy is moving as a 'solid'.

NEtwork MObility comes into play when you want that structure to
communicate with the rest of the world. Does each bus manage its own MR,
or does one take over for the whole group. In the first case, we are
trivially back to basic. The second case - when one bus takes over the
whole convoy- is an example of surrogate. 

MANET is considered in the taxonomy for the Internal Routing and gateway
model. If the gateway is MIP enabled then it's akin to the surrogate
model. Otherwise the gateway needs to inject the routes in the
infrastructure, or NAT the addresses within the mobile network.

We have studied this in the lab and for our own use cases -we expected a
bit less 'solidity' then your convoy-, a LORA proactive MANET seemed
optimum inside the mobile cloud. Then it appeared that DHCP + NEMO was a
cool approach to make the TLMR a surrogate gateway (a NEMO version of
HMIP) and we drafted that. 

What do you think?

Pascal