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

[Frank Xia <[e-mail]>]

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


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 ; [e-mail] 
  Cc: [e-mail] ; [e-mail] ; ??? 
  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,


  On 6/4/07 11:29 AM, "ext Frank Xia" <[e-mail]> wrote:


    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.

    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 .



    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?

    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.
    ...
     
    In fact any parts related to the prefix is not proper for p-to-p link model.
     
    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. 

     
    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.
     
    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 ----- 
       
      From:  Rajeev  Koodli <mailto:[e-mail]>  
       
      To: [e-mail] ; Frank  Xia <mailto:[e-mail]>  
       
      Cc: [e-mail] ; [e-mail] ; ??? <mailto:[e-mail]>   
       
      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" <[e-mail]>  wrote:

       

        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<[e-mail]>
        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" <[e-mail]>
        To:  <[e-mail]>
        Cc: <[e-mail]>
        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
        > [e-mail]
        >  https://www1.ietf.org/mailman/listinfo/16ng
        >

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






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







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

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