Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6

From: James Kempf <[email-masked]>
Date: Thu, 7 Jun 2001 10:42:20 -0700 (PDT)

Hi Charlie,

>> As I said, "some portion". I agree that there may be need for buffering
>> on newAR, but currently the draft does not mention any handoff smoothing
>> technique. I don't believe it should mention any, unless it clarifies
>> that bicasting can be used too.
>
>But I believe that bicasting is problematic in many ways that do not
>apply to proper buffering techniques.  For instance, there is the
>problem of how to handle multple levels of wireless IP routers.  We
>should be very careful to avoid standardizing techniques for general
>protocols that are only applicable to specific scenarios.  Then there
>are the control issues (when to start? when to stop?), TCP issues,
>and at least two or three others that I can't remember right now.
>
>Buffering, on the other hand, can be made to be deterministic and
>precise, as well as delay-bounded and time-limited.
>

I'd rather not get into a point by point discussion on bicasting
v.s. buffering. 

Actually, I think a combination of bicasting and buffering may be 
the best solution, together with an L2 trigger that tells the AR
when the L2 handover has started. The trick is to keep the buffering
restricted to the time in which the L2 link to the mobile
is well and truely gone. Otherwise, you run the risk of introducing
artifacts. Buffering at L2 (such as 802.11 does for dormant mode mobiles) is 
probably a better solution in the end.

>I am not wholly against bicasting, because I think it can be made
>into a useful addition to the set of smooth handover tools.  However,
>it needs to have a lot of work I think before it can be considered
>as part of network-layer standards.  The considerations seem to
>be somewhat different at the physical layer.
>

IMHO, this draft currently deals exclusively with latency reduction. There is
nothing in it currently about handoff smoothing, in contrast with
the v4 draft where both were put into the same draft. If you
want to discuss handoff smoothing, then I think all alternatives
should be discussed. Otherwise, I think that a reference should
be put into the existing draft to a new draft that discusses handoff smoothing.

		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 8 Jun 2001 11:19:45 +0200

> protocols that are only applicable to specific scenarios.  
> 
	=> I believe we need to be specific about the application 
	that is being considered here. If the aim is to minimise the 
	perceived interruption of services during a handover then 
	I clearly support Jim's suggestion. For real time traffic 
	I haven't seen _any_ proof that buffering is a good 
	idea. Please correct me here if you can show the opposite.

	As far as wireless routers are concerned, I believe your 
	assumption here was that packets will be duplicated
	first by ARs and then by the wireless routers. Some 
	comments on your assumptions:

	- You do _not_ receive every packet twice when you're
	bicasting and I can't see how that would be possible 
	in a "break before make" scenario. Clearly you wouldn't
	use it as a smoothing technique if you can recive traffic 
	simultaneously from two different routers. 
	 
	- A wireless router does not have to bicast if it sees 
	that as a danger. The entire draft hasn't considered 
	wireless (I guess you mean mobile ) routers anyway.  
	I don't think we've considered mobile routers scenarios 
	at all, so depending on the solutions for that scenario
	we can discuss the impacts of buffering / bicasting.

> Then there
> are the control issues (when to start? when to stop?),
> 
	=> The BU has a lifetime field. There is no difference
	here. The same issue exists for every BU. If we follow 
	the MIPv6 spec, the lifetime value is effectively 
	negotiated between the MN and the HA/AR/MAP. 
	The receiver of the BU will send back a lower value 
	if needed. The same applies whether bicasting is used 
	or not. Different values can be used for bicasting. 

>  TCP issues,
	=> see http://search.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-alg-00.txt
	I beleive this will address your concerns.

	Regards,
	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 8 Jun 2001 11:25:05 +0200

> probably a better solution in the end.
	=> This would be the best way of handling the smoothing
	of the handover. I fully agree with that.

> be put into the existing draft to a new draft that discusses handoff smoothing.
	=> Agreed again. This has been my point all along. The v4 draft
	covers the entire space and I don't understand why we can't do 
	the same thing for v6. I don't see any fundamental differences
	that would stop us from using the smoothing techniques
	in v4 or ping pong avoidance. 

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 8 Jun 2001 11:30:31 +0200

Hi Behcet, 

> >  My solution would
> > be to have a new draft, dealing with smooth handovers.
> >
> > Regards,
> > Charlie P.
> 
> I second this. But at the same time there is the question of why in the
> first place this was not included in the fast handover draft for
> mipv6? The answer is (my guess) there was no agreement on which regional
> registration protocol to use in the DT. Maybe now there
> is an agreement. 
> 
	=> This was not related to the Fast handoffs draft and we never
	discussed it in the DT. The idea was that the draft will coexist,
	but, not depend on, any of the LMM techniques. 

> This leads me to suggest that DT could extend its life
> a bit longer to come up with a single draft for fast and smooth
> handover.
> What do you think?
> 
	=> Well, the draft already had the smoothing techniques before
	and they were removed in the last minute. So it would be 
	really simple to reintroduce them. Having them in another
	draft doesn't make sense to me. We have one draft for 
	low latency handovers for v4 and if you implement it you 
	will get a complete solution, i don't see why we should 
	distribute the Fast Handoffs draft for v6 over several drafts. 

	Regards,
	Hesham

---

From: James Kempf <[email-masked]>
Date: Fri, 8 Jun 2001 11:28:40 -0700 (PDT)

>> >> JMC :
>> >> What happens if  ESP is used ? Alt-CoA will be encrypted and you couldn't 
do
>> filtering ...
>> >
>> >what filtering? the source address of the F-BU is the oldCoA
>> >and it is still attached to oldAR. so ingress filtering is fine.
>> >
>> 
>> This is only if everything goes as planned. It is also possible that
>> the F-BU could get sent after the L2 handover. And there are
>> lots of possibilities for things to go wrong.
>> 
>
>thats right. but we were talking about sending F-BU when still
>attached to the oldAR.
>

Might not get there. Remember, we're in a handover situation, so
the radio L2 may not be the best.

Also, even if MN sends it when thinks its attached to oldAR, it
might actually be  in transit or already arrived at newAR. The draft says 
nothing about how MN knows whether or not its attached to oldAR, nor about
the timing of L3 v.s. L2 handover.

>at the newAR there is a problem. the MN still uses the oldCoA 
>as the source address (because it cannot start using its 
>newCoA), but the newAR knows about oldCoA (it came in the HI 
>message from the oldAR). the newAR also has the link layer 
>address of the MN (this also from the HI message). it can be 
>made to work.
>

Right, if newAR does a reverse tunnel back to oldAR. The draft
doesn't talk about this, though. In subsequent email, Alper made
clear that was intended, but the draft needs revision.

But your point about newAR knowing oldCoA is made.

			jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 8 Jun 2001 13:55:48 -0500

Thanks Vijay,

Yes, my question was what you stated below.
Also could you please let me know where U flag is described?

