Subject: Re: [MOBILE-IP] simultaneous mobility bindings: 'tunnels a copy t o each'

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Tue, 15 Feb 2000 11:58:20 +0100

Hi

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

I think that it depends on your wireless access technology as to
whether the MN will receive multiple copies of packets over the air
interface. The MN can solve the problem by making sure it is only
attached to one L2 access point at a time (or is constrained to doing
so) for reception/transmission. Switching between L2 technologies or
access points can then be done according to L2 measurements.
I assume that you have one FA per access point as you stated.
Superfluous packets are then discarded since they cannot be delivered.
Some bandwidth is wasted on the wired part due to the multiple flows,
but that is cheap compared to the air interface.

On the other hand, distributing load on several simultaneous COAs
cannot be done. This is quite a complex issue since the intelligence
to distribute the load according to L2 characteristics has to be
in the HA/GFA (simultaneous binding agent) which typically has little
knowledge of this.

Regards,
Karim

---

From: Gerald Maguire <[email-masked]>
Date: Tue, 15 Feb 2000 12:48:03 +0100

But there are air interfaces that can listen on multiple channels at
one time (for example many CDMA receivers only need another correlator
to listen on a second spreading code). Thus the cost for listening to
multiple access points need not be high.

Chip

---

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

Reading draft-calhoun-mobileip-proactive-fa-00.txt, a couple of
questions
came up:

* why do you choose the FA to assist the hand-off?
Couldn't this be any node in the network?
Wouldn't it be nicer to separate functionalities?
(Leaving it optional to implement both in one piece of software)

* why does the oFA need to communicate with the nFA?
Could the oFA send a direct message to the MN, asking it
to register with the nFA?
Wouldn't this make more sense, since the MN might not be
able to listen to multiple FAs?

* registering with a new FA could mean to access the network
via a new physical link. This might be useful even in the
absence of FAs. Would you suggest to have a separate hand-off
mechanism for physical connections?

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: "[email-masked]" <[email-masked]>
Date: Tue, 15 Feb 2000 08:44:29 -0800

Karl, see my responses below.

PatC

> * why do you choose the FA to assist the hand-off?
In today's cellular network, the BSC/BTS is responsbile for such hand-offs (at
least in the CDMA network, I'm not sure about GSM). As some of us in 3GPP2
(and WMIF) are trying to come up with an All-IP cellular network
infrastructure, we are looking at how we can expand existing IETF protocols to
suit our requirements.

The BSC/BTS currently measures the signal strength in order to determine the
mobile's movements. This is done by the link layer, and it seemed to make
sense to write an interface of some form between this link layer and the
Mobile IP FA stack. The idea here is to take as much as we can from the
cellular networks and put as much as we can in IP, and make the cellular
networks look like nothing more than a link layer (albeit a rather complex
link layer).

> Couldn't this be any node in the network?
Such as? I suppose that we could introduce a new IP device in the network, but
I fail to see the reason for doing so (except to sell more boxes :). I suppose
the BTS itself, which is a rather dumb device, could send these messages.

> (Leaving it optional to implement both in one piece of software)

Well, I'm not so sure. I think that I would like to have the FA be responsible
for this function. Further, as move along this thread, we may decide that
simultaneous bindings at the FA (in a hierarchical network) would provide
another cellular requirement, which is that a mobile must receive multiple
identical data streams from multiple BTS. The FA could be responsible for
this, but it would need to know where the mobile is, and where it is going.

> * why does the oFA need to communicate with the nFA?
Because we know that oFA and nFA can communicate.

> to register with the nFA?
It isn't clear that oFA can still communicate with the Mobile Node. All it
knows is that the signal is sufficiently degraded, and if the mobile is moving
at fast enough speeds, it is possible for the oFA NOT be to able to send the
said message to the MN.

> able to listen to multiple FAs?
Well, in today's cellular networks, the Mobile Node receives up to 6 data
streams from different BTS' (again, in a CDMA network). It also isn't clear
that the Mobile can still receive packets from oFA (due to signal strength).

Another alternative is to have both oFA and nFA send the indication to the
mobile.

> mechanism for physical connections?
I *have* been thinking about something along these lines. In today's CDMA
network (again, I need some help as far as GSM is concerned), the MN can
receive up the data stream from up to 6 BTS. If a new simultaneous
binding-like function was added to Mobile IP, it would allow the FA to send
multiple instances of packets to the relevant BTS, and provide BSC-like
functionality.

