Subject: Re: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ?

From: Erik Nordmark <[email-masked]>
Date: Thu, 1 Aug 2002 19:25:11 +0200 (CEST)

> This question is for the WG to decide. What do others
> think ? Should we make PrRtAdv an optional message ?
> Interop implications ?

I'm having a hard time understanding the question without a specification
that I can read which goes into detail of what messages are sent and received
in which cases.

If there are link layers where this message isn't useful at all, then it
isn't useful for those link layers. As long as all the MNs and ARs in fact
know that they are operating over such a link layer (which is an implementation
issue; my IP stack doesn't know whether it is operating over Ethernet or
802.11 for instance), then it might be reasonable to state that the message is
optional *when running over that link layer*.

But I think the high-order bit is that such a message might not provide any
utility on particular link layers.

My 2 cents,
  Erik

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 01 Aug 2002 13:00:18 -0700

Hello Erik,

> that I can read which goes into detail of what messages are sent and received

The draft has so far addressed a base protocol that should work on all
link types. Here is the URL.
http://people.nokia.net/~rajeev/draft-ietf-mobileip-fast-mip6-05.txt

The debate is now on whether we could optimize the protocol for certain
link types.

> optional *when running over that link layer*.

Ok. Although, I do not know of *existing* link layers where
the functionality is provided by the link layer with the qualifier
that serial links need consideration.

> utility on particular link layers.

OK. It would be good enlist those link layers that offer the
same functionality today or are required to provide in
future.

Thanks,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Thu, 1 Aug 2002 15:38:35 -0700

> that serial links need consideration.

See my message sent out yesterday on wCDMA. The message is unnecessary there
because it duplicates information exchanged at the link layer. I believe IS-2000
is a similar situation, but I have not checked.

> same functionality today or are required to provide in

 Do you mean compile a list of such link layers?

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 01 Aug 2002 17:17:12 -0700

> is a similar situation, but I have not checked.

I read your message, but did not understand how the MN
gets the L2 address and IP address of the target access router, which
is what it needs to send packets. It seemed like what the MN is
getting is the BSSID of the target base station. Am I missing
something ?

>  Do you mean compile a list of such link layers?

Yes, so that we know if majority of link layers already
supply the information needed.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 2 Aug 2002 08:38:30 -0700

> getting is the BSSID of the target base station. Am I missing

That requires the Seamoby CARD protocol, or a static table mapping the BS id to
the target router id. The same procedure is required by any radio protocol in
which the base station is not integrated with the access router, and it would
even be required if PrRtAdv were sent, in order that the old AR could get the
new AR's IP address for the HI/HaCK.

> supply the information needed.

Here is a start at a list:

    wCDMA - PrRtAdv not necessary, BS id of target BS is supplied by L2
signaling, mapped to router L2/IP address
                      via Seamoby CARD protocol or a static table on BS/old AR.
    IS-2000 - Same as wCDMA (but needs confirmation)
    flash OFDM - Fast handover not necessary. Wireless layer 2 is capable of
true make-before-break, so the mobile
                          can conduct RS/RA and binding updates on the forward
channel to the new BS while getting its traffic
                          on the backward channel.
    802.11a,b,g-  PrRtAdv and SolPrRtAdv not possible in a portable way, since
802.11 standard provides no prehandover
                          signaling on the mobile or access point. Nonportable,
proprietary extensions to some product drivers
                          to provide signal strength may allow use, but depends
on product firmware.
    Bluetooth - The standard Bluetooth IP profile requires IP to run over PPP,
so fast handover is probably not an option.
                      (Aside: is somebody looking at how Mobile IP would work
with PPP for Bluetooth?)
    Hyperlan - ??? (is Hyperlan still important?)
    GSM - ??? ( is it important? GPRS hides the radio protocol fairly deeply?)

If anyone is more familiar with these radio protocols, or others that I have
missed, please reply with corrections.

                jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 02 Aug 2002 10:08:10 -0700

> new AR's IP address for the HI/HaCK.

The AR needs a mapping, yes. However, how does the MN get the
mapping information ? Who provides it ? A link layer message ? If
yes, is such thing there in the relevant spec ?

> signaling, mapped to router L2/IP address via Seamoby CARD protocol or a static
> table on BS/old AR.

Rajeev: Same comment as above: which message provides the information
to the MN ?

>     IS-2000 - Same as wCDMA (but needs confirmation)

Ok.

> channel to the new BS while getting its traffic

Ok.

>                           to provide signal strength may allow use, but depends

So, how does a WLAN card decide to associate with a new AP ? There is
a "scan" message that allows the MS to figure out what APs are within
reach. After that, there has to be some guideline as to when the MS
changes its AP, based on, e.g., received signal strength.
The result of scan is the input to PrRtSol. We don't have to standardize
how the scanning works etc, do we ? It suffices to provide a message
that can be called when the L2 decides to look for other AP(s). Note
that there is analogous support in Linux to send a RS upon detecting
a new link.

