Re: [Seamoby] DoCoMo Implementation Issues with CTP

Rajeev Koodli <rajeev@iprg.nokia.com> Fri, 20 February 2004 01:06 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 UAA08673 for <seamoby-archive@odin.ietf.org>; Thu, 19 Feb 2004 20:06:04 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atz6m-00012P-89 for seamoby-archive@odin.ietf.org; Thu, 19 Feb 2004 20:05:36 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K15apH003983 for seamoby-archive@odin.ietf.org; Thu, 19 Feb 2004 20:05:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atz6m-000128-4E for seamoby-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 20:05:36 -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 UAA08665 for <seamoby-web-archive@ietf.org>; Thu, 19 Feb 2004 20:05:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atz6k-0001r2-00 for seamoby-web-archive@ietf.org; Thu, 19 Feb 2004 20:05:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atz5w-0001nh-00 for seamoby-web-archive@ietf.org; Thu, 19 Feb 2004 20:04:45 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atz5F-0001jV-00 for seamoby-web-archive@ietf.org; Thu, 19 Feb 2004 20:04:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atz5F-0000t6-Vm; Thu, 19 Feb 2004 20:04:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atz54-0000sl-D7 for seamoby@optimus.ietf.org; Thu, 19 Feb 2004 20:03:50 -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 UAA08592 for <seamoby@ietf.org>; Thu, 19 Feb 2004 20:03:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atz52-0001ij-00 for seamoby@ietf.org; Thu, 19 Feb 2004 20:03:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atz45-0001e4-00 for seamoby@ietf.org; Thu, 19 Feb 2004 20:02:50 -0500
Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Atz3f-0001Yd-00 for seamoby@ietf.org; Thu, 19 Feb 2004 20:02:24 -0500
Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1K11qj01626; Thu, 19 Feb 2004 17:01:52 -0800
X-mProtect: <200402200101> Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNoXZhw; Thu, 19 Feb 2004 17:01:50 PST
Message-ID: <40355C74.22D0A058@iprg.nokia.com>
Date: Thu, 19 Feb 2004 17:01:40 -0800
From: Rajeev Koodli <rajeev@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Raghu <dendukuri@docomolabs-usa.com>
CC: James Kempf <kempf@docomolabs-usa.com>, seamoby@ietf.org
Subject: Re: [Seamoby] DoCoMo Implementation Issues with CTP
References: <059c01c3f5a4$63e9e360$936015ac@dclkempt40> <40341585.127EE1A7@iprg.nokia.com> <023601c3f744$49c01df0$1c6015ac@dcldendukuri>
Content-Type: text/plain; charset="us-ascii"
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.4 required=5.0 tests=AWL 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).

Length field increase (below) is okay.

-Rajeev


>
> > - Isn't MTU a consideration in increasing the size of the
> >     Length field to 16 bits ?
> >
>
> Since CTP is an application layer program, I guess
> supporting upto 16bits is more reasonable for the
> following reasons
> 1. UDP supports upto 16bits
> 2. As more Feature profiles are defined more
>     contexts in the same CTP needs to be transferred.
>
> As per the sections 2.4 & 2.5 in the draft
> "message length in units of 8", Padding bytes
>  are required for both CDB & CT Messages.
> These padding bytes get critical when we are
> reaching the maximum size ie 2048 bytes.
>


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