Subject: [nemo] New draft draft-morioka-nemo-mrcoop-00.txt

From: Hitoshi MORIOKA <[email-masked]>
Date: Tue, 12 Jul 2005 12:30:09 +0900 (JST)

Hi all,

I submitted a new draft on multiple mobile routers cooperation.
Until the draft becomes available at the official site,
you can get it from the following site.

http://www.root-hq.com/~hmorioka/draft-morioka-nemo-mrcoop-00.txt

Here is the abstract:

   This protocol intended to provide cooperation between mobile routers
   in a mobile network.  A mobile network is usually connected to the
   Internet through mobile routers with wireless interfaces.  Link
   quality of the wireless interface changes frequently and rapidly.  In
   case of several mobile routers in a mobile network, MNN should use
   the MR that has the best link quality.  This protocol makes all MRs
   in a mobile network share link quality of MRs each other. Propagation
   of routing information in a mobile network is not out of sight of
   this draft.

Any questions and comments are welcome.

Hitoshi MORIOKA ([email-masked])

---

From: kishore mundra <[email-masked]>
Date: Tue, 12 Jul 2005 19:22:57 +0530

Hi Hitoshi,

I have a few questions in the draft:

1. Are we assuming that all the MRs have the same HA? Because whosoever
becomes primary MR may not be able to send Binding    Update for other MRs
in case they have different HA.

2. There can be situations (because of dropped packet or at the time of
transition from one primary MR to another) where a few of the MRs chooses
some MR2 as primary MR and few MRs may still use the previous primary MR,say
MR1 as primary MR. During this phase, what if both of them send a Binding
Update to HA? 
The previous primary MR may send BU as the timeout of sending BU whereas the
new MR sends assuming he has become the new primary MR. It can be that the
Binding Update from new primary MR(MR2) is replaced again by the Binding
Update of previous primary MR,MR1.

3. What about the synchronization of BU to the change in routes between MRs.
I am asking so because once a BU is completed successfully, the primary MR
is responsible for transferring packets to the other MRs. So what if routing
table gets updated first and BU got delayed, the previous primary MR may not
be able to route the packet and vice versa!

4. U have chosen a value of 300ms for deletion of entry from LM and 100ms
for sending LMMs, any particular reason for going for so less value. It may
flood a lot of messages in the network and may change primary MRs too
rapidly which will create its own set of problems!!!

Looking forward for your reply. In case I have misunderstood any part,
please do clarify.

Regards,
Kishore.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hitoshi MORIOKA
Sent: Tuesday, July 12, 2005 9:00 AM
To: [email-masked]
Subject: [nemo] New draft draft-morioka-nemo-mrcoop-00.txt

Hi all,

I submitted a new draft on multiple mobile routers cooperation. Until the
draft becomes available at the official site, you can get it from the
following site.

Here is the abstract:

---

From: Romain KUNTZ <[email-masked]>
Date: Wed, 13 Jul 2005 21:01:33 +0900

Hi Hitoshi,

Regarding draft-ietf-nemo-multihoming-issues-02, it seems that your
draft only focus on the (n,1,n) topology (Multiple MRs, Single HA,
Multiple MNPs), and only solves a few issues (MR failure). Do you have
any plan to extend your solution to support more scenario, and solve
more issues?

Your solution only allows to have one active MR at a time. When a NEMO
has multiple MRs, we should take benefit from this topology to use all
of them together for load sharing, load balancing, bi-casting or any
purposes that multiple paths could benefits to.

If the goal of your solution is to provide the selection of the MR with
the best access to the Internet, then what could be the benefits of your
solution compared to an unique Mobile Router with several egress
interfaces?

Regards,

Romain

Hitoshi MORIOKA wrote:
> Hi all,
> 
> I submitted a new draft on multiple mobile routers cooperation. Until
> the draft becomes available at the official site, you can get it from
> the following site.
> 

-- 
Romain KUNTZ
[email-masked]

---

