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

Frank Xia <xiayangsong@huawei.com> Mon, 04 June 2007 18:28 UTC

Return-path: <16ng-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvHHf-0001xP-14; Mon, 04 Jun 2007 14:28:03 -0400
Received: from 16ng by megatron.ietf.org with local (Exim 4.43) id 1HvHHc-0001xE-W5 for 16ng-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 14:28:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvHHc-0001x6-MM; Mon, 04 Jun 2007 14:28:00 -0400
Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvHHa-0006y5-2l; Mon, 04 Jun 2007 14:28:00 -0400
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJ400GVQJ9LY8@szxga03-in.huawei.com>; Tue, 05 Jun 2007 02:27:21 +0800 (CST)
Received: from ny3104051930 ([10.124.12.56]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJ400JV3J9DS6@szxga03-in.huawei.com>; Tue, 05 Jun 2007 02:27:21 +0800 (CST)
Date: Mon, 04 Jun 2007 13:29:03 -0500
From: Frank Xia <xiayangsong@huawei.com>
Subject: Re: [Mipshop] Re: [16NG] FW: Call for Review on FMIP6 over IEEE802.16e Networks
To: Rajeev Koodli <rajeev.koodli@nokia.com>, heejin.jang@samsung.com
Message-id: <004501c7a6d6$3c168730$380c7c0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-Priority: 3
X-MSMail-priority: Normal
References: <C289A06E.12142%rajeev.koodli@nokia.com>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 1df8e4abc9851cb4adb45bd64d8514ae
Cc: mipshop@ietf.org, 16ng@ietf.org
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0533060900=="
Errors-To: 16ng-bounces@ietf.org

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: heejin.jang@samsung.com ; Frank Xia 
  Cc: mipshop@ietf.org ; 16ng@ietf.org ; ??? 
  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" <heejin.jang@samsung.com> 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<xiayangsong@huawei.com>
    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" <soohong.park@samsung.com>
    To: <mipshop@ietf.org>
    Cc: <16ng@ietf.org>
    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
    > 16NG@ietf.org
    > https://www1.ietf.org/mailman/listinfo/16ng
    >

    _______________________________________________
    Mipshop mailing list
    Mipshop@ietf.org
    https://www1.ietf.org/mailman/listinfo/mipshop






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


_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng