Re: [Seamoby] DoCoMo Implementation Issues with CTP

"Raghu" <dendukuri@docomolabs-usa.com> Fri, 20 February 2004 18:48 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06377 for <seamoby-archive@odin.ietf.org>; Fri, 20 Feb 2004 13:48:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFgy-0003E1-HW for seamoby-archive@odin.ietf.org; Fri, 20 Feb 2004 13:48:04 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KIm42f012391 for seamoby-archive@odin.ietf.org; Fri, 20 Feb 2004 13:48:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFgy-0003Dm-EO for seamoby-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 13:48:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06337 for <seamoby-web-archive@ietf.org>; Fri, 20 Feb 2004 13:48:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuFgw-0007Gb-00 for seamoby-web-archive@ietf.org; Fri, 20 Feb 2004 13:48:02 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuFfy-0007Ce-00 for seamoby-web-archive@ietf.org; Fri, 20 Feb 2004 13:47:03 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuFez-00078H-00 for seamoby-web-archive@ietf.org; Fri, 20 Feb 2004 13:46:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFf0-00033K-Rk; Fri, 20 Feb 2004 13:46:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFeK-00030N-J3 for seamoby@optimus.ietf.org; Fri, 20 Feb 2004 13:45:20 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06262 for <seamoby@ietf.org>; Fri, 20 Feb 2004 13:45:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuFeI-00075v-00 for seamoby@ietf.org; Fri, 20 Feb 2004 13:45:18 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuFdG-000723-00 for seamoby@ietf.org; Fri, 20 Feb 2004 13:44:15 -0500
Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AuFcm-0006yZ-00 for seamoby@ietf.org; Fri, 20 Feb 2004 13:43:44 -0500
Message-ID: <02cc01c3f7e1$49b31040$1c6015ac@dcldendukuri>
From: Raghu <dendukuri@docomolabs-usa.com>
To: seamoby@ietf.org
References: <059c01c3f5a4$63e9e360$936015ac@dclkempt40> <40341585.127EE1A7@iprg.nokia.com> <023601c3f744$49c01df0$1c6015ac@dcldendukuri> <40355C74.22D0A058@iprg.nokia.com> <024601c3f750$0902ab00$1c6015ac@dcldendukuri> <40356445.C6D3270@iprg.nokia.com> <02 <40364EC3.621890A@iprg.nokia.com>
Subject: Re: [Seamoby] DoCoMo Implementation Issues with CTP
Date: Fri, 20 Feb 2004 10:42:27 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>, <mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>, <mailto:seamoby-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> The intended reason for including PAR's IP address in CTAR is
> to allow NAR to construct CTREQ and send it to PAR.
> 
okay.


> When PCTD takes place, there is no reason to do CTREQ.
>
Right.


> (Also, note that you could not match contexts using PAR's IP
> address since that could yield many contexts corresponding to
> multiple MNs.)
> 
I was also under impression that both (PAR IP & MN IP) 
from CTAR & PCTD must match before verifying the token.
Otherwise how can nAR determine from 
which pAR a MN is comming from ? 


> The token calculation does not include PAR's address. It
> only includes MN's previous address (note: when V is 10 in
> CTAR, the token should include both the IP addresses).
> Since the MN includes both its addresses and NAR has
> contexts for both of those addresses, they can be matched.
> The token calculation on NAR is also done in a similar way
> as in the MN; PAR's address is not a parameter in computing
> the token.
> 
> Is this better ?
> 
Yes.


> MN includes the PAR's address in CTAR. NAR should use that
> address in the Dest field of CTREQ.
> Perhaps we should state that the MN should only include the
> IPv4 address of PAR (NAR).
> 
It helps.

regards,
Raghu

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby