Subject: Re: [Mipshop] Re: [16NG] FW: Call for Review on FMIP6 over IEEE 802.16e Networks

From: Heejin Jang <[email-masked]>
Date: Mon, 04 Jun 2007 04:44:14 +0000 (GMT)

Hi, Frank & Daniel.
 
RFC4068 describes fast HO procedure based on prediction, including NCoA formulation in advance.
However, how to allocate the prefix to MN in NAR (before actual HO) is out of scope in this document
as mentioned in Section 4. 
 
"The method by which Access Routers exchange information about their neighbors, and thereby allow 
  construction of Proxy Router  Advertisements with information about neighboring subnets is outside
  the scope of this document."
 
Furthermore, the problem you mentioned in draft-xia-mipshop-fmip-ptp-00 is not limited only to 802.16 networks
but happens all networks which have point-to-point link such as 3GPP2.
I think that it is proper to handle this problem separately.
 
Thanks for your opinion.
 
- Regards, 
Heejin

------- Original Message -------
Sender : Frank Xia<[email-masked]>
Date   : 2007-06-01 06:50
Title  : [Mipshop] Re: [16NG] FW: Call for Review on FMIP6 over IEEE 802.16e	Networks

Hi Daniel

Here is my two cents.

The draft is based on RFC4068, and point-to-point link model is also recommended .
RFC4068 is based on shared link model, and is not applicable for point-to-point link model without modification.
So,  there are some basic conflicts in the draft.

Formulation of  a prospective NCoA  is a main idea of  RFC4068. 
But in Point-to-Point link model, it is impossible to formulate the NCoA 
according to  RFC4068 because there is no proper prefix.

BR
Frank

----- Original Message ----- 
From: "Daniel Park" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, May 27, 2007 9:34 PM
Subject: [16NG] FW: Call for Review on FMIP6 over IEEE 802.16e Networks

> To MIPSHOP WG, 
> 
> Here is another expert review on "draft-ietf-mipshop-fh80216e-01",
> particularly, IEEE 802.21 relevant texts in this draft.
> 
> Reviewer (Yoshihiro Ohba) is a IETF official liaison from IEEE 802.21
> 
> Thanks Yoshihiro and hope this helps...
> 
> 
> ----
> 
> Daniel Park & Gabriel Montenegro
> Chairs, 16NG Working Group
> 

--------------------------------------------------------------------------------

> _______________________________________________
> 16NG mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/16ng
> 

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

_______________________________________________
16NG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng

---

From: Frank Xia <[email-masked]>
Date: Mon, 04 Jun 2007 13:29:03 -0500

Re: [Mipshop] Re: [16NG] FW: Call for Review on FMIP6 over IEEE802.16e NetworksHi Rajeev 

I just picked some texts from 4068bis.

Could you make it clear when when P-to-P link is applied?

1 "(AP-ID, AR-Info) tuple Contains an access router's L2 and IP addresses, and
  prefix valid on the interface to which the Access Point (identified by AP-ID) is attached.  
 The triplet [Router's  L2 address, Router's IP address and Prefix] is called "AR-Info"".

=> Here, prefix is AR's physical interface prefix is used for NCoA formulation.
  As you know, this prefix is useless for P-to-P link model.