Madjid

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]]
Sent: Wednesday, June 06, 2001 3:06 PM
To: [email-masked]
Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6

hi Alper,

> We have a 'U' Buffer Flag in HA message. And I think this makes it an optional
> feature. oldAR MAY turn this flag on. Do you think we should spell this out in
> the draft?

it is slightly different. by setting the 'U' flag, the oldAR basically
tells the newAR, that i have been buffering packets for this particular
MN. you should also do it.

and in the scenario, Madjid was talking about, the newAR is receiving
packets forwarded by the oldAR to the MN. but the MN hasnt shown up
yet. here it MUST buffer packets, whether the 'U' flag in the HI was 
set or not. if it doesnt buffer, it has to drop the packets till the 
MN shows up.

vijay

> 
> >
> >
> > 3- This question was asked on the list, I am not sure if I saw a convincing
> > answer other than comparing F-BU with BU.
> > The MN cannot use its newCoA as source address until it has received
> > F-Back from oldAR. Then how does it use newCoA as source address in F-BU?
> > Isn't this a chicken and egg problem? What am I missing?
> > Also what about ingress filtering issue at oldAR?
> >
> 
> MN doesn't have to use newCoA as the source address of F-BU. It can use oldCoA
> as the source address, and include a alternate CoA suboption. (I'm not sure if
> this is already stated in the draft. If not, we should add this.)
> 
> alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 8 Jun 2001 12:01:27 -0700 (PDT)

> 	of the handover. I fully agree with that.

If the L2 trigger mentioned above is the capability on the AR to say "MN has 
detached" or "MN has attached", then I don't see why we would also need 
bi-casting. This L2 feature itself is sufficient to direct the traffic either 
towards the current link on oldAR (MN is still attached), or towards the newAR 
(as soon as MN detaches). 

I don't think we need bi-casting if we have this L2 feature.

alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 8 Jun 2001 12:03:38 -0700 (PDT)

> Hi Vijay and Alper,
> 
> Vijay Devarapalli a écrit :
> 
> > answer for question 3.
> >
> > it will work if the following happens.
> 
> JMC :
> I don't think so.
> 
> >
> >
> > when the MN sends a F-BU when at the oldAR, the source address
> > of the packet is oldCoA. the newCoA is included in the alt-CoA
> > sub-option.
> 
> JMC :
> What happens if  ESP is used ? Alt-CoA will be encrypted and you couldn't do 
filtering ...

The recepient of this BU, oldAR, would know how to decrypt this packet, and 
retrieve the alt-CoA.

alper

> JMC.
> --
> France Telecom R&D - DTL/SSR
> Jean-Michel COMBES, Internet/Intranet Security
> E-Mail : [email-masked]
> Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
> PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214
> 

alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 8 Jun 2001 12:07:53 -0700 (PDT)

> 
> I agree. It is also not clear on "mobile has not arrived". Has the mobile been
> authenticated by the new AR? If not, how the new AR can receive packets for
> un-authenticated mobile. We need to check security issues here.

F-BU authenticates MN to oldAR.
HI authenticates oldAR to newAR.

If you are asking "how can newAR trust MN and release the buffers", that's 
outside the scope of this draft. Even without buffering, some other node on the 
same link can steal your traffic by overwriting neighbor cache of the AR. 

alper

> 
> Barani.
> 
> 
> 
> 
> James Kempf <[email-masked]> on 06/07/2001 09:41:22 AM
> 
> Please respond to [email-masked]
> 
> Sent by:  James Kempf <[email-masked]>
> 
> 
> cc:    (Barani Subbiah/HQ/3Com)
> >Can you add the following text to the draft then?
> >
> >    When the newAR is receiving packets forwarded by the
> >    oldAR for the MN, and the MN hasnt shown up yet, the
> >    newAR SHOULD buffer packets. If the newAR does not
> >    buffer packets, it would the packets meant for the MN.
> >
> 
> I don't think this text should be added.
> 
> It is entirely unclear at this point whether buffering will work without 
causing
> user-perceivable artifacts in real time streams. In fact, I know of
> at least one experiment with buffering (in IPv4) that showed it cannot be 
done.
> This experiment was not definitive, of course, but I think it is
> not wise to write buffering into the standard until more is known
> about whether it will work or not.
> 
> There are other alternatives to handoff smoothing, for example bicasting,
> that could handle some portion of the handoff smoothing task without
> introducing artifacts. We need to leave the standard open on this
> until there is more evidence.
> 
>           jak
> 
> 
> 
> 
> 

alper

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 8 Jun 2001 14:07:39 -0500

James,

I can understand if the draft does not want to mandate or recommend
buffering, specifically for real time application, where buffering a
lot of data does not solve user problems.
However, it was not clear to me what drafts' position on buffering is,
specially since one of its prime goals is reducing latency for real time
application:

Is buffering optional (when buffering helps, says 1-2 voice packets)
supported, not supported?
Does the draft provide guidelines or  talk about tradeoffs? I think
buffering is an important issues. 

Regards,
Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Thursday, June 07, 2001 11:41 AM
To: [email-masked]
Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6

		jak

---

From: Alper Yegin <[email-masked]>
Date: Fri, 8 Jun 2001 12:15:39 -0700 (PDT)

James,

> might actually be  in transit or already arrived at newAR. The draft says 

Wouldn't you say MN's L2 should be aware of this? (we should clarify this in the 
draft)

> clear that was intended, but the draft needs revision.

Yes, this was already noted for next revision.

alper

---

From: [email-masked]
Date: Fri, 8 Jun 2001 12:29:07 -0700

Thanks. it woud not be bad idea to include issues out of scope in this draft.

Barani.

Alper Yegin <[email-masked]> on 06/08/2001 12:07:53 PM

Sent by:  Alper Yegin <[email-masked]>

To:   [email-masked]
cc:   [email-masked] (Barani Subbiah/HQ/3Com)
Subject:  Re: [mobile-ip] questions on fast handoffs for MIPv6

alper

causing
done.

alper

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 8 Jun 2001 14:41:48 -0500

Don't know why this one didn't make it to the list?
Send it again.

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 
Sent: Friday, June 08, 2001 1:53 PM
To: [email-masked]'
Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6

Hi Alper,

Thanks for the email. See my comments below:

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]]
Sent: Wednesday, June 06, 2001 2:10 PM
To: [email-masked]
Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6

Hi Madjid,

> Q1-Neighbor advertisement and L2 connectivity
> It says in the draft (page 5) that the newAR will deliver packets to the 
mobile
> when it receive indication from access network or NA from Mobile.
> In page 1 it says MN sends NA or F-NA to newAR as soon as it receives L2 
connectivity
> trigger. Could there be a race condition where newAR can start delivering 
packets
>  (based on L2 indication) before receiving an NA from MN? if not why is
the 
text 
> written that way?

I don't see a problem even when newAR detects arrival of MN, and at the same

time MN sends a F-NA to newAR. Do you see a problem?

MN>> I am not sure when the MN "gets ready" to receive package, right after
L2 connectivity or after its done sending F-NA or NA. Also I am guessing
that L2 indication comes from an AP (if AP and AR are not collocated)
to both AR and MN. So newAR and MN can possibly get their indications
at different times (wireless/ wired link bandwidth and error characteristics
are different).So it could happen that newAR starts delivering packets,
while
MN is not ready.  Maybe, I am stretching it but this is how the current text
reads.

> 
> Q2-It seems that the oldAR forwards MN's data to newAR as soon as oldAR 
> receives a BU from MN or an F-BU + HACk.
>  The newAR delivers the packets to the MN as soon as it receives an NA or
>  F-NA from the MN (apart from Q1 above). 
> This means that during this time the MN's packets must be buffered at 
> newAR (whether it helps real time traffic or not, is another issue).
> There was also a discussion about buffering at oldAR or at newAR, but
> I think what I missed on the discussion was that
> " is buffering at newAR supported or is it left to implementers,
>   (Should/ MUST/ May question?)"

We have a 'U' Buffer Flag in HA message. And I think this makes it an
optional 
feature. oldAR MAY turn this flag on. Do you think we should spell this out
in 
the draft?

MN>>Sorry, I am not sure what you mean by HA message and U flag, could you
please
lead me to the place in the draft? 

> Also what about ingress filtering issue at oldAR?

MN doesn't have to use newCoA as the source address of F-BU. It can use
oldCoA 
as the source address, and include a alternate CoA suboption. (I'm not sure
if 
this is already stated in the draft. If not, we should add this.)

MN>> That is acceptable, but as it is stated in the draft (page 2)

"The mobile node sends a Fast Binding Update using its newly formed 
   COA as the last message before it executes the handover."

is a bit ambiguous.

BR,
Madjid

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 8 Jun 2001 13:52:39 -0500

Hi Alper,

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]]
Sent: Wednesday, June 06, 2001 2:10 PM
To: [email-masked]
Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6

Hi Madjid,

mobile
connectivity
packets
>  (based on L2 indication) before receiving an NA from MN? if not why is the 
text 

MN>> I am not sure when the MN "gets ready" to receive package, right after
L2 connectivity or after its done sending F-NA or NA. Also I am guessing
that L2 indication comes from an AP (if AP and AR are not collocated)
to both AR and MN. So newAR and MN can possibly get their indications
at different times (wireless/ wired link bandwidth and error characteristics
are different).So it could happen that newAR starts delivering packets, while
MN is not ready.  Maybe, I am stretching it but this is how the current text reads.

MN>>Sorry, I am not sure what you mean by HA message and U flag, could you please
lead me to the place in the draft? 

is a bit ambiguous.

BR,
Madjid

---

From: James Kempf <[email-masked]>
Date: Fri, 8 Jun 2001 14:11:28 -0700 (PDT)

Alper,

Bicasting is needed for ping-ponging. 

		jak

>Date: Fri, 8 Jun 2001 12:01:27 -0700 (PDT)
>From: Alper Yegin <[email-masked]>
>Content-MD5: 5aiUiiWadtM0RBnOD58dtA==
>

---

From: James Kempf <[email-masked]>
Date: Fri, 8 Jun 2001 14:14:52 -0700 (PDT)

>buffering is an important issues. 

If the authors want to talk about handoff smoothing, then they should.
But they need to consider bicasting too. As it is, the draft says
nothing about smoothing, and, as Charlie mentioned, the plan  is
for that to be in another draft.

		jak

---

From: Alper Yegin <[email-masked]>
Date: Fri, 8 Jun 2001 16:17:13 -0700 (PDT)

Madjid,

> L2 connectivity or after its done sending F-NA or NA. Also I am guessing

Abstractly speaking, L2 connected MN is ready to receive packets (as long as 
sender knows where to send).

reads.

I'm not sure about this example. It sounds like data packets from AR are ahead 
of L2 attachment indication to MN. This didn't make sense to me.

please
> lead me to the place in the draft? 

Sorry. I meant "HI" message. 

>    COA as the last message before it executes the handover."

Thanks for this catch. We should make this clear in the draft.

alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 8 Jun 2001 16:21:26 -0700 (PDT)

Madjid,

> 
> Alper, 
> 
> Hate to bring security issues in here, since this was about buffering
> but, you brought it up :) Sorry.
> 
> 1-Why does MN need to authenticate itself to oldAR, while it
> is saying "goodbye" to it. It has been receiving service from
> oldAR so far, hasn't it?

This is the standard Binding Update authentication. Nothing new.

> 
> 2-authentication of oldAR to newAR does not solve all the
>  security problems, what about 
> authentication of newAR to oldAR, what about authorization of 
> newAR to receive MN's packets?
> 

Both HI and HACK are authenticated, therefore oldAR is authenticated to newAR, 
and vice-versa.

alper

> Sent: Friday, June 08, 2001 2:08 PM
> Cc: [email-masked]

alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 8 Jun 2001 16:24:56 -0700 (PDT)

Jim,

> Bicasting is needed for ping-ponging. 

Even for ping-ponging, if oldAR can detect that MN is back (ponged :), then it 
can start forwarding traffic through its link.

If MN pings again (gone to new link), the oldAR can detect this and start 
tunneling to newCoA.

Therefore this L2 feature can be used to handle ping-ponging without requiring 
bi-casting.

alper

alper

---

From: James Kempf <[email-masked]>
Date: Fri, 8 Jun 2001 16:35:30 -0700 (PDT)

Alper,

>Therefore this L2 feature can be used to handle ping-ponging without requiring 

Sure, it's possible to switch the L3 back and forth, but coupling
that with L3 buffering gets complicated. Suppose newAR is buffering.
When the MN pongs, how does it pick up the buffered packets? 

		jak

---

From: Alper Yegin <[email-masked]>
Date: Fri, 8 Jun 2001 17:00:33 -0700 (PDT)

Jim,

> When the MN pongs, how does it pick up the buffered packets? 

I am just saying, in the existence of this L2 feature, we don't need bi-casting. 
So, we don't need "this L2 feature + bi-casting", "this L2 feature" does the 
job.

I don't know where the buffering gets involved here. 

alper

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sun, 10 Jun 2001 22:44:41 +0200

Alper

> I don't think we need bi-casting if we have this L2 feature.
	=> And what if we don't ?
	Even if we do, I don'tthink we need such level of complexity 
	to determine whether a packet should be forwarded or not 
	on the IP layer. Most decent routers implement fowarding 
	in HW, we don't want to modify HW to implement 
	a Fast Handoff mechanism. 
	If the capability you're talking about exists in some cases 
	then the packets will be dropped on L2 layer anyway
	since there is no one to send it to. 

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sun, 10 Jun 2001 23:05:23 +0200

