Subject: [MOBILE-IP] simultaneous mobility bindings: 'tunnels a copy to each'

From: Stuart Card <[email-masked]>
Date: Mon, 14 Feb 2000 13:57:31 -0500

I studied RFC 2002 a little more carefully and can now elaborate
a little more specifically...

--

4.2.3. Home Agent Considerations

   ... The home agent must examine the IP Destination Address of all
   arriving datagrams to see if it is equal to the home address of any
   of its mobile nodes registered away from home.  If so, the home agent
   tunnels the datagram to the mobile node's currently registered care-
   of address or addresses.  If the home agent supports the optional
   capability of multiple simultaneous mobility bindings, it tunnels a
   copy to each care-of address in the mobile node's mobility binding
   list...

--

We want to use simultaneous COAs, but we do _not_ want each FA
to deliver a copy of each datagram, because that would waste our
precious wireless bandwidth (defeating the purpose of our using
multiple COAs in the first place): in our case, FAs are routers
colocated with radio base stations, and we want to aggregate the
bandwidth of multiple wireless links to the MN.

The HA sections of the RFC appear to permit (and largely to support)
our desired behavior: if the HA tunnels a copy to each FA, but
_only one_ FA then delivers it via its wireless medium.  Unfortunately,
the FA sections seem to require of us that _all_ FAs deliver their
copies...

--

4.2.2. Foreign Agent Considerations

   Upon receipt of an encapsulated datagram sent to its advertised
   care-of address, a foreign agent MUST compare the inner destination
   address to those entries in its visitor list.  When the destination
   does not match the address of any mobile node currently in the
   visitor list, the foreign agent MUST NOT forward the datagram without
   modifications to the original IP header, because otherwise a routing
   loop is likely to result.  The datagram SHOULD be silently discarded.
   ICMP Destination Unreachable MUST NOT be sent when a foreign agent is
   unable to forward an incoming tunneled datagram.  Otherwise, the
   foreign agent forwards the decapsulated datagram to the mobile node...

--

The language used is that 'the foreign agent forwards'.  There is no
'MUST' here, so maybe we can drop the datagram at all but one FA?

This approach is inefficient, in the sense that redundant datagrams
traverse the wired networks between the HA and (N-1) of the FAs.
It is however efficient in use of the (more precious) wireless bandwidth.
Further, each FA, by receiving copies of all datagrams (even those it is
not destined to forward), has a complete picture of the traffic flow
to/from its registered MNs, potentially enabling it to make smarter
forwarding decisions.  Finally, this may introduce some opportunities
for fault-tolerance: critical traffic might actually be forwarded by more
than one of the FAs (all, or a subset) to fight wireless link quality
problems with redundancy; or datagrams might be buffered at all FAs,
so that NAKed (or unACKed) datagrams might be [re]transmitted by
FAs other than the one which originally forwarded (or should have
forwarded) them.

So, I have several questions:

(1) Should I interpret 4.2.2 as requiring that _each_ FA MUST
forward _all_ tunneled datagrams, or can I drop a datagram at
zero or more FAs, provided I ensure that _at least one_ FA
forwards that datagram?

(2) Do I seem to be violating any other rules of this (or any
other relevant) RFC?

(3) Any other comments on this scheme?

Thanks!

------------------------------------------------------------------------
Stuart W. Card, Chief Scientist & Vice-Pres., Critical Technologies Inc.
Suite 400 Technology Center, 4th Floor 1001 Broad Street, Utica NY 13501
315-793-0248   FAX -9710    <[email-masked]>   http://www.critical.com

---

From: Claude Castelluccia <[email-masked]>
Date: Tue, 15 Feb 2000 10:00:36 +0100

> a little more specifically...

Hello Stuart,

Current Mobile IP does not support such functionalities.
However we have presented in a Mobicom paper
(http://www.inrialpes.fr/planete/people/ccastel/mobicom98.ps.gz)
an architecture and some simple   Mobile IP  extensions that  allow  to use
simultaneously several  CoAs for different
flows... this should solve your problem...

regards,

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: Karl Jonas <[email-masked]>
Date: Tue, 15 Feb 2000 10:15:48 +0100

Stuart, Charlie, et al,

it seems that i was unprecise in my previous email, so let me try again:
Simutaneous bindings are possible according to the current MIP draft
BUT as Charlie Perkins noted in one of his emails, this might be dropped
in future drafts of MIP.
He wrote (Jan 26)
  "It is possible for a mobile node to enter simultaneous registrations
  and thus have more than one care-of address.  However, this feature
  has not, to my knowledge, been tested at any interoperability event.
  Thus, unless it is shown to be interoperable, there is the likelihood
  that the feature will be dropped from the standard as we pass from
  Proposed Standard to Draft Standard (possibly later this year)."

The intention of my mail was to keep simultaneous bindings as an option
in MIP, since i expect it to be useful for future implementations, and
-being optional- it does not harm anybody else.

So, it is good to hear that Stuart needs and uses the feature.

karl

--
Karl Jonas, NEC C&C Research Labs
EMail: [email-masked]
Tel.:  +49.(0)6221.905 11 21
Fax:   +49.(0)6221.905 11 55
http://www.ccrle.nec.de/heidelberg/index.html

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Tue, 15 Feb 2000 18:56:52 +0900

Hello, Karl,

 I have a plan to check the interoperability about simultaneous binding
 at the coming Sun's Connectathon.  I hope this will help you a bit.
 But, I cannot clearly image there are any applications that really want
 this capability.  So, if you or someone else point out more potential
 applications that need this capability, it will be appreciated more.

Cheers.
-Yoshi

---

From: Stuart Card <[email-masked]>
Date: Tue, 15 Feb 2000 12:05:52 -0500

> applications that need this capability, it will be appreciated more.

I'm confused: I thought I _did_ identify 2 cases where it is needed...

(1) When a wireless mobile is moving through regions of marginal
wireless connectivity, it will acquire and lose link repeatedly,
potentially at a very rapid rate; it would be infeasible to change
Mobile-IP registrations at this rate.  This is _not_ just a
'micromobility' problem that can be solved below the IP layer:
the different base stations with which the mobile can communicate
may have network gateways in different parts of the IP address space,
may be operated by different providers, and indeed may involve
entirely different link layer technologies (see my previous example
involving VHF, HF and UHF radio links).  This is also _not_ just
a military problem: a commercial mobile might have both Iridium
and cellular capabilities; it may want to maintain continuous
reachability as it wanders in and out of cellular link, but
not pay the high price to use Iridium continuously; it would
be wasteful to have to re-register with Iridium every time
it momentarily lost cellular link, and vice versa.

(2) A less common situation is that where a wireless mobile
is capable of using, _truly concurrently_, multiple wireless
links, and wants to aggregate their bandwidths.  The Air Force
has this need: there are typically multiple narrowband radios
on an aircraft; no one link provides anywhere near adequate
bandwidth; but the aggregate of all its wireless links may
offer something on the order of a low speed wireline link.

With regard to this not having been tested for interoperability,
I cannot _yet_ help there; we have not yet fully implemented our
test & demonstration system... but we are working on it!