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 11:59:34 -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: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Aug 2004 15:05:57 +0200

Stuart W. Card wrote:
> 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).

"Multiple LAN's aboard aircraft", was it like "nesting" moving networks
each with its MR?  Or was it like several combined subnets with a unique
MR at the top-level?

> It uses MIPv4 extension type 42 to register prefixes and supports 
> multihoming via multiple simultaneous COAs.

A-ha!  So a new Registration Request message type number?  This should
be suggested to IETF and to IANA if interoperability is important.  And
then maybe 35 is sufficient, no need of 43 so high (34 Foreign-Home
Authentication is the last allocated, no?).

> (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.

This sounds reasonable at the first read.  You seem to assume keeping
FA's on the ground and thus save bandwidth between it and onboard MR.

However, when accepting a visiting moving network to board the flying
equipment, one should place an onboard FA too, no?  One can't have a
grounded FA to deal with an onboard MR behind another onboard MR.

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

Yes, ideas there are about eliminating the HA from the LFN-CN
communication path and without encapsulation.

In the specific scenario that you describe, a simpler Mobile IP
architecture could be engineered that eliminates that encapsulation, and
doesn't employ Route Optimization techniques (which does not exist in
MIP4 btw). In order to do that one should have more information about
the current architecture you're considering, because it seems to me it
is very much different than the architectures we commonly consider with
telecom networks, wireless access networks, etc.

For example, when you say LOS, beyond LOS and SATCOM, where do those
links point to?  Is it like all the distinctive ground stations
(corresponding to LOS, beyond LOS and SATCOM) are linked together by
some earth-grounded-high-speed-fiber?  Or is it that those ground
stations are communicating via the Internet?

If they're connected together by high-speed-something then it would make
little sense to have both FA's and HA's, but would make better sense to
only have one FHA callit, and then never encapsulate at all towards it.

This is just a possibility about how it could be made to eliminate
encapsulation over the wireless links, but depends on the architecture,
please provide details about it.

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

So MR2 has actually three interfaces, right?  The third interface was
kind of dangling before achieving another point of attachment.

> but MN1 is not, per the the nomenclature and multihoming drafts. This
>  is because MNs are nominally precluded from offering transit.

One should attach a certain interpretation to the statements about
moving networks being precluded to offer transit. In nested NEMO moving
networks, one network transits packets of the other ok. However, in OSPF
networks there are "transit" and "stub" networks and in this sense a
moving network is more like an OSPF stub network and precluded to be an
OSPF transit network.

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

Yes, this requirement looks to provide value and I think moving networks
as they are now (NEMO basic support is exclusively IPv6, and
non-interoperable v4 implementations exist) will not  accomodate the
above scenario.

We have identified another mobility configuration that is not supported
by NEMO Basic Support and is not multi-homing either (uses a mobile HA).

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 6 Aug 2004 09:01:10 +0900

Hi Alex,

See below.

> by NEMO Basic Support and is not multi-homing either (uses a mobile HA).

What do you mean by new configuration ?  The HA would be 1. in the
aircraft or 2 in the infrastructure ? If 1, this falls into the nested
case (offering service to LMNs). In both cases, we are talking about
multiple HAs, don't we ?

Thierry

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Aug 2004 10:23:43 +0200

Thierry Ernst wrote:
>>> (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,
[...]
>>>  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.
> 
>> We have identified another mobility configuration that is not 
>> supported by NEMO Basic Support and is not multi-homing either 
>> (uses a mobile HA).
> 
> What do you mean by new configuration ?

Our NEMO-unsupported configuration was the one presented at a previous
IETF - "cross-over tunnels" - and I think it's not multi-homed because
although there are multiple HA's (one in a moving network and one in the
infrastructure), each MR only has a unique egress interface in that
scenario.

The Card/Zabele/DoD demo is different than our non-working configuration
and fails to work for other reasons than ours (tunnels that would
"cross-over" do not help solve their problem, while it would solve ours).

The problem in the Card/Zabele/DoD demo is that LFN in MovingNetwork1
will not be able to change its default route towards MR2 when MR1 gets
disconnected and MR2 attaches its third interface to a new wireless
access system. MR2 does not send RA's on any of its egress interface so
LFN (which sits above MR2) can not configure a default route towards MR2.

I do not know whether it's a new RO mechanism or an existing RP (routing
protocol) and traffic shaping that could help solve both these issues,
or a combination of the two.

> The HA would be 1. in the aircraft or 2 in the infrastructure ? If 1,
>  this falls into the nested case (offering service to LMNs). In both 
> cases, we are talking about multiple HAs, don't we ?

Ah sorry, so it is agreed that when there are multiple HA's there's
actually "multi-homing" taking place? This would mean that most times
when there are nested networks there's actually "multi-homing"?

Alex