[nemo] Comments on draft-clausen-nemo-ro-problem-statement-00.txt

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Mon, 08 November 2004 09:57 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16027 for <nemo-archive@lists.ietf.org>; Mon, 8 Nov 2004 04:57:03 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR65S-00035L-QF; Mon, 08 Nov 2004 04:45:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR5vv-0001it-UY for nemo@megatron.ietf.org; Mon, 08 Nov 2004 04:35:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14585 for <nemo@ietf.org>; Mon, 8 Nov 2004 04:35:29 -0500 (EST)
Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR5wN-0003O0-Aa for nemo@ietf.org; Mon, 08 Nov 2004 04:36:03 -0500
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B0A6E2DC4C; Mon, 8 Nov 2004 10:34:52 +0100 (CET)
Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp02.uc3m.es (Postfix) with ESMTP id 6A7F62DC35; Mon, 8 Nov 2004 10:34:52 +0100 (CET)
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: nemo@ietf.org
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-QeJnHvY8xMU1lPd4yVVZ"
Organization: Universidad Carlos III de Madrid
Message-Id: <1099906490.2545.12.camel@acorde>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6
Date: Mon, 08 Nov 2004 10:34:50 +0100
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: Ryuji Wakikawa <ryuji@sfc.wide.ad.jp>
Subject: [nemo] Comments on draft-clausen-nemo-ro-problem-statement-00.txt
X-BeenThere: nemo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NEMO Working Group <nemo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nemo@ietf.org>
List-Help: <mailto:nemo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=subscribe>
Sender: nemo-bounces@ietf.org
Errors-To: nemo-bounces@ietf.org

Hi Ryuji,

First of all, thanks for submitting the draft.

Your draft seems to address the problem of the Internet-to-NEMO
communication and the NEMO-to-NEMO communication when nesting is
involved, using a MANET approach. I agree with you that in the
NEMO-to-NEMO approach, having the MRs in a nested-NEMO running an Ad-Hoc
routing protocol would help to avoid traversing the Internet and also
avoid the encapsulation. On the other hand, I don't see that clear how
this would help the Internet-to-NEMO, at least as it is now described in
the current version of your draft.

The draft says:

   "Additionally, this would also ease the Internet-to-NEMO scenario. In
   order to deliver an IP datagram to a node in the nested NEMO network,
   only a path to the access router between the nested NEMO network and
   the Internet would be required: once an IP datagram arrives in the
   nested NEMO network, the routing tables in the mobile routers, as
   provided by OLSR, would allow direct routing to the destination.
   Thus, there would no longer be a requirement to do nested encapsula-
   tion on each logical hop (i.e. each transversal of a Home Agent) in
   order to be able to decapsulate and correctly forward IP datagrams in
   the nested NEMO network.


   Thus even if no route optimizations are performed in the Internet-to-
   NEMO scenario, an overhead reduction can still be achieved through
   much lower encapsulation requirements."

How this improvements are achieved? If a CN in the Internet sends a
packet to a MNN that is connected to a nested-NEMO, the packet would
traverse the HAs of every MR in the nested-NEMO until the MNN is finally
reached. Therefore, I don't see how this encapsulation would be avoided,
without making any additional change to the MR and/or HA and/or CN. Am I
missing something?

Thanks in advance.

Kind Regards,

Carlos J.

-- 
Carlos Jesús Bernardos Cano - http://www.it.uc3m.es/cjbc/
GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40