Note, that the last paragraph is still an very rough idea that I have, and
requires lots of engineering.

PatC

---

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

>access points can then be done according to L2 measurements.

I wasn't sufficiently clear...

We _want_ to use more than one link _truly concurrently_.
For instance, maybe I have 2 links of equal bandwidth:
I want half my packets to traverse one, and the other half
the other.  This is because my links are _SLOW_! Some of
them are only 2400 bps.  One might argue that this is a
very special case: most folks have faster links.  True,
most folks have faster links... but they also want to
move _more data_, so on a relative basis, the situation
remains the same: load balancing is common is backbone
networks, which have incredibly high speed links.

>in the HA/GFA (simultaneous binding agent) which typically has little

It 'cannot be done' using only standard Mobile-IP HA functionality;
however, once we have Mobile-IP in place, with multiple simultaneous
bindings, our routing and forwarding processes can take advantage of
those concurrent paths, and provide the additional intelligence not
present in the HA itself.  I agree it is 'quite a complex issue':
we are talking about QoS routing, which is so hard most folks have
given up on it; and then compounding the problem by not merely
selecting the one 'best' route, but rather forwarding packets
over multiple concurrent paths.

------------------------------------------------------------------------
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: Jim Willkie <[email-masked]>
Date: Tue, 15 Feb 2000 09:56:39 -0800

Folks:
Excuse me for jumping into the middle of a topic, but a couple things below
need clarity...

>networks look like nothing more than a link layer (albeit a rather complex

Correction: signal strength (and most other BSC/BTS functionality
mentioned) is in the physical layer, not the link layer.

>Another alternative is to have both oFA and nFA send the indication to the

It is a misrepresenation to state that CDMA mobiles can receive multiple
streams. To state more correctly a CDMA mobile can receive its signal from
multiple BTS's, which is a great aid to dealing with multipath issues. This
unique benefit of CDMA is a physical layer thing, and does nothing to
provide multiple link layer streams to a single mobile.

>requires lots of engineering.

Ditto from above..... I don't profess to be on top of the bigger issue of
this thread but I wanted to make sure the actual behavior of the CDMA air
interface is properly understood.

Thanks, Jim Willkie

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 15 Feb 2000 10:00:57 -0800

> >In today's cellular network, the BSC/BTS is responsbile for such hand-offs
> (at >least in the CDMA network, I'm not sure about GSM). As some of us in
> 3GPP2 >(and WMIF) are trying to come up with an All-IP cellular network
> >infrastructure, we are looking at how we can expand existing IETF protocols
> to >suit our requirements.
> >

Correct, that was what I meant to state (and failed).

PatC

---

From: Karl Jonas <[email-masked]>
Date: Wed, 16 Feb 2000 10:40:53 +0100

Pat et al, thanks for the replies.

Let me argue again for a separation of FA functionality and hand-off
support,
and for a 'direct' communication with the MN.

The discussion (in particular Claude's arguments) shows that there is
concern to move more functionality from the MN into the network.
Although I think that is is always good to OFFER support from the
network
(for whatever), this should be separated fro required functions and
optional
to implement/provide. A MN should not rely on it.

If hand-off-support would become part of FA functionality, it would go
away
with the FA in IPv4 CoCOA mode  and in IPv6. If it, on the other hand,
is
an independent service it could still be co-located / implemented with
the FA.

This would also make independent service provision simpler.
Operators might want to optimise network resource usage, thus offering
hand-off support in the access network.
I might want to optimise on cost, with hand-off support either on my
MN or my home network (HA?), or both.
Someone else might want to offer this as a third party service.

These are a few examples why network-assisted hand-off should not
necesarily be supported by the FA, but be independent.

This hand-off support agent (let me call it X) should use the most
appropriate
way to communicate with the MN, which is either via the current FA or
using
the current CoCOA.

Also, it should be considered that these messages could be interpreted
by the MN as
hints or as requests. An operator might want to be able to force
hand-over, while
my private cost-optimiser just wants to inform.

Maybe the messages do not allways need to be sent to the MN, but to the
old FA,
since the oFA could force a hand-over (is this part of MIP?).

comments?

karl