Alper,

> So, we don't need "this L2 feature + bi-casting", "this L2 feature" does the 
	=> Further to my last mail, I don't think you could really convince
	router designers to implement this when there is another 
	L2 independant mechanism for forwarding packets (bicasting).

	BTW, while we're on the topic, Karim and I will issue a 
	draft shortly on this. 

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 11 Jun 2001 19:39:39 +0200

Barani, 

	Your authorisation questions (at the new AR) are orthogonal to this draft. 
	This is what Alper said earlier. Authorisation (to get access to the Internet)
	is needed even without mobility.
	See comments below.

> here the text i sent in another mail. it should answer your question.
> 
> in the mobile controlled handoff case, its the MN which says
> i want to move to this particular AR.
> 
> >> How does the MN informs this to Old AR when the MN has not "arrived" or not
> connected or not exhanged any packets with the new AR?
> 
	=> Which part of the draft isn't clear ?
	The MN sends a BU to the old AR.

> so here there is no
> question of authorization of the newAR to receive MN's
> packets.
> 
> >> New AR has to authenticate the MN before it can store packets for the MN. If
> not, it will opne many issues.
> 
	=> Again this is orthogonal to the draft. This has to happen for 
	any node connected to a router.

> in the network controlled handover, its again some
> network entity
> 
> >>  can you point out which entity? or Are we going to leave this out of this
> draft.
> 
	=> How about we read the draft :) It's the old AR.

> which decides that this particular MN should
> be handed over to this AR. there is no question of
> authorization of the newAR in this case either.
> 
> the newAR also receives a HI from the oldAR protected by
> an authentication header. the oldAR receives a HAck from
> the newAR protected by an authentication header.
> 
> 
> >> I am not interested to reopen the fast handoff and buffering. My concern is,
> the scenario where we allow the new AR to buffer packets before the
> mobile can attach itself to new AR.
> 
>      2. Ping pong effect - when the mobile is not able to attach to new AR after
> Hi-HACK (between ARs). Either the mobile returns to old AR or selects a
> different AR. What happens to buffered packets at the anticipated new AR?
> 
	=> They get dropped. 

>      3. Timing issues - How long and how much buffer has to allocated, What
> happens if the MN has not attached itself with in the time limit.
> 
	=> This is system and implementation dependant. 

> for various reasons, IMHO even if buffering is good choice we should avoid
> buffering packets for un attached MNs.
> 
	=> RFC 2461 says that if the default router receives a packet addressed
	to a node on its link, it attempts to resolve the address several 
	times. In the mean time packets are buffered.

	Hesham

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 11 Jun 2001 15:42:18 -0500

Alper,

Thank you for your email. Please see my comments below (MN>>>>)

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]]
Sent: Friday, June 08, 2001 6:17 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6

Madjid,

the 

MN>>>>Well, how does the sender know where to send the packets before
receiving 
F-NA/NA from the mobile?

while
reads.

I'm not sure about this example. It sounds like data packets from AR are
ahead 
of L2 attachment indication to MN. This didn't make sense to me.

MN>>>> to me neither. Tell me who sends L2 attachement to MN,
AR or AP, if AR does then there would be no race condition
(however, this would not be a general case, I think), but
if AP does, then AP sends the signal to AR as well and there
would be a time when one of  AR and MN does not know about the
L2 connectivity (I think MN would know later, but it is not certain)
  
As you said earlier, newAR should deliver MN's 
packets when it knows that it has L2 connection for 
the mobile and it has MN's address and this happens when it
has received F-NA from MN (MN sends F-NA after L2 connectivity)
So the draft can mention the following as condition:
      (has received F-NA)
or to be safer
	(received F-NA *AND* indication on L2 connectivity) 
NOT as it says in the draft 
	(received NA *OR* L2 connectivity),
 otherwise the race condition might happen (as I said earlier:
when L2 signal comes from an AP to AR and MN separately, instead of
direct communication between MN and AR)

optional 

please

MN>>>> Ok, thanks, I still has not found the U flag in the draft :((
Is it in the MIPv6 base draft? I did not see it there either?

oldCoA 

MN>>Thanks, I too feel better now :)

Regards,
Madjid

---

From: Alper Yegin <[email-masked]>
Date: Mon, 11 Jun 2001 15:01:58 -0700 (PDT)

Madjid,

> MN>>>>Well, how does the sender know where to send the packets before

L2 address of MN is sent in HI message from oldAR to newAR. As soon as MN 
attaches to new link, "if" newAR can detect this attachment and correlate this 
to MN, then newAR can start forwarding packets. Otherwise, newAR needs to wait 
for F-NA. "where to send" information is the L2 address of the mobile node, 
which was communicated in the HI message.

> L2 connectivity (I think MN would know later, but it is not certain)

So, what you are saying is this: there can be a case where AR thinks MN is L2 
connected and starts sending packets, but MN is actually not L2 connected yet. 
This sounds like a L2 problem, that needs to be handled at L2. I think L2 folks 
should fix this :)

> 	(received F-NA *AND* indication on L2 connectivity) 

Well, if newAR has received F-NA, who cares about L2. MN is clearly L2 connected 
if it were able to send this F-NA.

> Is it in the MIPv6 base draft? I did not see it there either?

page 16 and page 21 of FMIPv^ draft.

> MN>>Thanks, I too feel better now :)

Thanks Madjid,

alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 11 Jun 2001 15:13:21 -0700 (PDT)

Hesham,

> > > >Even for ping-ponging, if oldAR can detect that MN is back (ponged :), 
then 
> > it 

I think this is taking advantage of L2 features, which I suspect they'd want to 
do. Well, I guess we'll see.

> 	BTW, while we're on the topic, Karim and I will issue a 

Looking forward to it.

alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 11 Jun 2001 15:11:21 -0700 (PDT)

Hesham,

> 	since there is no one to send it to. 

I don't think this is that complicated. And clearly more optimized then 
replicating data traffic and sending two copies each time.

If you see this as a problem for forwarding in the HW, I assume same problem 
applies to bi-casting. That HW needs to know which packets to bi-cast, where to 
bi-cast.

If I have a L2 with this capability, while should I duplicate my traffic knowing 
that one would be dropped, whereas I can know exactly where to send it? It's not 
like bi-casting is for free.

alper

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 12 Jun 2001 00:22:01 +0200

Alper,

> replicating data traffic and sending two copies each time.
	=> You're not answering my question above. What if we don't 
	have that capability ? Regarding your point above, I can't
	see how there is any replication in the case where we have 
	an intelligent L2 that knows if a device has disconnected. 
	How can it send something to a "non-existent" device ?

> applies to bi-casting. That HW needs to know which packets to bi-cast, where to 
	=> I wasn't talking about the forwarding itself, I was referring 
	to these L2 triggers that will change the forwarding 
	tables. Which btw may not be secure in case your L2 
	doesn't have the appropriate level of security, but that's
	another point.

