Subject: Re: [Mipshop] comments on Mobile IPv6 Fast Handovers over IEEE 802.16e Networks draft

From: Daniel Park <[email-masked]>
Date: Fri, 15 Jul 2005 07:04:53 +0000 (GMT)

I am CCing James and Phil as a chair of  *netlmm* BoF...

>1. The draft is not talking about the network initiated L3 handover. 
>
>    I think, it is possible in the following scenario
>
>a)      BS and AR are collocated (as in Figure 3), and 
>
>b)      BS is sending MOB_BSHO-REQ
>
>
>Then AR can send PrRtAdv to MN, so that MN can start 
>handoff immediately (with out exchanging RtSolPr, PrRtAdv). 
>To accomplish this, a new trigger from L2 to L3 (similar to the 
>three primitives namely Link_Going_Down, Link_Up and Link_Switch 
>defined in the draft for interaction between FMIPv6 and 802.16e) 
>in BS may be required.

sounds interesting, but I am not sure it is in scope of FMIPv6
operation. Rather, it seems like network based mobility
support. During this meeting, *netlmm* BoF will be scheduled
to discuss network based localized mobility management,
and 802.16 will be presented at that time. If acceped, we will
be able to show this document...

James, Phil, could you let us know your view on the above ?

>2. In section 6.2 
>…
> 6.2  Handover Execution
>
>    When the FBAck message arrives before the handover, the MN runs as
>   predictive mode.  If the MN can not acquire the FBAck message on the
>   current link, it should run as reactive mode.  One reason for this is
>   that the MN has not sent FBU.  The other is that FBAck is lost during
>   the handover.

>Another reason can be FBU itself is lost as mentioned in FMIPv6 draft.
> 
>
>one Typo:
>
> In Section 6.1,
> 
>  After receiving either MOB_BSHO-RSP or MOB_BSHO-REQ message, the MN
>   may sends FBU (Fast Binding Update) to the PAR.  At this time, the
>              ^^^^^   
>   Link_Going_Down (LGD) is introduced to signal L3 of L2 reception of
>   MOB_BSHO-REQ/MOB_BSHO-RSP as soon as possible.
> 
>
>s/send/sends

s/sends/send   Right ? 

Anyway, thanks your comments at all. 

Regards   
 
Daniel (Soohong Daniel Park)
Mobile Platform Laboratory. SAMSUNG Electronics

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Subba Reddy <[email-masked]>
Date: Fri, 15 Jul 2005 12:52:00 +0530

Hi Daniel,

> operation.

Section 3.3. Protocol Operation of Network-initiated Handover of FMIPv6,
talks
about network initiated handoff.

<cut>

Thanks & Regards,
Subba Reddy

---

From: "Junghoon Jee" <[email-masked]>
Date: Fri, 15 Jul 2005 16:59:54 +0900

Hi Subba,
Thank you for reviewing this I-D.

> > >Then AR can send PrRtAdv to MN, so that MN can start handoff 
> > >immediately (with out exchanging RtSolPr, PrRtAdv).
> > >To accomplish this, a new trigger from L2 to L3 (similar 
> to the three 
> > >primitives namely Link_Going_Down, Link_Up and Link_Switch 
> defined in 
> > >the draft for interaction between FMIPv6 and 802.16e) in BS may be 
> > >required.
> >
> Section 3.3. Protocol Operation of Network-initiated Handover 
> of FMIPv6, talks about network initiated handoff.

Even though the L2 handoff can be initiated by AR(BS) in the network side,
the final decision of handoff is performed by MN by the MOB_HO-IND in the
IEEE 802.16e networks.
Therefore, I am not sure that *real* network initiated L3 handover can
happen in the IEEE 802.16e networks.

Network-initiated handover in the current FMIPv6 spec assumes that 
**Network** side can decide the target AR(NAR) thus notifies this
information though PrRtAdv to MN.

BTW, in the IEEE 802.16e networks,   **MN** decides the target AR(NAR) just
before sending the MOB_HO-IND.
Therefore, NAR information contained in PrRtAdv can be different from the
actual target AR(NAR) information decided by MN.

I think that FMIPv6's network-initiated handover has a meaning only if the
handover control is fully assigned to the network side,
where the network can instruct MN to commit L3 handover according to its own
decision.

