Subject: [nemo] can't make San Diego but here's some food for thought

From: "Stuart W. Card" <[email-masked]>
Date: Mon, 02 Aug 2004 12:40:47 -0400

At 04:50 PM 7/30/2004, <[email-masked]> wrote:
>...
>See you in San Diego...

Sadly, I will again be unable to join you.  However, I would like
to take this opportunity to remind you of some work we have done
and issues we have identified, described in long-ago postings to
the mailing list, in case any of this proves relevant during IETF60.

(1) We have a very NEMO-like solution for IPv4 under Linux.  It has
been extensively tested, both in the lab and in the field (multiple LANs
aboard aircraft, using Line Of Sight, Beyond LOS and SATCOM radios
to reach base stations). It uses MIPv4 extension type 42 to register
prefixes and supports multihoming via multiple simultaneous COAs.
It minimally violates the MIPv4 RFC by not merely sending redundant
packets to the COAs, but rather load balancing across them with
QoS reservations. That approach to forwarding is decoupled from
the basic network mobility support mechanism, so the registration
is 100% compliant with the RFCs as far as we know.  It was designed
by Dr. Steve Zabele of AlphaTech, implemented by his staff, and
integrated by a Northrop Grumman led team into a DoD system.

(2) We have not yet migrated to IPv6 and NEMO, partly
because the lack of FAs in MIPv6 forces encapsulation
over the links to the MRs.  While this overhead is minor
over wireline and many wireless media, it is significant
over our wireless WAN links (long latency, low data rate,
high error rate, due to being narrowband and traversing
long ranges often including geostationary satellites).
We would like to migrate to IPv6 and NEMO to be in step
with the community.  Are there any ideas being considered
that could obviate the requirement for encapsulation over the
links to the MRs, at least in some special cases that might
need additional support not required by the basic support draft?

(3) For the reasons cited in (2) above, we are concerned with
the multiple encapsulation that may occur with nested NEMO
and/or RO.  We really don't care about RO in the wireline network,
as our bandwidths are so many orders of magnitude smaller, but
we do need to avoid any avoidable multiple trips or encapsulations
over the wireless links.  We believe this concern will be shared
by other developers of wireless WANs, as bandwidth is inherently
much more precious in the wireless WAN than the wireless LAN,
as the latter spectrum can be extensively re-used in different cells,
but the former cannot.

(4) Assume MN1 is served by MR1 and MN2 by MR2, and that
the former is the parent of the latter in a nested NEMO.  If MR2
then achieves another point of attachment to the fixed infrastructure,
but also retains its connectivity through MN1, MN2 is multi-homed,
but MN1 is not, per the the nomenclature and multihoming drafts.
This is because MNs are nominally precluded from offering transit.
However, the access link between MR1 and the infrastructure may
have very different QoS attributes from that directly between MR2
and the infrastructure: nodes in MN2 can choose their preference,
but nodes in MN1 cannot; in some scenarios, the restriction on
transit through MN2 will preclude some applications from running
on nodes in MN1, even though adequate capacity and QoS would
be available to them, were they only permitted to transit MN2.
Setting QoS aside, MN1 and MN2 may both offer bursty traffic,
with peak demand from each exceeding the capacity of its MR's
direct link to the backbones, but the peak aggregate demand
not exceeding their aggregated capacity; MN2 will be fine, but
MN1 will suffer needless congestion induced packet loss if it is
not permitted to transit MN2.  We realize that transit should not
be offered in general by MNs, for good and obvious reasons, but
believe cases of this sort should be supported.  Keep in mind that
the only reason MN2 was allowed to transit MN1, and not vice versa,
was the temporal order in which registrations occurred: MN2 first was
attached to MN1 and then later directly to the backbones; had MN2
initially been attached to a backbone, and MN1 attached to MN2,
the 'rules' as to who can transit whom would have been reversed.

If anyone would like to discuss these interactively, despite my
absence from the face-to-face meeting, send me an e-mail and
we can arrange to speak by phone.

We believe these concerns will be shared, not just by US DoD
developers, but by mobile wireless WAN developers in general,
so thanks for giving them some thought!

Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc.
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <[email-masked]> www.critical.com

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 3 Aug 2004 02:35:22 +0900

Hi Stuart,

On your scenario below, what would prevent a reversal for the second
mobile network MN2 (this doesn't stand for mobile node I suspect ...)
serving as the parent of MN1 ?  Also, we once spoke about "split
network", why not about "merged networks" ?

Thierry.