Re: [Seamoby] DoCoMo Implementation Issues with CTP
"Raghu" <dendukuri@docomolabs-usa.com> Fri, 20 February 2004 01:28 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 UAA09738 for <seamoby-archive@odin.ietf.org>; Thu, 19 Feb 2004 20:28:14 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtzSE-0002o6-HK for seamoby-archive@odin.ietf.org; Thu, 19 Feb 2004 20:27:46 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K1RkKu010784 for seamoby-archive@odin.ietf.org; Thu, 19 Feb 2004 20:27:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtzSE-0002nr-EA for seamoby-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 20:27:46 -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 UAA09717 for <seamoby-web-archive@ietf.org>; Thu, 19 Feb 2004 20:27:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtzSC-0003bG-00 for seamoby-web-archive@ietf.org; Thu, 19 Feb 2004 20:27:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtzRC-0003XJ-00 for seamoby-web-archive@ietf.org; Thu, 19 Feb 2004 20:26:42 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtzQX-0003Tf-00 for seamoby-web-archive@ietf.org; Thu, 19 Feb 2004 20:26:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtzQZ-0002g1-0q; Thu, 19 Feb 2004 20:26:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtzQ7-0002eY-Tt for seamoby@optimus.ietf.org; Thu, 19 Feb 2004 20:25:35 -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 UAA09615 for <seamoby@ietf.org>; Thu, 19 Feb 2004 20:25:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtzQ5-0003RA-00 for seamoby@ietf.org; Thu, 19 Feb 2004 20:25:33 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtzP9-0003Nh-00 for seamoby@ietf.org; Thu, 19 Feb 2004 20:24:35 -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 1AtzOW-0003KU-00 for seamoby@ietf.org; Thu, 19 Feb 2004 20:23:56 -0500
Message-ID: <024601c3f750$0902ab00$1c6015ac@dcldendukuri>
From: Raghu <dendukuri@docomolabs-usa.com>
To: Rajeev Koodli <rajeev@iprg.nokia.com>
Cc: seamoby@ietf.org
References: <059c01c3f5a4$63e9e360$936015ac@dclkempt40> <40341585.127EE1A7@iprg.nokia.com> <023601c3f744$49c01df0$1c6015ac@dcldendukuri> <40355C74.22D0A058@iprg.nokia.com>
Subject: Re: [Seamoby] DoCoMo Implementation Issues with CTP
Date: Thu, 19 Feb 2004 17:22:41 -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
> > Hello Raghu, > > > Raghu wrote: > > > > > > > - When both IPv4 and IPv6 addresses are used in CTD, > > > "Processing the address of the opposite > > > version in the stack is complicated. " Could you elaborate on > > > this ? I can see that once IP (v4 or v6) stack demultiplexes the > > > packet to belong to a CTP client, it would just forward the block > > > to a CTP module (a daemon for instance), which could then > > > process contexts associated with both the addresses. > > > > > IP Version flag in the draft indicates whether the IP Version > > can be either IPv4 or IPv6 or both(IPv4 & IPv6). > > When MN is assigned both IPv4 & IPv6 addresses, > > it is assumed that AR also has both IPv4 & IPv6 addresses. > > When MN moves, sending two CT messages for the same MN > > is unnecessary. Hence to avoid this, either IP version flag > > > > hmm.. This is perhaps a misunderstanding. > The `V' bits indicate whether contexts corresponding to > both IPv4 and IPv6 addresses (as well as the addresses > themselves) are present. The (P)CTD message itself > can be either IPv4 or IPv6. You may observe that the > Source and Destination IP addresses for all the messages > are absent. I cannot say this is intentional, but the result is > that the messages themselves can be carried in IPv4 or IPv6 > packets. > > > > should not support both IPv4 & IPv6 at the same time or > > the draft should mention, which IP version to take precedence. > > > > Hopefully, the above explanation clarifies..(i.e., IP version of > the packets carrying CTP messages is independent of the > `V' bits). > I understand your point, but I request you to explain how the implementation should be in the following scenario ? When MN moves, MN sends CTAR to nAR, nAR needs to extract IP information from CTAR and send a CTREQ to oAR. When both(IPv4 & IPv6) are present in CTAR, What is the behaviour of nAR ? regards, Raghu _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby
- [Seamoby] DoCoMo Implementation Issues with CTP James Kempf
- RE: [Seamoby] DoCoMo Implementation Issues with C… john.loughney
- Re: [Seamoby] DoCoMo Implementation Issues with C… Rajeev Koodli
- Re: [Seamoby] DoCoMo Implementation Issues with C… Raghu
- Re: [Seamoby] DoCoMo Implementation Issues with C… Rajeev Koodli
- Re: [Seamoby] DoCoMo Implementation Issues with C… Raghu
- Re: [Seamoby] DoCoMo Implementation Issues with C… Rajeev Koodli
- Re: [Seamoby] DoCoMo Implementation Issues with C… Raghu
- Re: [Seamoby] DoCoMo Implementation Issues with C… Rajeev Koodli
- Re: [Seamoby] DoCoMo Implementation Issues with C… Raghu
- RE: [Seamoby] DoCoMo Implementation Issues with C… Soliman Hesham
- Re: [Seamoby] DoCoMo Implementation Issues with C… Raghu
- RE: [Seamoby] DoCoMo Implementation Issues with C… Soliman Hesham
- Re: [Seamoby] DoCoMo Implementation Issues with C… James Kempf
- Re: [Seamoby] DoCoMo Implementation Issues with C… James Kempf
- Re: [Seamoby] DoCoMo Implementation Issues with C… James Kempf
- Re: [Seamoby] DoCoMo Implementation Issues with C… Rajeev Koodli
- Re: [Seamoby] DoCoMo Implementation Issues with C… Raghu
- Re: [Seamoby] DoCoMo Implementation Issues with C… Rajeev Koodli
- Re: [Seamoby] DoCoMo Implementation Issues with C… Rajeev Koodli
- Re: [Seamoby] DoCoMo Implementation Issues with C… Raghu
- Re: [Seamoby] DoCoMo Implementation Issues with C… Rajeev Koodli
- Re: [Seamoby] DoCoMo Implementation Issues with C… Raghu
- Re: [Seamoby] DoCoMo Implementation Issues with C… Rajeev Koodli
- Re: [Seamoby] DoCoMo Implementation Issues with C… Raghu
- Re: [Seamoby] DoCoMo Implementation Issues with C… James Kempf
- Re: [Seamoby] DoCoMo Implementation Issues with C… Rajeev Koodli
- Re: [Seamoby] DoCoMo Implementation Issues with C… James Kempf