Regards,
Junghoon

---

From: Heejin Jang <[email-masked]>
Date: Fri, 15 Jul 2005 17:24:45 +0900

Hi, Subba.
Thanks for your comments. 

Current version of this draft focuses on the most typical case.
But it's good idea to include the network-initiated handover in future version.
As you mentioned, the network-initiated handover is expected to show better performance 
when optimized with the close interaction of 802.16e via some primitives.
Specially in case of co-located AR/BS, network-initiated handover of FMIPv6 will be
tightly coupled with the BS-initiated handover of 802.16e.

---

From: Subba Reddy <[email-masked]>
Date: Fri, 15 Jul 2005 14:29:06 +0530

Hi Junghoon Jee,

<cut>

> information though PrRtAdv to MN.

I think, It (network or PAR) can decide, but it is not "MUST" to decide.
PrRtAdv can contain multiple (BSID, AR-Info) tuples in this case also.
i.e, it can contain more than one subnet information.
So, in this case also, MN can decide which network it wants to associate
with.
After this step, procedure defined for predictive case in the draft can be
followed.

> before sending the MOB_HO-IND.

Predictive case is covered in "FMIPv6 over IEEE 802.16e Networks" draft.
IMHO, Since MN has to send FBU and receive FBack, it needs to decide to
which BS it is
going to associate with.
For this FBU, FBack exchange should happen before sending MOB_HO-IND
(in predictive case).

> where the network can instruct MN to commit L3 handover according to its
own

As I mentioned above, MN can take the decision, if more than one subnet
information is
sent in PrRtAdv. and AR can send multiple subnet info in one PrRtAdv even in
network
initiated handover case.

Thanks & Regards,
Subba Reddy

---

From: Subba Reddy <[email-masked]>
Date: Fri, 15 Jul 2005 14:32:13 +0530

Hi Heejin Jang,

> tightly coupled with the BS-initiated handover of 802.16e.
 I agree.

---

From: "Junghoon Jee" <[email-masked]>
Date: Fri, 15 Jul 2005 18:26:38 +0900

> > Even though the L2 handoff can be initiated by AR(BS) in 
> the network 
> > side, the final decision of handoff is performed by MN by the 
> > MOB_HO-IND in the IEEE 802.16e networks.
> So, in this case also, MN can decide which network it wants 
> to associate with.
> After this step, procedure defined for predictive case in the 
> draft can be followed.

My point is that,
In IEEE 802.16e, MN can re-initiate the L2 handover when it does not want to
handover to the the proposed BS lists which is contained in MOB_BSHO-REQ.
The handover decision and control is fully assigned to MN not network side.

Regards,
Junghoon

> > BTW, in the IEEE 802.16e networks,   **MN** decides the 
> target AR(NAR)
> just
> IMHO, Since MN has to send FBU and receive FBack, it needs to 
> decide to which BS it is going to associate with.
> For this FBU, FBack exchange should happen before sending 
> MOB_HO-IND (in predictive case).
> 
> > Therefore, NAR information contained in PrRtAdv can be 
> different from 
> > the actual target AR(NAR) information decided by MN.
> >
> > I think that FMIPv6's network-initiated handover has a 
> meaning only if 
> > the handover control is fully assigned to the network side, 
> where the 
> > network can instruct MN to commit L3 handover according to its
> own
> > decision.
> 
> As I mentioned above, MN can take the decision, if more than 
> one subnet information is sent in PrRtAdv. and AR can send 
> multiple subnet info in one PrRtAdv even in network initiated 
> handover case.
> 
> Thanks & Regards,
> Subba Reddy
>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 15 Jul 2005 08:53:41 -0700

