Subject: Re: [Int-area] IRON issue discussion

From: Scott Brim <[email-masked]>
Date: Fri, 17 Jun 2011 13:14:49 -0400

On Wed, Jun 15, 2011 at 03:51, Bob Hinden <[email-masked]> wrote:
> Fred,
>
> This sounds a lot like Mobile IPv6 with the extension that the client can
change home agents if the client get's too far away from where the the home
agent is.  I am sure the details are different, but the functionality sounds
similar.

Good point.

Fred, please compare and contrast IRON and NEMO.

Also: How does path optimization work?

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 17 Jun 2011 15:32:41 -0700

Hi Scott,

Reading RFC3963 ("Network Mobility (NEMO) Basic Support Protocol"),
NEMO is an extension of the MIPv6 protocol whereas IRON is a mobile
tunneling system unto itself. The NEMO Mobile Router construct is
essentially the same as the IRON client router, although the IRON
client can also be a singleton end system. Like NEMO, IRON seeks
to support session continuity for nodes in the mobile network, and
for the mobile network nodes to be reachable while the IRON client
router moves from one Internet attachment point to another.

The NEMO Mobile Router forms a bidirectional tunnel with the MIPv6
home agent, and apparently (in the NEMO basic case, at least) all
traffic between the MR and correspondents must flow through the
HA in both directions. This is where the IRON model offers a
significant difference.

For IRON, the IRON client forms a bidirectional tunnel with a nearby
IRON server. If the client moves far from its current server, it simply
forms a bidirectional tunnel with a new IRON server and drops the
bidirectional tunnel with the old server. The IRON overlay network
dynamically tracks the client-to-server bindings and will update
the bindings so that connectivity is preserved across the handover.

Furthermore, the bidirectional tunnel is used for all traffic coming
from correspondent nodes destined to nodes in the IRON client's
mobile network. In the outbound direction, however, the IRON
client can form unidirectional tunnels with the IRON server that
provides service to the final destination so that path stretch can
be greatly reduced. The unidirectional tunnels are established
based on route optimization signalling messages informing the
IRON client of a more direct path toward the correspondent.

Finally, the underlying links over which the IRON tunnels ride
can fluctuate (come up, go down, change addresses, etc.) without
the fluctuations disrupting the tunnels in any way. As long as
there is at least one working underlying link, the tunnels will
survive.

I hope this helps clarify,

Thanks - Fred
[email-masked]<mailto:[email-masked]>

________________________________
From: Scott Brim [mailto:[email-masked]]
Sent: Friday, June 17, 2011 10:15 AM
To: Bob Hinden
Cc: Templin, Fred L; t.petch; Internet Area
Subject: Re: [Int-area] IRON issue discussion

On Wed, Jun 15, 2011 at 03:51, Bob Hinden <[email-masked]<mailto:[email-masked]>> wrote:
> Fred,
>
> This sounds a lot like Mobile IPv6 with the extension that the client can change home agents if the client get's too far away from where the the home agent is.  I am sure the details are different, but the functionality sounds similar.

Good point.