From: Hitoshi MORIOKA <[email-masked]>
Date: Thu, 14 Jul 2005 22:57:22 +0900 (JST)

Hi Kishore,

At first, I'd like to describe my motivation.
I'm so sorry, it should be described in the draft.

The draft mainly focuses on Make-Before-Break handover by cooperation
of the MRs.  But a link information exchange scheme like this may help
selection of MRs for load sharing, load balancing and so on.

From: kishore mundra <[email-masked]>
Subject: RE: [nemo] New draft draft-morioka-nemo-mrcoop-00.txt
Date: Tue, 12 Jul 2005 19:22:57 +0530

> in case they have different HA.

Yes. I assumed all the MRs use the same HA as the first step.
I suppose it can be expandable to accommodate multiple HAs,
if the MRs can share the home addresses, shared-secrets and so on,
for example.

> Update of previous primary MR,MR1.

You got that right.  All MRs which think they have a valid tunnel
to the HA should include the flags or the options that indicate
they have a valid tunnel in their LMMs.  
By doing so, the MRs can know duplicate BUs after recieving
the next LMM.

> be able to route the packet and vice versa!

It's also right.  I suppose it can be avoided by the LMM described above.
The previous primary MR changes its routing table after it receives
the LMM with a valid tunnel option/flag from the new primary MR.

> rapidly which will create its own set of problems!!!

The values are tentative and I'd like to discuss them.

I think the updating interval of the link metric table(LMT)
depends on the moving speed of the MRs and the design of the cells.

In case of the MRs on a train which moves at 360km/h=100m/s,
1s means a movement of 100m distance.
The maximum range of IEEE802.11g wireless LAN in OFDM54 mode
was approximately 400m according to our experiment. 
We used 3dBi tri-step co-linear antenna for both
the AP and the MR, and there were no obstacles between them.
So the train will pass through a cell in 8s in such an environment.

Considering Make-Before-Break handover by cooperation of the MRs,
the MR should update the LMT as fast as possible because
the latency of updating delays the decision of handover.
If the sum of the updating latency and the handover latency is
greater than the time of passing through the overlapped area
of the cells, the MRs cannot complete MBB handover.

On the other hand, shorter interval makes more traffic in the
mobile network, as you said.
If the MRs exchange LMMs by unicast, the traffic increses O(n^2).
For example, if the average size of the LMMs is 200 bytes and
10 MRs are in the mobile network, the traffic is 1.4Mbps.
If we should assume more MRs in the mobile network or less traffic,
we may increse the updating interval or using broadcast.

I know that NEMO WG is considering not only wireless LAN but also
various media and we may have to use other media in such a case.
But I think we should consider practical possible cases like it.

Thanks for your questions and comments.

Best regards.

---

From: Hitoshi MORIOKA <[email-masked]>
Date: Thu, 14 Jul 2005 23:04:04 +0900 (JST)

Hi Romain,

From: Romain KUNTZ <[email-masked]>
Subject: Re: [nemo] New draft draft-morioka-nemo-mrcoop-00.txt
Date: Wed, 13 Jul 2005 21:01:33 +0900

> any plan to extend your solution to support more scenario, and solve

As I mentioned in another mail, it mainly focuses on the MBB handover
for now.

> purposes that multiple paths could benefits to.

I think it can be extended to help to select the MRs for these benefits.
For example, there is a relation between the RSSI value and
the throughput on the wireless LAN.
The link metrics can be used for the hint of load sharing,
load balancing and so on. And it will help to switch the MRs
before failure.

> solution compared to an unique Mobile Router with several egress

Sure. We already implemented the MR with two WLAN egress interfaces
for MBB handover and it worked well at the speed of 260km/h.
But there are restrictions of the location of the MR.

If we'd like to install one antenna at the front of a train and
another at the tail, we must extend the radio cable over the
entire train in case of a single MR with multiple interfaces
even if the optical fibres or ethernet cables are there.
It causes less signal and more noise.
If the multile MRs can cooperate, we can connect the MRs at the
both side of the train without any losses.

Best regards.