(cc'ing to netlmm mailing list)

Daniel,

-----
> James, Phil, could you let us know your view on the above ?

I have not read this draft yet, I have a long plane ride coming up next week
when I'm intending to read it, so I'll refrain from making any detailed
comment on the technical content.

In general, my technical view (and it is just my personal view, some others
involved with NETLMM might not share it) is that NETLMM and FMIP have
different roles. NETLMM is used for localized mobility management within an
lmm domain, and is responsible for taking care of updating the routing on
handover within the lmm domain. When moving between lmm domains, however,
MIP should be used to change the care of address and  FMIP can be used to
smooth handover. So I don't see any real conflict between the two.

If we manage to get a WG formed, I think one topic of discussion might be
how to handle transition between NETLMM domains, though I don't see this as
being necesarily part of the base protocol.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 15 Jul 2005 15:47:12 -0700

> I think, It (network or PAR) can decide, but it is not "MUST" to decide.

Right.

> So, in this case also, MN can decide which network it wants to associate

Yes.

>>where the network can instruct MN to commit L3 handover according to its
>>own decision.

Not quite. The network can initiate the handover process with
gratuitous PrRtAdv (and even inform the MN that connectivity
may be lost otherwise), but as mentioned above (and below by Subba 
Reddy), it can still supply multiple tuples and let the MN choose which 
NAR/NCoA to use.

This is supported by using Code=1, but by leaving out NCoA option in
PrRtAdv.

-Rajeev

---

From: "Junghoon Jee" <[email-masked]>
Date: Sat, 16 Jul 2005 16:25:25 +0900

Hi Rajeev,

> >>network can instruct MN to commit L3 handover according to its own 
> >>decision.
> 
> may be lost otherwise), but as mentioned above (and below by 
> Subba Reddy), it can still supply multiple tuples and let the 
> MN choose which NAR/NCoA to use.

I have been stating that MN can reject all of multiple tuples proposed by
the PAR in IEEE 802.16e networks.

Anyway, I would like to hear about your comment about the FMIPv6's
predictive mode in IEEE 802.16e networks.
In IEEE 802.16e networks, the target BS(AR) is decided by the MN just before
MN sends L2 MOB_HO-IND to the serving BS(PAR).
After that, any L3 communication is not possible between MN and PAR.
Therefore, to operate as FMIPv6's predictive mode, FBU/FBack transfer SHOULD
be completed before MN sends MOB_HO-IND to the PAR.
In this situation, I think that FMIPv6's predictive mode hardly happen in
IEEE 802.16e networks without delaying L2 processing from the upper layer.

Regards,
Junghoon

> This is supported by using Code=1, but by leaving out NCoA 
> option in PrRtAdv.
> 
> -Rajeev
> 
> 
> > 
> > 
> > As I mentioned above, MN can take the decision, if more than one 
> > subnet information is sent in PrRtAdv. and AR can send 
> multiple subnet 
> > info in one PrRtAdv even in network initiated handover case.
> > 
> > Thanks & Regards,
> > Subba Reddy
> > 
> >

---

From: Subba Reddy <[email-masked]>
Date: Sat, 16 Jul 2005 13:31:46 +0530

Hi Junghoon,

> the PAR in IEEE 802.16e networks.

I think above case may be rare case.
One thing PAR can do (in FMIPv6) is, it can send all the possible tuples
i.e,
all the neighborhood information.
so MN can select one of them.

Thanks & Regards,
Subba Reddy

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 18 Jul 2005 11:37:51 -0700

> the PAR in IEEE 802.16e networks.

I am curious, when the BS sends MOB_BSHO-REQ, which BS/AR does the
MN choose?

> IEEE 802.16e networks without delaying L2 processing from the upper layer.

The important thing is to send FBU before MOB_HO-IND. The MN should be 
able to leave immediately after that. When it attaches to NAR, it will 
resend FNA[FBU] if it has not received FBack, but packets may already
be waiting at NAR since FBU was sent earlier. NOTE: You need to modify
your sequence for reactive handover based on this.

So, consider being able to send FBU prior to MOB_HO-IND as the event 
that separates the two scenarios. If the very first FBU is sent from the 
new link, you may consider that as reactive handover.

Regards,

-Rajeev

---

From: Heejin Jang <[email-masked]>
Date: Tue, 19 Jul 2005 20:21:18 +0900

Hi, Rajeev.
What you mentioned is exactly what we have described in the draft. 
We seperates the case depending on whether FBU is sent and FBack is recevied before sending MOB_HO-IND. However,  sending FBU itself cannot guarantee packets will be waiting at NAR since FBU also can be lost. 

The cases are classified as follow.