2 " Through the RtSolPr and PrRtAdv messages, the MN also formulates a
    prospective new CoA (NCoA), when it is still present on the PAR's
    link.  Hence, the latency due to new prefix discovery subsequent to
    handover is eliminated.  Furthermore, this prospective address can
    be used immediately after attaching to the new subnet link (i.e.,
    NAR's link) when the MN has received a "Fast Binding Acknowledgment
    (FBack)" message prior to its movement.  In the event it moves
    without receiving an FBack, the MN can still start using NCoA
    after announcing its attachment through an unsolicited Neighbor
    Advertisement message (with the 'O' bit set to zero) message [8];
    NAR responds to to this UNA message in case the tentative address is
    already in use.  In this way, NCoA configuration latency is reduced"
=>is it meaningful for P-to-P?

...

In fact any parts related to the prefix is not proper for p-to-p link model.

BTW, From my understanding, your propsal is that the only way for MN getting it's CoA
MUST be requesting it from NAR for P-to-P link.

BR
Frank

  ----- Original Message ----- 
  From: Rajeev Koodli 
  To: [email-masked] ; Frank Xia 
  Cc: [email-masked] ; [email-masked] ; ??? 
  Sent: Monday, June 04, 2007 12:56 PM
  Subject: Re: [Mipshop] Re: [16NG] FW: Call for Review on FMIP6 over IEEE802.16e Networks

  As far as I see, there is no problem here!

  It does not matter what you call the prefix advertised in PrRtAdv. RFC 4068 does not make assumptions about how the prefixes are assigned and managed on an AR's link. So, it is inaccurate to say as such in draft-xia-mipshop-fmip-ptp-00.txt. 

  So, if prefix A is advertised in PrRtAdv, and a MN formulates a prospective address IP-A and sends FBU, IP-A can be overridden by NAR in HAck.

  Section 6.2.2

                Code        3: Handover Accepted, NCoA assigned
                               (used in Assigned addressing)

  The supplied NCoA is provided in FBack or NAACK option.

  This is the way I understood the problem and the solution for ptp links.

  What am I missing?

  -Rajeev

  On 6/3/07 9:44 PM, "ext Heejin Jang" <[email-masked]> wrote:

    Hi, Frank & Daniel.

    Thanks for your opinion.

    - Regards,
    Heejin

    ------- Original Message -------

    Hi Daniel

    Here is my two cents.

    BR
    Frank

    ----- Original Message -----
    From: "Daniel Park" <[email-masked]>
    To: <[email-masked]>
    Cc: <[email-masked]>
    Sent: Sunday, May 27, 2007 9:34 PM
    Subject: [16NG] FW: Call for Review on FMIP6 over IEEE 802.16e Networks

  -- 
  http://people.nokia.net/~rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 04 Jun 2007 10:56:46 -0700

It does not matter what you call the prefix advertised in PrRtAdv. RFC 4068
does not make assumptions about how the prefixes are assigned and managed on
an AR¹s link. So, it is inaccurate to say as such in
draft-xia-mipshop-fmip-ptp-00.txt.

So, if prefix A is advertised in PrRtAdv, and a MN formulates a prospective
address IP-A and sends FBU, IP-A can be overridden by NAR in HAck.

Section 6.2.2

What am I missing?

-Rajeev

On 6/3/07 9:44 PM, "ext Heejin Jang" <[email-masked]> wrote:

> RFC4068 is based on shared link model, and is not applicable for
> point-to-point link model without modification.

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 04 Jun 2007 12:39:51 -0700

HI Frank,

On 6/4/07 11:29 AM, "ext Frank Xia" <[email-masked]> wrote:
> Rajeev:> you could interpret it that way, but you don¹t have to. The point I
> am trying to make is that the current model works for the scenario you are
> enumerating.
> 
> An AR may use per-mobile prefix and an aggregate prefix on the interface. As I
> said, aggregate prefix could be what is advertised in PrRtAdv. The MN can
> formulate a prospective NCoA using that, but receive a different NCoA from
> NAR, based on the per-mobile prefix.
>  
> I can imagine other ways to manage the prefix.
> 
> 
> Rajeev:> If your question is will it work with per-mobile prefix, yes. Either
> FBack or NAACK can provide the NCoA that the NAR wants the MN to use.
> 
> ...
>  
> Rajeev:> That¹s a pretty broad statement. You should separate prefix
> management from the address formulation. If an address is formulated using an
> aggregate prefix (which NAR exchanges with PAR), then that address can be
> overridden from the NAR using a per-mobile prefix. RFC 4068 provides means to
> do this. 
> 
>  
> Rajeev:> I am just pointing out how the current model in 4068 can work for
> your scenario. 
> 
> -Rajeev
> 
>  
>  
> BR
> Frank
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>>  
>> From:  Rajeev  Koodli <mailto:[email-masked]>
>>  
>> To: [email-masked] ; Frank  Xia <mailto:[email-masked]>
>>  
>> Cc: [email-masked] ; [email-masked] ; ??? <mailto:[email-masked]>
>>

---

From: Frank Xia <[email-masked]>
Date: Mon, 04 Jun 2007 15:40:19 -0500

I am a little bit confused with you explanation.

Please see my inline comments.

BR
Frank
  ----- Original Message ----- 
  From: Rajeev Koodli 
  To: ext Frank Xia ; [email-masked] 
  Cc: [email-masked] ; [email-masked] ; ??? 
  Sent: Monday, June 04, 2007 2:39 PM
  Subject: Re: [Mipshop] Re: [16NG] FW: Call for Review on FMIP6 over IEEE802.16e Networks

  HI Frank,

     

    Rajeev:> you could interpret it that way, but you don't have to. The point I am trying to make is that the current model works for the scenario you are enumerating.

    Frank=> don't you think the concept of the perfix is too flexible that different people can have their own different understanding?  In your draft, the prefix is definitely the prefix of AR physical interface. I think there is not ambiguous.

    An AR may use per-mobile prefix and an aggregate prefix on the interface. As I said, aggregate prefix could be what is advertised in PrRtAdv. The MN can formulate a prospective NCoA using that, but receive a different NCoA from NAR, based on the per-mobile prefix. 
    Frank =>In fact,  this is not big different from our propsoal in draft-xia-mipshop-fmip-ptp-00 

    I can imagine other ways to manage the prefix. 
    Frank => I  also have a revised document which elaborating other alternatives, and we can cooperate .

    Rajeev:> If your question is will it work with per-mobile prefix, yes. Either FBack or NAACK can provide the NCoA that the NAR wants the MN to use. 

    Frank => The exchange of RtSolPr and PrRtAdv is to formulate a new CoA while is useless in p-t-p model.  It is a waste of air interface resource.
    ...

    Rajeev:> That's a pretty broad statement. You should separate prefix management from the address formulation. If an address is formulated using an aggregate prefix (which NAR exchanges with PAR), then that address can be overridden from the NAR using a per-mobile prefix. RFC 4068 provides means to do this. 

    Rajeev:> I am just pointing out how the current model in 4068 can work for your scenario. 

    Frank => P-to-P scenario is adopted by WiMAX/3GPP2, while I have little idea about promising deployment of shared link model.
    IMHO, your simplified proposal can't solve the proplem very well.

    -Rajeev

    BR
    Frank

     

     

      ----- Original Message ----- 

       

      Section  6.2.2

      What am I missing?

      -Rajeev

        Hi, Frank & Daniel.

        Thanks for your opinion.

        -  Regards,
        Heejin

        ------- Original Message -------

        Hi Daniel

        Here is  my two cents.

        BR
        Frank

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 04 Jun 2007 14:08:36 -0700

Hi Frank,

May be we are going in circles here.. I have not seen why the current model
cannot work for the scenario you have in mind. If there is an issue, the WG
process is to bring it up and propose text. It¹s more productive that way. I
am willing to clarify in the bis version. Some more replies below..
 
>>> Rajeev:> you could interpret it  that way, but you don¹t have to. The point
>>> I am trying to make is that the  current model works for the scenario you
>>> are enumerating.
>>>  
>>> Frank=> don't you think the concept of the  perfix is too flexible that
>>> different people can have their own different  understanding?  In your
>>> draft, the prefix is definitely the prefix of  AR physical interface. I
>>> think there is not ambiguous.
>>> 
>>> Rajeev/2/:> First, it is not my draft; it is the WG document. Second, it is
>>> not clear to me why you would equate the prefix to physical interface. 4068
>>> only says it is the prefix valid on the interface the MN is attaching to,
>>> and I am unable to see what¹s the problem.
>>> 
>>> If you are trying to map it to ptp model, that¹s fine. But, please don¹t
>>> make assumptions which not intended, nor are necessary.
>>>  
>>>  
>>> An AR may use per-mobile prefix and an aggregate prefix on the  interface.
>>> As I said, aggregate prefix could be what is advertised in  PrRtAdv. The MN
>>> can formulate a prospective NCoA using that, but receive a  different NCoA
>>> from NAR, based on the per-mobile prefix.
>>>  
>>> Rajeev:/2/> I am not proposing a new model above. Just showing how the
>>> existing model can be used.
>>> 
>>> Rajeev:> If your question is will it work with per-mobile  prefix, yes.
>>> Either FBack or NAACK can provide the NCoA that the NAR wants  the MN to
>>> use. 
>>>    
>>> Frank => The exchange of RtSolPr and PrRtAdv is to formulate a new CoA while
>>> is useless  in p-t-p model.  It is a waste of air interface  resource.
>>> 
>>> Rajeev:/2/> That¹s debatable, and is up to each technology that implements
>>> FMIP. 
>>>  
>>>  
>>> Frank => P-to-P scenario is adopted by  WiMAX/3GPP2, while I have little
>>> idea about promising  deployment of shared link model.
>>> 
>>> Rajeev:/2/> Good.  RFC 4068 is not about shared link only. It¹s your
>>> interpretation.
>>>  
>                Rajeev:/2/> You have not shown why my explanation on how the
> current model can work will not  work. As I suggested earlier, if there is any
> specific issue that needs to be addressed, it is productive to propose the
> issue and text. 
> 
> -Rajeev
> 
>>  
>>