If the MS moves before PrRtSol could be attempted, then the HI/HAck
happens after the association with the new AP.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 2 Aug 2002 11:45:31 -0700

> yes, is such thing there in the relevant spec ?

In the case of radio protocols such as wCDMA, the MN doesn't need this
information, since the MN and the old BS exchange the identity of the new BS at
the link layer. The old BS sends the Layer 2 identifier of the new BS to the AR
by a Layer 2 specific means, or using something like Alper's proposed ICMP
message, if the BS and AR are not integrated. If they are integrated, then the
AR will have this information. The AR can use either the CARD protocol or a
static table to do the lookup, exchange HI/HaCK. The MN's link gets switched at
Layer 2, the AR tunnels until the MN completes binding update on the new AR.

For link layers where there is no exchange of new BS identity over the air at
Layer 2 prior to handover but the MN knows, the MN can use Seamoby CARD to do
the mapping, and SolPrRtAdv/PrRtAdv would be required.

For link layers with no prehandover signaling between the BS and MN such as
802.11, the MN can use Seamoby CARD after handover and do the mapping, but it is
yet unclear how the tunnel would be initiated in this case. Alternatively, the
BS can do the mapping if the old BS id is known, and use target triggered
handover, which is also undefined in draft 5. The fast handover signaling for
this case is the most underspecified in draft 5, IMHO.

In any case, how the BS does this mapping is out of scope for the fast handover
spec, though we do need to have it nailed down for a complete solution.

> Rajeev: Same comment as above: which message provides the information

See above.

> So, how does a WLAN card decide to associate with a new AP ?

Proprietary. It is not specified in the 802.11 standard. As a practical matter,
FER and signal strength are both possibilites. In existing products, there are a
wide variety of algorithms, and they are likely to get more varied as vendors
start competing on handover performance.

> There is

It could also be FER. Also, some current products do make a decision based on
other measures not associated with the quality of the link. 802.11 is not like
cellular, there is no standard signal strength specified nor a standard FER, nor
even a requirement that these should be used to make the handover decision. The
only standardized signaling is the Reassociation.request() and
Reassociation.reply() when the card has selected which access point it will
associate with.

> The result of scan is the input to PrRtSol.

Our experience is that the results of a scan are not typically available to the
driver when a handover is necessary, it is conducted by the firmware, and is
followed by the Reassociation.request()/reply() without any driver intervention.
On some cards, a scan can be forced, signal strength measured, and handover
forced by the driver, but this is by no means a standard. Also,during the
exchange of PrRtSol/PrRtAdv (which will take some amount of time) after the scan
is forced, the firmware could decide to perform handover to a completely
different access point. Nothing constrains the firmware to continue being
associated with the current access point until the PrRtSol/PrRtAdv completes.
Finally, while a scan is being conducted, the card is basically offline for any
traffic. This means that the scan prior to the PrRtSol/PrRtAdv would shut down
traffic to the card, during which time it would have to be buffered (or dropped)
if the scan takes too long.

We've measured typical scan times of about 100 ms on a cell with a single MN.
This time increases dramatically if there is more than one MN in the cell,
because 802.11 has no QoS on signaling traffic. The scan is scheduled on the
link with the same priority as MN traffic. With 3 MNs doing continuous traffic,
the scan time can be upwards of 200 ms.

> We don't have to standardize
> how the scanning works etc, do we ?

We can't. It is up to IEEE 802.11 to do that. They have been extremely reluctant
to do any standardization of prehandover conditions. I've been advised to not
pursue the issue with them.

> It suffices to provide a message

I don't follow. If the Layer 2 protocol doesn't provide this, how can IP help?
We can't control what happens at Layer 2 unless the hooks are there.

> happens after the association with the new AP.

Sure, that's target triggered handover. There is something in draft 04 to do
this, and also in the FMIPv4 draft.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 02 Aug 2002 15:37:20 -0700

> Layer 2, the AR tunnels until the MN completes binding update on the new AR.

I guess I was not clear.. The question is not how the old AR can determine the
IP address of the new AR, which itself is a separate issue, but how can the MN send

packets to the new router. If the MN knows the L2 address of the new BS (not the
new AR), can it send packets to the router ? Two options:

a) assume that the new AP is capable of routing/switching packets to the new AR
based on L2 headers
b) assume that the new AP is only a bridge between wireless and wireline portions
of
     the network.

In UMTS (scenario a) ), the MN sends packets to the AP (actually to Node B and then
to RNC).
And, then there is GTP tunneling. However, in UMTS, the MN does not change the
AR (i.e., GGSN). As I understand, inter-GGSN handovers are not specified. Inside
the GGSN, handover support is done by GTP and is well-specified. So, I am not
sure how the scenario you describe above would be applicable specifically to WCDMA
networks..
Also, PrRtAdv is as inapplicable as any ND messages defined today.

If you consider scenario b), which is applicable to WLAN e.g., the MN needs to know

the L2 address of the new AR to send packets.

> this case is the most underspecified in draft 5, IMHO.