1. L2 is uncontrollable. (That means MN's L2 does not allow L3 to get FBack before sending MOB_HO-IND.)
   -  FBU/FBack has been exchanged before sending MOB_HO-IND -> "predictive mode"
   -  FBU is not sent/ lost before/during sending MOB_HO-IND . -> "reactive mode"
   -  FBU is sent but FBack is lost before sending MOB_HO-IND.  -> "reactive mode" 
     (even though packets are forwarded to NAR, MN sends FNA[FBU] since it does not know whether the     
     FBU was processed or not.)   

2. L3 is controllable.  (That means MN's L2 waits L3 to get FBack before sending MOB_HO-IND.)
   -  "predictive mode"

Can it be other cases?
We'll appreciate if you can give any technical advice for our draft.

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 21 Jul 2005 11:28:40 -0700

Heejin Jang wrote:

> We seperates the case depending on whether FBU is sent and FBack is 
> recevied before sending MOB_HO-IND. 

I am saying you don't have to do that. Send FBU, send MOB_HO-IND and
leave. (If you got FBack before MOB_HO-IND, good. But, don't wait for
it).

> However,  sending FBU itself cannot 
> guarantee packets will be waiting at NAR since FBU also can be lost. 
> 

That's why you re-send FBU from the new link encapsulated in FNA.
Assuming FBU made it, then packets will be waiting or arriving. If it
didn't, then you will fall back to reactive.

Important point is that you didn't require L2 to wait for FBack.

-Rajeev

---

From: Subba Reddy <[email-masked]>
Date: Fri, 22 Jul 2005 12:28:33 +0530

Hi Heejin Jang,

> didn't, then you will fall back to reactive.

Even if MN attaches to different BS (than the one sent in FBU) also,
erroneous conditions
described in section 5.5.  (Fast or Erroneous Movement) of FMIPv6 can be
used.

Thanks & Regards,
Subba Reddy

---

From: "Junghoon Jee" <[email-masked]>
Date: Sun, 24 Jul 2005 06:19:51 -0700

Hi Rajeev,
Sorry for late response.

> I am curious, when the BS sends MOB_BSHO-REQ, which BS/AR 
> does the MN choose?

Basically, one of them which are listed in MOB_BSHO-REQ.
However, to choose one of them is not MUST in the current .16e spec.
If MN does not want to choose one of them, 
it can re-initiate the L2 handover by sending MOB_MSHO-REQ.

> The important thing is to send FBU before MOB_HO-IND. The MN 
> should be able to leave immediately after that. When it 
> attaches to NAR, it will resend FNA[FBU] if it has not 
> received FBack, but packets may already be waiting at NAR 
> since FBU was sent earlier. NOTE: You need to modify your 
> sequence for reactive handover based on this.
> 
> So, consider being able to send FBU prior to MOB_HO-IND as 
> the event that separates the two scenarios. If the very first 
> FBU is sent from the new link, you may consider that as 
> reactive handover.

Aha !
Thank you for this good comment.
Separating FMIPv6's predictive and reactive mode which is based on the
capability of receiving FBack was somewhat unclear to me.
As you said, the most important point to send FBU in the PAR.

Regards,
Junghoon

> option in

---

From: Heejin Jang <[email-masked]>
Date: Mon, 25 Jul 2005 11:45:39 +0900

Hi, Rajeev.
> Important point is that you didn't require L2 to wait for FBack.

In our draft, by default, L3 does not enforce L2 anything.
If MN can get FBack before sending MOB_HO-IND luckily, it runs reactive mode, otherwise, predictive mode. 

However, "if available", we can use that L3 command for efficiency.
Generally, it has been said that L3 cannot require L2 to wait L3's operation, at least so far. 
However, these days, there are proposals of their cooperation.
In my knowledge, section 5&6 in 802.21 standard draft (IEEE P802.21/D00.01), describe about 
this, MICS (Midia Indepedent Commend Service). Here, MIH_SWITCH is what we used  in our draft.
.
"Media independent Command service provides set of commands that enables MIH users to
issue commands to control link behavior relevant to handovers."

Regards, 
Heejin.

---

From: Heejin Jang <[email-masked]>
Date: Mon, 25 Jul 2005 14:40:34 +0900

Sorry

I replace this sentence

> If MN can get FBack before sending MOB_HO-IND luckily, it runs reactive mode, otherwise, predictive mode. 

with this.

>> If MN can get FBack before sending MOB_HO-IND luckily, it runs proactive mode, otherwise, reactive mode.