Re: [Mipshop] FMIPv6 Reactive Handover - HI/HAck

"Charles E. Perkins" <charliep@iprg.nokia.com> Tue, 23 August 2005 12:27 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7XsE-00013s-8N; Tue, 23 Aug 2005 08:27:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7XsC-00013n-Ro for mipshop@megatron.ietf.org; Tue, 23 Aug 2005 08:27:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00875 for <mipshop@ietf.org>; Tue, 23 Aug 2005 08:27:23 -0400 (EDT)
Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7XsJ-0002tL-S9 for mipshop@ietf.org; Tue, 23 Aug 2005 08:27:32 -0400
Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j7NBt1910350; Tue, 23 Aug 2005 04:55:01 -0700
X-mProtect: <200508231155> Nokia Silicon Valley Messaging Protection
Received: from hed034-190.research.nokia.com (172.21.34.190, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdjO0MEa; Tue, 23 Aug 2005 04:54:59 PDT
Message-ID: <430B160F.8060309@iprg.nokia.com>
Date: Tue, 23 Aug 2005 15:26:55 +0300
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center, Mtn. View
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Junghoon Jee <jhjee@etri.re.kr>
Subject: Re: [Mipshop] FMIPv6 Reactive Handover - HI/HAck
References: <EMAIL107XOq3JkrKdMU00005c30@email1.etri.info>
In-Reply-To: <EMAIL107XOq3JkrKdMU00005c30@email1.etri.info>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Content-Transfer-Encoding: 7bit
Cc: mipshop@ietf.org
X-BeenThere: mipshop@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mipshop.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mipshop@ietf.org>
List-Help: <mailto:mipshop-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=subscribe>
Sender: mipshop-bounces@ietf.org
Errors-To: mipshop-bounces@ietf.org

Hello Junghoon,

HI may be needed to capture packets still in flight to PAR.
This is independent of context transfer, but that reinforces
the point.

Please excuse if this answer has already been provided in
previous e-mail discussion.

Regards,
Charlie P.

Junghoon Jee wrote:

> Hi Vidya,
> I made the same question through DNA WG recently regarding FMIP-DNA I-D.
> You can find the previous discussion through the attached message.
> I am still questioning why HI/HAck for the access control is required 
> after MN has already attached to NAR in the reactive case.
> Junghoon
>> -----Original Message-----
>> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
>> Sent: Tuesday, July 19, 2005 8:46 AM
>> To: Junghoon Jee
>> Cc: 'Syam Madanapalli'; dna@eng.monash.edu.au 
> <mailto:dna@eng.monash.edu.au>; smadanapalli@gmail.com 
> <mailto:smadanapalli@gmail.com>
>> Subject: Re: [DNA] draft-koodli-dna-fmip-00.txt
>>
>>
>>
>>
>> Junghoon Jee wrote:
>>
>> > Rajeev,
>> >
>> >
>> >>For both predictive and reactive modes, HI/HAck can be useful for
>> >>access control. NAR can forward packets for the MN without forcing
>> >>access control, through HI/HAck.
>> >
>>
>> One could use HI/HAck for CT, but I am not referring to that.
>>
>> When FBU processing is successful, PAR's message (HI) to NAR
>> can allow NAR to "validate" the ND cache entry for NCoA.
>> No Context Transfer is involved. The fields in HI (PCoA, NCoA,
>> LLA) are sufficient for the purpose.
>>
>> -Rajeev
>>
>>
>>
>>
>>
>> >
>> > Are you saying about context transfer by HI/HAck ?
>> >
>> > Regards,
>> > Junghoon
>> >
>> >
>> >>(If it is not clear, FMIP-DNA is applicable when DNA+oDAD is
>> >>available,
>> >> and no neighborhood information is available for FMIP)
>> >>
>> >>-Rajeev
>> >>
>> >>
>> >>
>> >>Syam Madanapalli wrote:
>> >>
>> >>
>> >>>Hello Junghoon,
>> >>>
>> >>>Thanks for reviewing the draft.
>> >>>
>> >>>
>> >>>>Hi Syam,
>> >>>>It's an interesting work.
>> >>>>After reviewing this I-D, I've come up with a following question.
>> >>>>
>> >>>>About the role of HI/HACK in this reactive FMIPv6-DNA :
>> >>>>I thought that these messages are required to confirm the MN's
>> >>>>prospective NCoA in predictive mode.
>> >>>>In the FMIPv6-DNA, MN configures the NCoA by optimistic
>> DAD in the
>> >>>>reactive mode, so why do those messages needed to be
>> >>
>> >>transferred and
>> >>
>> >>>>what's their roles ?
>> >>>>Just to prepare for future optional behavior the same as
>> >>
>> >>specified in
>> >>
>> >>>>the draft-ietf-mipshop-fast-mipv6-03 ?
>> >>>>I guess that my question may also apply to the reactive mode of
>> >>>>draft-ietf-mipshop-fast-mipv6-03.
>> >>>
>> >>>
>> >>>As you mentioned, currently there is no new use of HI/HACK
>> >>
>> >>other than
>> >>
>> >>>what is mentioned in FMIPv6 RFC. That is, NAR can make use of the
>> >>>knowledge that its trusted peer (i.e., PAR) has a trust
>> >>
>> >>relationship
>> >>
>> >>>with the
>> >>>MN.
>> >>>
>> >>>
>> >>>
>> >>>>Regards,
>> >>>>Junghoon
>> >>>>
>> >>>
>> >
>>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Mipshop mailing list
>Mipshop@ietf.org
>https://www1.ietf.org/mailman/listinfo/mipshop
>  
>



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