> If I have a L2 with this capability
> 
	=> _what_if_you_don't ?? We design another solution ?

> , while should I duplicate my traffic knowing 
	=> Nothing is free of course, but you're trying to have multiple 
	solutions where I want one. In this case the one I'm referring 
	to will have the exact same effect. So why are we trying to solve
	the problem twice ? Seems wasteful to me. 

	Hesham

---

From: Alper Yegin <[email-masked]>
Date: Tue, 12 Jun 2001 11:54:52 -0700 (PDT)

Hesham,

> 	have that capability ? Regarding your point above, I can't

I'll answer this below.

> 	How can it send something to a "non-existent" device ?

I wasn't saying that packets are replicated on the air. Packets are definitely 
replicated in the IP stack, right? This is bi-casting. Only after they are 
passed to L2, one copy might be dropped if this L2 knows MN is no longer 
attached.

I don't want to replicate packets, if I know one copy is not needed at all. Why 
don't we communicate this "L2 not attached" information to where packets would 
have been replicated, stop bi-casting and forward packets to one place?

> 	doesn't have the appropriate level of security, but that's

Not trusting your L2... I'd say this is out of scope.

> 	the problem twice ? Seems wasteful to me. 

I agree that it's very desirable to have one solution that works in every case. 
But, we should also be aware of it's costs, and alternative solutions which are 
optimized in certain cases.

What I'm saying is, whenever available, connection-oriented L2 features should 
be used, instead of bi-casting. If this feature is not available, then something 
else can be used. 

I understand it's desirable to have one solution. But I clearly see a benefit to 
taking advantage of this L2 feature. Do you see any technical problems with this 
approach, other than it using a case-specific solution?

alper

---

From: James Kempf <[email-masked]>
Date: Tue, 12 Jun 2001 14:23:51 -0700 (PDT)

Alper,

>have been replicated, stop bi-casting and forward packets to one place?

There is no reason why oldAR can't stop replicating packets once it
gets an L2 signal that MN is gone. There is no point in continuing
to send packets on old L2 unless MN shows up again due to a ping-pong.

The replication at oldAR is only needed from the time the oldAR determines that
an L2 handoff is about to take place until the oldAR drops the old L2
due to an L2 handoff occuring. The reason you need that replication
is because of the uncertainty involved in exactly when the L2 handoff
will occur and how long it will last. During that interval, the newAR should
be using a sliding window buffer at L2 to hold a few radio frames
until the MN shows up on the new link. The buffer size
should be calculated to give some high percentage of covering the
L2 handover time on average (figure 90% coverage, for example, probably
best to measure experimentally) for a particular radio link protocol and
incoming bit rate.

If a ping-pong occurs, the MN is back on oldAR and it may miss a few
packets that arrived while the MN was in transit from and back to oldAR. This
could cause an artifact in the real time transport if enough are dropped.
An alternative would be for oldAR to apply the same kind of sliding
window buffer for some period of time (again determined experimentally)
until it is, say, 90% certain that a ping-pong won't occur, then
switch off the L2. 

If the L2 doesn't support buffering, then perhaps a similar small
L3 buffer for the duration of the L2 handover could be implemented.

The kind of thing I don't think is needed is full up L3 packet buffering
on newAR from the time the HACK gets sent out until the time
the MN sends the F-NA. In that case, if the MN pongs back to the
oldAR, there is a bigger chunk of state on newAR that newAR has to
deal with (drop? forward to oldAR?), and oldAR doesn't have
anything for MN unless it, too, buffers. The radio channel on newAR also gets
preempted while that chunk of state is sent down to the MN. Plus it requires 
more state in the router.

To see how much more, consider the following calculations:

Case 1:
The buffer is designed to accommodate only traffic while L2 handover 
is in progress. Suppose the L2 handover requires, on average 200 ms (sorry for 
the imprecision, I'm having difficulty locating exact L2 handover times). That's 
240 bytes at 9.6 kbps, or 6 WCDMA frames. The data rate here could be
more or slightly less, but this seems like a reasonable assumption.

Case 2:
The buffer is designed to accommodate all incoming L3 traffic between
HACK arriving and MN sending F-NA indicating it is up on the newAR. 
It is difficult to estimate when the HACK might arrive, but let's say
there is a 10 ms lag between HI and HACK, so the HACK arrives 10 ms
after an L3 handoff begins. Some estimates for L3 handoff times
were included in the previous email I sent out, so let's assume
that the amount of buffering is: (L3 handover time - 10 ms) + L2 handover time.
L2 handover time is 200 ms from above. The most optimistic L3 handover
time at 9.6 Kbps from my previous calculations is 133 ms. The result
is 387 bytes, or 62 % more buffer required.

In reality, it would have to be more than 387 bytes because I assumed
the most optimistic time. You would have to measure experimentally
how often the various combinations of F-BU on oldAR or newAR,  F-BACK
on oldAR or newAR, etc occured and size the buffer so it accommodated
90% of that variability. 

Multiply that extra buffer size by the number of mobile nodes you want
to support, and it should be clear the Case 1 is more scalable.

As I think should be clear from this discussion, the situation is
not one of bicasting v.s. buffering but rather how to use both
in a way that will accommodate the characteristics of the radio link
to provide the smoothest possible handover for the MN.
In some radio links, you might not need one or the other, but for
typical 3G radio links, I think you will need both.

		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 13 Jun 2001 00:17:55 +0200

Alper, 

> have been replicated, stop bi-casting and forward packets to one place?
	=> That's clearly not free either as was discussed many times
	in the DT. Apart from the complexity of implementing it
	(we agree that there is complexity in implementing anything
	really), there maybe delays in detecting the MN's detachment
	on L2. This will add delays in packet forwarding. 

> Not trusting your L2... I'd say this is out of scope.
	=> Huh ?  Not all L2s have a different security association
	per device. 

> optimized in certain cases.
	=> Of course, but right now we don't have a soution after bicasting 
	was removed from the draft. We've been over this many times
	now and we always discussed adding the _option_of bicasting.
	It was never a MUST.

> be used, instead of bi-casting. If this feature is not available, then something 
	=> Like bicasting ? another solution ? nothing is in the draft 
	right now.

> approach, other than it using a case-specific solution?
	=> Alper, if you want to implement this in your router no one 
	will / can stop you from doing so. But if you don't want to
	or the solution won't work for you, then what do you do ?

	BTW, if we can rely on the method you mention here, 
	why did we have the NA message to inform the new 
	AR that the MN has appeared on link ?

	Ping pong is not the only reason for using bicasting, 
	once you anticipate movement, you're ever 100 % sure
	about the exact time at which you will lose L2 connectivity, 
	therefore packets will be lost in the mean time. 

	Hesham

---

From: Alper Yegin <[email-masked]>
Date: Wed, 13 Jun 2001 11:11:51 -0700 (PDT)

Jim,

> to send packets on old L2 unless MN shows up again due to a ping-pong.

Yes, we are in agreement here. 

> will occur and how long it will last. During that interval, the newAR should

If there's a possibility that MN might successfully attach to new link, before 
oldAR recevies a L2 detach notice, only then it makes sense to bi-cast until L2 
detach signal. If we certainly know MN cannot attach to new link until oldAR 
receives the L2 detach notice, then I still don't see why we should bi-cast. If 
this is the uncertainity you are talking about, it'd make more sense, yet I 
don't know how big are the savings here. [depends on system, implementation, 
etc..]

