Re: [Seamoby] DoCoMo Implementation Issues with CTP
"Raghu" <dendukuri@docomolabs-usa.com> Fri, 20 February 2004 00:05 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 TAA05191 for <seamoby-archive@odin.ietf.org>; Thu, 19 Feb 2004 19:05:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyA4-00040q-Ct for seamoby-archive@odin.ietf.org; Thu, 19 Feb 2004 19:04:56 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K04uL2015420 for seamoby-archive@odin.ietf.org; Thu, 19 Feb 2004 19:04:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyA4-00040c-8N for seamoby-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 19:04:56 -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 TAA05181 for <seamoby-web-archive@ietf.org>; Thu, 19 Feb 2004 19:04:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtyA0-00052F-00 for seamoby-web-archive@ietf.org; Thu, 19 Feb 2004 19:04:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aty9A-0004wC-00 for seamoby-web-archive@ietf.org; Thu, 19 Feb 2004 19:04:01 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aty8J-0004m5-00 for seamoby-web-archive@ietf.org; Thu, 19 Feb 2004 19:03:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aty8G-0003nE-4r; Thu, 19 Feb 2004 19:03:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aty7p-0003eB-Pp for seamoby@optimus.ietf.org; Thu, 19 Feb 2004 19:02:37 -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 TAA04881 for <seamoby@ietf.org>; Thu, 19 Feb 2004 19:02:32 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aty7m-0004i1-00 for seamoby@ietf.org; Thu, 19 Feb 2004 19:02:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aty6H-0004RN-00 for seamoby@ietf.org; Thu, 19 Feb 2004 19:01:02 -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 1Aty59-0004G5-00 for seamoby@ietf.org; Thu, 19 Feb 2004 18:59:51 -0500
Message-ID: <023601c3f744$49c01df0$1c6015ac@dcldendukuri>
From: Raghu <dendukuri@docomolabs-usa.com>
To: Rajeev Koodli <rajeev@iprg.nokia.com>, James Kempf <kempf@docomolabs-usa.com>
Cc: seamoby@ietf.org
References: <059c01c3f5a4$63e9e360$936015ac@dclkempt40> <40341585.127EE1A7@iprg.nokia.com>
Subject: Re: [Seamoby] DoCoMo Implementation Issues with CTP
Date: Thu, 19 Feb 2004 15:58:34 -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
Hi Rajeev, Please find my comments below regards, Raghu > > Jim, > > the suggested changes are okay. I am curious about couple > of suggestions however.. > > - 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 should not support both IPv4 & IPv6 at the same time or the draft should mention, which IP version to take precedence. > - 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. > Thanks, > > -Rajeev > > > James Kempf wrote: > > > DoCoMo is in the process of implementing CTP, and we came up with the > > following list of issues in the spec. Since none of them seem particularly > > large, Allison suggested that we simply update the current version of the > > document (which is now under review by the ROHC WG) in place, without reving > > the document to a new version. She will make the changes. > > Below, a list of the issues and suggested changes to the document to address > > them. > > > > Any comments? Please let me know by March 6. > > > > jak > > > > ------------------------------------------- > > > > 1) Section 2.5.1, pg. 10; Section 2.5.2, pg. 11; Section 2.5.3, pg. 12; > > Section 2.5.4, pg. 13; Section 2.5.6, pg. 15 - 'V' flag > > > > The spec allows CTP messages to carry both IPv4 and IPv6 addresses, but as a > > practical matter in the implementation, a CTP message will be sent to the > > IPv4 or IPv6 address of a router. Processing the address of the opposite > > version in the stack is complicated. Suggestion is to only allow IPv4 or > > IPv6 addresses, but keep the flag field size at 2 bits in case further > > experience shows that there are reasons why both might be sent. The router > > can issue separate messages if both addresses must be changed, Suggested > > change in text: > > > > Replace: "When set to '10', indicate presence of both IPv6 and IPv4 Previous > > (New) addresses." > > With: "Values of '10' and '11' are reserved". > > > > 2) Section 2.5.3, pg. 12 - Length of Algorithm field in CTD message block. > > > > The length of the algorithm field in the CTD message block is shown as 17 > > bits. It should be 16. > > > > 3) Section 2.5.1, pg. 10; Section 2.5.2, pg. 11; Section 2.5.3, pg. 12; > > Section 2.5.4, pg. 13; Section 2.5.6, pg. 15 - Length field. > > > > The size of the message length field is currently 8 bits, and the units for > > the length are in 8 octet words. This allows a maximum of 2048 octets, which > > might not be enough for bundling large amounts of context if padding is > > required. Suggestion is to increase the size of the field and make it be > > units of octets, for a total of 65535 octets. This would only involve moving > > the flags into the Reserved field, and would not otherwise modify the > > message. > > > > Replace: In message diagram blocks, move Length to be 16 bits rather than 8. > > > > Replace: "Length message length in units of 8 octet words" > > With: "Length message length in units of octets" > > > > 4) Section 2.5.1. pg. 9; Section 2.5.2, pg. 11; Section 2.5.3, pg. 12; > > Section 2.5.4, pg. 13; Section 2.5.5, pg. 14; Section 2.4.6, pg. 15 - IP > > address field size. > > > > The message block diagrams show the size of the IP address fields as 4 > > octets, but if the IP address is for IPv6, it will be 16. > > > > Replace: In the message block diagrams, replace the final "|" with a "~" to > > indicate a variable length field. Indicate variable length field by putting > > "(4 or 16 octets)" after the text in the field. > > > > 5) Section 2.5.3, pg. 12 - Key field in message diagram > > > > Only 4 bytes are shown for the key field, but the key size field allows > > 65535. The message diagram needs to be changed. > > > > Replace: In the message diagram, replace the final "|" with a "~" to > > indicate a variable length field. Indicate the variable length field by > > putting "(variable)" after the text in the field. > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ 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