RE: [Seamoby] DoCoMo Implementation Issues with CTP
john.loughney@nokia.com Wed, 18 February 2004 13:59 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 IAA11181 for <seamoby-archive@odin.ietf.org>; Wed, 18 Feb 2004 08:59:26 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSE6-00008H-6o for seamoby-archive@odin.ietf.org; Wed, 18 Feb 2004 08:58:58 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IDwwDs000509 for seamoby-archive@odin.ietf.org; Wed, 18 Feb 2004 08:58:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSE6-000088-2G for seamoby-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 08:58:58 -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 IAA11144 for <seamoby-web-archive@ietf.org>; Wed, 18 Feb 2004 08:58:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtSE4-00007l-00 for seamoby-web-archive@ietf.org; Wed, 18 Feb 2004 08:58:56 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtSD6-00002E-00 for seamoby-web-archive@ietf.org; Wed, 18 Feb 2004 08:57:57 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtSCC-0007lM-00 for seamoby-web-archive@ietf.org; Wed, 18 Feb 2004 08:57:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSCC-0008SI-OH; Wed, 18 Feb 2004 08:57:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSC2-0008Rv-IY for seamoby@optimus.ietf.org; Wed, 18 Feb 2004 08:56:51 -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 IAA11035 for <seamoby@ietf.org>; Wed, 18 Feb 2004 08:56:48 -0500 (EST)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtSC0-0007jh-00 for seamoby@ietf.org; Wed, 18 Feb 2004 08:56:49 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtSB2-0007fH-00 for seamoby@ietf.org; Wed, 18 Feb 2004 08:55:49 -0500
Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1AtSA6-0007bU-00 for seamoby@ietf.org; Wed, 18 Feb 2004 08:54:50 -0500
Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1IDsmT15861; Wed, 18 Feb 2004 15:54:48 +0200 (EET)
X-Scanned: Wed, 18 Feb 2004 15:54:09 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE
Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i1IDs9Y9031328; Wed, 18 Feb 2004 15:54:09 +0200
Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00eu6F7e; Wed, 18 Feb 2004 15:54:07 EET
Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1IDs5710959; Wed, 18 Feb 2004 15:54:05 +0200 (EET)
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 18 Feb 2004 15:54:04 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Seamoby] DoCoMo Implementation Issues with CTP
Date: Wed, 18 Feb 2004 15:54:04 +0200
Message-ID: <DADF50F5EC506B41A0F375ABEB3206360143B6D5@esebe023.ntc.nokia.com>
Thread-Topic: [Seamoby] DoCoMo Implementation Issues with CTP
Thread-Index: AcP1pLy6jnS0bPtvTkmJ9DvbtmWJggAgefMA
To: kempf@docomolabs-usa.com, seamoby@ietf.org
Cc: dendukuri@docomolabs-usa.com
X-OriginalArrivalTime: 18 Feb 2004 13:54:04.0963 (UTC) FILETIME=[ABE55730:01C3F626]
Content-Transfer-Encoding: quoted-printable
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.3 required=5.0 tests=AWL, NO_REAL_NAME autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
James, These seem like reasonable changes to me. John > -----Original Message----- > From: seamoby-admin@ietf.org > [mailto:seamoby-admin@ietf.org]On Behalf Of > ext James Kempf > Sent: 18 February, 2004 00:21 > To: seamoby@ietf.org > Cc: Raghu Dendukuri > Subject: [Seamoby] DoCoMo Implementation Issues with CTP > > > > 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] 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