> until it is, say, 90% certain that a ping-pong won't occur, then

Yes, if you want to smooth the handover in a way that you want to save packets 
which arrived at the oldAR while MN is ponging back from newAR... Further 
smoothing..

> typical 3G radio links, I think you will need both.

That makes sense. Depending on the system, people can implement these different 
handoff smoothing techniques. I don't think these require a protocol 
specification. IMHO, these are implementation decisions.

alper

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 13 Jun 2001 13:21:31 -0500

Alper,

Thanks for the email and thanks for the ref to U flag.
 Please see my comments below.
I did cut a lot for readability.

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]]
Sent: Monday, June 11, 2001 5:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6

.....<snip>

L2 address of MN is sent in HI message from oldAR to newAR. As soon as MN 
attaches to new link, "if" newAR can detect this attachment and correlate
this 
to MN, then newAR can start forwarding packets. Otherwise, newAR needs to
wait 
for F-NA. "where to send" information is the L2 address of the mobile node, 
which was communicated in the HI message.

MN>> Ok, Maybe I need to do some studying on the addressing issues,
at this point, I am not sure what correlating in this case means,
Does it mean newAR looks at its database for MN's address (stateful)
what about stateless?
I would say waiting for F-NA is the layer 3 way of doing things. 
You seem to be relying on some L2 mechanisms, am I missing something?

> L2 connectivity (I think MN would know later, but it is not certain)

So, what you are saying is this: there can be a case where AR thinks MN is
L2 
connected and starts sending packets, but MN is actually not L2 connected
yet. 
This sounds like a L2 problem, that needs to be handled at L2. I think L2
folks 
should fix this :)

MN>> Well maybe, but the way it is written in the draft, you are
making your protocol volnurable to L2 imperfections!! Especially
in the solution that offerred in your first answer above.
I still have a hard time to digest your "based on L2 connectivity
signal OR receiving F-NA" condition.

Let me know if I am confused.

Madjid

---

From: James Kempf <[email-masked]>
Date: Wed, 13 Jun 2001 11:24:38 -0700 (PDT)

Alper,

>don't know how big are the savings here. [depends on system, implementation, 

You are talkng about make before break, and this is not typically the
kind of handoff where MIP would come into play. MIP would only come
into play when the connection with the old access point is broken,
at L3, before it comes up on the new.

But I'm curious why you feel that a make before break handoff would
be the only case that would benefit from bicasting. To me, it is
the other way around. The reason is because the MN breaks  the
old L2 before the new L2 is solid enough for L3 traffic. Typically,
there is some short period of time when the MN and new AP exchange traffic
to be sure the connection is solid, before L3 traffic resumes. Since
the exact duration of this time period is uncertain and when the
old L2 is broken, it makes sense to send the MN's traffic to newAR before there 
is a break in the old L2, to make sure the MN doesn't miss anything. Or?

>specification. IMHO, these are implementation decisions.

I think there are interoperability considerations, and to the extent
there are, it should be specified. Suppose I connect a Nokia router
and a Motorola router, and one does smoothing as I outline and the
other doesn't?

		jak

---

From: Alper Yegin <[email-masked]>
Date: Wed, 13 Jun 2001 11:32:08 -0700 (PDT)

Hesham,

> > > > that one would be dropped, whereas I can know exactly where to send it? 
It's 
> > not 

There are a number of solutions. Bi-cast, connection oriented L2, buffering. For 
some systems one is better, for other others. Sometimes you want to mix them. 
These are all implementation specific. I don't see a protocol work here.

As I said before, implementors will make their choices. For the networks in your 
mind, maybe bi-casting is the only solution. Fine, they can use it. For others 
L2 signals might be sufficient.

> 	AR that the MN has appeared on link ?

Because, as you'd agree, not all L2's have that capability. And as a protocol, 
we don't want to tie FMIPv6 to a specific L2.

All I was saying was "when available", this L2 faeture can be used to replace 
functionality of bi-casting. Implementors can choose to use anything they like.

> 	therefore packets will be lost in the mean time.

Basically, what I'm saying is, choice of smoothing technique is 
implementation/system specific, and not a part of the "protocol". Implementors 
can use FMIPv6 protocol with any of the available smoothing techniques, and be 
able to interoperate with others' products.

alper

---

From: Alper Yegin <[email-masked]>
Date: Wed, 13 Jun 2001 12:00:42 -0700 (PDT)

Jim,

> at L3, before it comes up on the new.

I didn't mean make-before-break. I'm just trying to understand where the 
uncertanity is.

> is a break in the old L2, to make sure the MN doesn't miss anything. Or?

OK, that makes sense.

> and a Motorola router, and one does smoothing as I outline and the

And you get partial smoothing (lose some packets), and that's fine. That was 
apparently implementors or administrator's choice. Or your choice when you 
signed up for that service :)

alper

---

From: [email-masked]
Date: Wed, 13 Jun 2001 12:01:20 -0700

As in the draft and this thread, I like to point out that Link layer address
based verification across ARs should be avoided as much as possible.
MN can have two interfaces and also move from one AR to another AR using the new
L2 interface.

If we want L2 identifier then there should be a way that MN can indicate to the
old AR about the new Link layer ID that it will be using plus the current L2 ID.

Barani.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 14 Jun 2001 17:42:12 +0200

Hello Charlie, 

> >         => Not quite, that maybe true in the network determined case where
> >         the MN does not send a BU to the old AR. If the MN sends a BU
> >         then it MUST be able to request bicasting for a number of reasons:
> > 
> >         1. BU list management in terms of lifetimes
> >         2. In some cases (different access technologies) the MN doesn't
> >             need to request bicasting at all. The AR won't have that knowledge
> >             and therefore the best place to have the request is the BU.
> 
> I don't think that this behavior has been mandated -- certainly
> not for Mobile IPv6!  Thus I would ask that you not capitalize such
> "MUST"s merely for emphasizing your point.  A lot of people might
> get the wrong impression.
> 
	=> I wasn't quoting any RFCs or drafts. 

> Plus, how does (2) support your contention?!  Didn't you claim in
> earlier messages that when bicasting has value, its value depends
> on characteristics of the access medium?  
> 
	=> Yes.