Regarding target-triggered tunnel establishment: how does the new AR know
the previous AR, and the previous IP address of the MN ? How does the new AP
figure both of these through Reassociate ?

Regarding tunnel establishment after association: the MN sends FBU which
triggers HI/HAck and hence the tunnel establishment. This may be need to
be specified separately, but is not undefined.

> start competing on handover performance.

This is good enough. We provide a message that implementations can use
to obtain the L2 and IP addresses.

> Reassociation.reply() when the card has selected which access point it will

This is ok. What we need is a message that the implementations can use
independent of what criterion they use to undergo handover.

> the scan time can be upwards of 200 ms.

All of the above is ok. If the MN has time to do PrRtSol/PrRtAdv, which BTW
takes few milliseconds, it will benefit. Otherwise, the protocol will operate from
the
new link (i.e., FBU sent from new link). So, I don't understand..

> We can't control what happens at Layer 2 unless the hooks are there.

The L2 protocol allows scanning and each card can make a decision
to undergo handover based on its own criterion. Then, the IP message
can be sent.

> this, and also in the FMIPv4 draft.

v05 also allows the tunnel establishment through FBU. I will put this under
a separate section for tunnel establishment subsequent to new link
establishment and more content.

-Rajeev

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 3 Aug 2002 07:53:40 +0859 ()

Rajeev

> > the scan time can be upwards of 200 ms.

I'm afraid scan time to scan all the possible frequency channels is
more than a second.

> new link (i.e., FBU sent from new link). So, I don't understand..

It will take several seconds to find the new link.

When link latency is a lot larger than mobile IP latency, which is
the case with WLAN, minimization of mobile IP latency is meaningless.

						Masataka Ohta

---

From: "James Kempf" <[email-masked]>
Date: Fri, 2 Aug 2002 17:09:10 -0700

> Also, PrRtAdv is as inapplicable as any ND messages defined today.

Even if you don't consider GPRS, the base station could take care of making sure
the packets get to the new router, since the router would likely be at the
segmentation and reassembly point for the radio frames. So I don't think it's an
issue in cellular protocols.

> the L2 address of the new AR to send packets.

Three possibilities:

1) The MN runs Seamoby CARD protocol, maps the new AP address into the new AR
address.

2) MN sends the packet to the new AP L2 address and the new AP forwards to the
new AR. In this case, the AP isn't working as a transparent bridge anymore.

3) The tunnel doesn't run between the new AR and old AR, it runs between the new
AP and the old AP. The new AP and old AP exchange the target triggered signaling
when the new AP gets the Reassociation.request().

Note that 3) isn't quite as unlikely as it may seem, since the new AP must
already use IAPP back to the old AP to request the old AP to clean up its
resources for the mobile.

1) is out of scope for the fast handover draft, 2) and 3) would require some AP
work, and therefore is out of scope for the generic fast handover draft, but
maybe in for the 802.11 specific fast handover draft.

> figure both of these through Reassociate ?

New AP sends MN L2 address and old AP address to new AR through proposed ICMP
protocol, uses Seamoby CARD to find IP address of old AR for target triggered
handover signaling. The only issue is, unlike MIPv4, that the old AR doesn't
necessarily know the care of address for the MN, unless the AR has locked down
the neighbor cache and still has it around.

I think in our implementation we lock down the neighbor cache and send back the
MN's old CoA in the target triggered handover reply signaling, and flush the
cache when the tunnel gets torn down.

Alternatively, if the AP is handling the tunnel, it does the target triggered
handover back to the old AP in conjunction with the IAPP signaling.

> be specified separately, but is not undefined.

I'm unclear why FBU is being used here, but I think we should discuss that in a
separate thread.

> to obtain the L2 and IP addresses.

Can you explain what you mean by a message? The handover decision making is
happening internally to the firmware on the interface card. There is network
traffic involved, but it is strictly determined by the 802.11 scanning protocol.

> independent of what criterion they use to undergo handover.

Same question as above?

> takes few milliseconds, it will benefit.

Maybe I wasn't clear here. The issue is that even in *that few milliseconds*,
the firmware may decide to switch to another AP than the one that was selected
by the driver and sent in the PrRtSol/PrRtAv. Can you explain how the Mobile IP
stack can benefit if it runs some nonzero probability of ending up on a
different access point?

> Otherwise, the protocol will operate from
> the

The current definition of how this works in draft 05 has that defined as an
error case. In 802.11, unless the standard IETF Mobile IP fast handover
specification for 802.11 is defined such that it depends on proprietary
extensions to 802.11, the case of the mobile moving without any prehandover
notification will be the norm.

And, again, I'm unclear why FBU is being used in this case, but we should take
that up in a separate thread.

> to undergo handover based on its own criterion. Then, the IP message

As I mentioned above, the firmware has its own ideas. The driver may decide to
switch to access point A, but if the firmware switches to access point B, the IP
signaling won't reflect reality.

> establishment and more content.

OK.

            jak