> Why doesn't the access
> router have knowledge of those characteristics?
> 
	=> I am referring to an example of a case where the MN
	has two interfaces and can receive two traffic streams
	simultaneously. I don't expect a router connected 
	to a WCDMA network to know that there is a WLAN
	network nearby and that the MN can hear both. 
	I don't think this should be expected. 

	IF the air interface happened to allow the MN to receive
	two sets of traffic streams from two different routers 
	on a single physical interface in the MN, then 
	I would expect the AR to know about this. 
	This would be a link layer that allows for make before break
	handovers. Not many of those are around, if any. 

	Regards,
	Hesham

---

From: Alper Yegin <[email-masked]>
Date: Thu, 14 Jun 2001 19:38:20 -0700 (PDT)

Madjid,

> Does it mean newAR looks at its database for MN's address (stateful)

Ability to identify the matching HI message based on the L2 address of the newly 
attached MN.. Once newAR find the matching HI message, it can figure out who 
this MN is. And start forwarding this MN's traffic.

> You seem to be relying on some L2 mechanisms, am I missing something?

Using them (L2 features) whenever they are available.. If missing, then rely on 
L3.

> in the solution that offerred in your first answer above.

If there's some imperfection on the L2, of course it effects the protocol. We 
cannot guard the protocol againist this kind of L2 problems.... 

alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 14 Jun 2001 19:40:23 -0700 (PDT)

Barani,

> old AR about the new Link layer ID that it will be using plus the current L2 
ID.

If this is a mobile node with multiple links, which can be connected to 
different ARs at the same time, you most probably don't need FMIPv6 draft.

alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 14 Jun 2001 19:46:05 -0700 (PDT)

Hesham,

> > >         1. BU list management in terms of lifetimes

Can you please elaborate this, I didn't get it.

> 	I don't think this should be expected. 

Why do we need FMIPv6 in this case? You have two simultaneously connected 
interfaces.. 

alper

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 15 Jun 2001 13:38:35 +0200

Alper, 

> Can you please elaborate this, I didn't get it.
	=> You need to know how long a Binding Update entry is valid for. 
	Ie. how long will the AR forward to a particular address for. 
	If you don't communicate that in the BU there is no
	way of knowing when to remove the entry, or when the 
	AR will require a refresh, or when it will stop forwarding. 

	So if you're bicasting you need to know how long the bicasting 
	lifetime is.

> Why do we need FMIPv6 in this case? You have two simultaneously connected 
	=> You don't, which is what I was saying.

	Hesham

---

From: [email-masked]
Date: Fri, 15 Jun 2001 05:55:25 -0700

Charles,

Yes, you got it right.

Barani.

Charles Qi Shen <[email-masked]> on 06/15/2001 04:42:33 AM

Sent by:  Charles Qi Shen <[email-masked]>

Barani,

Do you mean a mobile with multiple interfaces but it only uses a single
interface at any given time and it changes this single interface after a
handoff?

Charles

At 09:23 PM 6/14/2001 -0700, you wrote:

>Alper,
>
>No. It is a single mobile with multiple links but connects via a single
>link at
>any given time to a single AR. However, after hand off it connects to new
>AR via
>a different link. Example would be WLAN and WWAN or any other combination.
>
>Barani.
>
>
>
>
>Alper Yegin <[email-masked]> on 06/14/2001 07:40:23 PM
>
> > MN can have two interfaces and also move from one AR to another AR
> using the
>new
> > L2 interface.
> >
> > old AR about the new Link layer ID that it will be using plus the
> current L2
>ID.
> >
>

---

From: Alper Yegin <[email-masked]>
Date: Fri, 15 Jun 2001 17:40:56 -0700 (PDT)

Hesham,

> 	So if you're bicasting you need to know how long the bicasting 

Bi-casting lifetime is different than binding cache lifetime, right? I'm 
guessing you wouldn't want your oldAR to bi-cast as long as it has a binding 
cache entry of the oldCoA.

Binding cache entry lifetime is dealed with the Binding Update already. And 
bi-cast lifetime, which is presumably a very short period, a L2 dependent 
duration, can be determined by oldAR. And mobile node wouldn't even know when it 
started, when it's terminated (given that it reecives single stream of data).

> 	=> You don't, which is what I was saying.

You were saying that there are cases (such as above) where MN wouldn't request 
bi-casting, as it's not needed. According to your logic (if I'm following it 
right) that means we need a flag or something in the BU "not to request" 
bi-casting. But, if we are not talking about FMIPv6 (as you agreed above), then 
we are not talking about having such a flag in F-BU.

When oldAR receives a F-BU, it can bi-cast. When it recevies regular BU, it can 
choose not to bi-cast. 

So, I don't see how this example justifies that MN needs the capability to 
request bi-casting.

alper

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 18 Jun 2001 09:21:17 +0200

Alper, 

> Bi-casting lifetime is different than binding cache lifetime, right? 
> 
	=> No, it is a binding cache entry. It's different for one of the 
	addresses if that's what you mean. Ie. not one lifetime 
	for both addresses.

> I'm 
	=> Correct.

> duration, can be determined by oldAR. 
> 
	=> No. The MN still has to know. You might want to extend
	it. For example ping pong might occur for a longer period 
	than expected. 

> we are not talking about having such a flag in F-BU.
	=> You're referring to one particular case above, there maybe 
	other cases where bicasting doesn't need to be a default
	behaviour. We will deal with those examples in the draft. 

	Hesham

---

From: [email-masked]
Date: Mon, 18 Jun 2001 10:55:25 -0700

Charles: Thanks for the scenario.

Alper: you can think of the same scenario with no GPRS coverage inside the
building. IMHO, we are going to see scenarios like this more often than a pure
single access technology wireless data access.
You can also think of same operator providing WWAN and WLAN (hot spot) coverage
and like to use fast MIP techniques.

I like to suggest that we remove any dependency of L2 with FMIP techniques.

Barani.

Charles Qi Shen <[email-masked]> on 06/18/2001 02:57:39 AM

Alper,

I am not aware of what kinds of scenarios Barani may have in his mind.
Please see whether my scenario can be something close to that.

For example, you have a Mobile Node with two interfaces, one GPRS and one
Wireless LAN, your company is covered by WLAN and you can use it for free
within the company, while you are outside you will use GPRS. Since you pay
for your GPRS but not the WLAN. You may wish to use WLAN *only* while
inside the Company. In this case, it is not really this mobile node
*cannot* have both interfaces connected, but it is the user choosing so.

Charles

At 05:26 PM 6/15/2001 -0700, you wrote:
>Barani,
>
>Is there any reason why this mobile node cannot have both interfaces
>connected
>at the same time? Do you have a scenario where it can or it should have
>only one
>connected, although they are using different interfaces?
>
>alper
>
>
> >
> > Alper,
> >
> link
>at
> > any given time to a single AR. However, after hand off it connects to
> new AR
>via
> > > If we want L2 identifier then there should be a way that MN can
> indicate to
> > the

SHEN, Qi (Charles)
Centre for Wireless Communications
National University of Singapore
20 Science Park Rd. #02-34/37, TeleTech Park
Singapore Science Park II, Singapore 117674
Tel: +65 870-9358       Fax: +65 779-5441
Email: [email-masked]
URL: http://www.cwc.nus.edu.sg

---

From: Alper Yegin <[email-masked]>
Date: Mon, 18 Jun 2001 19:58:43 -0700 (PDT)

Charles, Barani,

All it takes to avoid using FMIPv6 is the capability to be data connected at two 
interfaces for few seconds. So, if there's overlap (worth few seconds) then one 
can get away without using FMIPv6.

During the overlap, the other interface is used to configure a new CoA and send 
a BU to oldAR to establish forwarding from previous care-of address. After this 
point old attachment can be released.

I think few seconds overlap is reasonable. 

alper

alper

---

From: [email-masked]
Date: Tue, 19 Jun 2001 09:54:55 -0700

Alper,

I am not sure if this is a valid assumption to design a solution that works
given few seconds of overlap. The scenarios such as BT-WLAN-WWAN-Ethernet will
be the most prevalent wireless data access scenario and Mobile IP has lots to
gain to propose solutions that works across heterogeneous access (L2)
technologies.

Again, I want to emphasis that we remove any L2 dependency with FMIP. There are
other ways to solve the problem with out using L2 identifier.

Barani.

Alper Yegin <[email-masked]> on 06/18/2001 07:58:43 PM

Charles, Barani,

alper

alper

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 20 Jun 2001 02:28:40 +0200

> be the most prevalent wireless data access scenario 
> 
	=> That's certainly debatable to say the least, but I guess 
	this is a side topic for this list. Which asumptions in the draft do you 
	disagree with ? Do you disagree that some overlap between
	coverage areas is required ? I find that hard to believe since this 
	is the fundamental requirement for ANY wireless system. 

> and Mobile IP has lots to
	=> MIP already works across heterogenous networks due 
	to its location in the stack. Again what in the draft eliminates this 
	very useful feature ?

> Again, I want to emphasis that we remove any L2 dependency with FMIP. 
> 
	=> We are doing a handover because we're moving within the topology. 
	Topological movement can be due to physical movement (L2 changes)
	or changes in the topology. In the former I can't see how you could 
	possibly eliminate the need for an L2 indication. In the latter you 
	rely less on L2 knowledge but knowing it is a good optimisation. 
	Which scenario doesn't require L2 knowledge ?

> There are
	=> It would be good to know these, can you please elaborate ?

	Hesham

---

From: [email-masked]
Date: Thu, 21 Jun 2001 09:58:34 -0700

See comments below.

Barani.

"Hesham Soliman (ERA)" <[email-masked]> on 06/19/2001 05:28:40
PM

Sent by:  "Hesham Soliman  (ERA)" <[email-masked]>

To:   "'mobile-ip @sunroof.eng.sun.com'" <[email-masked]>
cc:    (Barani Subbiah/HQ/3Com)
Subject:  RE: [mobile-ip] questions on fast handoffs for MIPv6

//// The discussion so far is that does MN need to have connectivity to both AR
domains at same time (L3 at old AR and L2 at new AR).
Have a look at Alper's recent posting. FYI. current 802.11 spec does not allow a
client to connect to 2 APs at any time.

/// L2 dependency. See Alpers recent posting

/// There is a difference between L2 assistance and dependence. You are
referring to L2 assistance  and it is a good thing to have, but not the later.
L3 solutions can use L2 indications but should not expect the same L2 appear on
the other side after the handoff.

/// It will be in response to Alpers mail.

     Hesham

---

From: [email-masked]
Date: Thu, 21 Jun 2001 10:44:26 -0700

Alper,

comments below.

Barani.

Alper Yegin <[email-masked]> on 06/20/2001 11:16:43 AM

Barani,

I agree there will be a mix of access technologies deployed and Mobile IP will
be best used across this kind of environment.

>>>> I am glad to hear this.

And I think you also agree that if there's "enough" overlap between two
different access network coverage, we don't need FMIPv6.
"enough" being few seconds needed to configure a new CoA and send a BU to oldAR.

>>>> Yes, if the MN can connect at the same time to both access network.

There might be cases where MN doesn't have this few seconds, and need to use
FMIPv6. In this case, the L2 indetifier MN send in F-BU does not match the L2
identifier it'll be using at the new link. That means newAR cannot detect this
"mobile node" at L2, but instead needs to wait for the F-NA, which is in the
draft.

I don't see this as a "L2 dependency".

So, draft has a solution for your scenario (F-NA). But of course, we'd like to
hear your proposal as well.

>>>> We have tried to create a new ID called Association ID (AID), which is
created using AR L2 address, thus unique to each ARs. When a MN associated with
a AR, both MN and AR exchange this AID and agree to use this AID if and when
there is a hand off.
So, in the HI message from old AR to new AR, we can send this AID instead of L2
ID.
Once the MN move to new AR, it should send this AID to new AR so that new AR can
bind the AID and new L2 address and/or AID and new CoA.
It can be in F-NA. We are experimenting to see if we can extend the "ARP" to
carry this AID to the new AR. My proposal is that if we can find a way to get
this AID at the same time when L2 identification happens then we get the same
effect of moving with same L2.

alper

alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 21 Jun 2001 20:30:39 -0700 (PDT)

Barani,

> effect of moving with same L2.

As long as there's a way MN can negotiate this AID with the oldAR while it's 
attached to it, and MN can communicate this AID to newAR to signals it's 
arrival, I don't think there's anyhting that holds implementations from sending 
this AID in HI message... (pretend this is the L2 address of MN).

I guess this AID exchanges can happen outside FMIPv6 protocol signaling. But, if 
you are saying that we should put this AID in F-NA message, then I'd ask why we 
need this? If this is used to associate a fast handoff with the arrival of the 
MN, then F-NA carries oldCoA and newCoA to accomplish this.

alper

alper

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 25 Jun 2001 11:18:49 +0200

> domains at same time (L3 at old AR and L2 at new AR).
	=> Yes I followed that discussion. The point is that if you do have it then
	you can use standard MIPv6, if you don't then you should use this 
	draft. Overlap != simultaneous connectivity and receiving two
	independant traffic streams. Every wireless system has overlap between
	coverage area, but that doesn't equate to a "make before break"
	handover.

> current 802.11 spec does not allow a client to connect to 2 APs at any time.
> 
	=> I am aware of that. see above.

> the other side after the handoff.
	=> Agreed. I still don't see where the L2 dependancy is ? The draft 
	only relies on assistance. Having overlapping coverage areas
	is an assumption you can safely make abouany wireless
	system that provides an acceptable handover performance.

	Hesham