From nemo-bounces@ietf.org Tue Jul 05 18:57:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpwLk-0000rq-KM; Tue, 05 Jul 2005 18:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpwLG-0000LJ-MK; Tue, 05 Jul 2005 18:56:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12494; Tue, 5 Jul 2005 18:56:32 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpwfk-0007IX-38; Tue, 05 Jul 2005 19:17:49 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DpwEr-0007ak-A1; Tue, 05 Jul 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 05 Jul 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-ro-problem-statement-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Mobility Route Optimization Problem Statement Author(s) : C. Ng, et al. Filename : draft-ietf-nemo-ro-problem-statement-00.txt Pages : 24 Date : 2005-7-5 With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away. This results in various inefficiencies associated with packet delivery. This document investigates such inefficiencies, and provides for the motivation behind Route Optimization (RO) for NEMO. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-statement-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-ro-problem-statement-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-ro-problem-statement-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-5153955.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-ro-problem-statement-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-ro-problem-statement-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-5153955.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Wed Jul 06 08:39:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq9C3-0006X0-Qt; Wed, 06 Jul 2005 08:39:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq9C1-0006V2-R9 for nemo@megatron.ietf.org; Wed, 06 Jul 2005 08:39:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12961 for ; Wed, 6 Jul 2005 08:39:54 -0400 (EDT) Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq9Z9-0004Wk-LN for nemo@ietf.org; Wed, 06 Jul 2005 09:03:52 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 1F4BE80CC for ; Wed, 6 Jul 2005 14:35:26 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.50) id 1Dq95z-00087z-3e for nemo@ietf.org; Wed, 06 Jul 2005 14:33:43 +0200 Date: Wed, 6 Jul 2005 14:33:43 +0200 From: Julien Bournelle To: nemo@ietf.org Message-ID: <20050706123343.GE28487@ipv6-3.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [nemo] About section 2.5 in ro-problem-statement X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi all, I take a look at draft-ietf-nemo-ro-problem-statement-00.txt. I basically have 2 questions concerning section 2.5: In the first paragraph, it is written that: "When Mobile Routers have no prior knowledge of their peers..." In this sentence, "peers" means other MRs, MNNs, both ? Then it is written that: "In particular, it is possible to adopt a tit for tat (T4T) strategy and forward traffic unless the other party proves to be uncooperative when it is sollicited." I don't clearly understand this sentence. If we consider the Figure 1. MR3 uses MR2. So MR2 forwards traffic for MR3. But I don't see how MR3 can be uncooperative from MR2 perspective. Could you clarify this ? regards, -- julien.bournelle at int-evry.fr From nemo-bounces@ietf.org Wed Jul 06 10:05:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqAWT-0006kE-D8; Wed, 06 Jul 2005 10:05:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqAWP-0006fh-Na for nemo@megatron.ietf.org; Wed, 06 Jul 2005 10:05:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28053 for ; Wed, 6 Jul 2005 10:05:00 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqAtj-0000x3-9F for nemo@ietf.org; Wed, 06 Jul 2005 10:29:12 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j66E157Y025806; Wed, 6 Jul 2005 23:01:05 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j66E15p02227; Wed, 6 Jul 2005 23:01:05 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id j66E14612323; Wed, 6 Jul 2005 23:01:04 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 21:58:45 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 4498020C1D2; Wed, 6 Jul 2005 22:12:48 +0800 (SGT) Subject: Re: [nemo] About section 2.5 in ro-problem-statement From: Chan-Wah Ng To: Julien Bournelle In-Reply-To: <20050706123343.GE28487@ipv6-3.int-evry.fr> References: <20050706123343.GE28487@ipv6-3.int-evry.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 06 Jul 2005 22:12:47 +0800 Message-Id: <1120659168.9472.204.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 06 Jul 2005 13:58:45.0253 (UTC) FILETIME=[D3283350:01C58232] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Julien, First of all, thanks for reading the draft, and bringing comments. See my response in line (I would expect Pascal to give you better answers, but let me attempt any way). On Wed, 2005-07-06 at 14:33 +0200, Julien Bournelle wrote: > Hi all, > > I take a look at draft-ietf-nemo-ro-problem-statement-00.txt. > > I basically have 2 questions concerning section 2.5: > > In the first paragraph, it is written that: > > "When Mobile Routers have no prior knowledge of their peers..." > > In this sentence, "peers" means other MRs, MNNs, both ? Used in this context, "peers" should refer to other Mobile Routers who are trying to do the same thing (i.e. trying to "cooperate to improve the network availability for all parties"). > Then it is written that: "In particular, it is possible to adopt a tit > for tat (T4T) strategy and forward traffic unless the other party > proves to be uncooperative when it is sollicited." > > I don't clearly understand this sentence. If we consider the Figure 1. > MR3 uses MR2. So MR2 forwards traffic for MR3. But I don't see how MR3 > can be uncooperative from MR2 perspective. Could you clarify this ? > What this sentence tries to illustrate is that mobile routers may wish to relay each others packets to the Internet. Remembering they are mobile, there may be times when MR3 is attached to MR2, and times when MR2 is attached to MR3. So when MR3 is attached to MR2, should MR2 prove to refuse to provide connectivity to MR3, when the times comes to MR2 attaching to MR3, MR3 may refuse to help. /rgds /cwng From nemo-bounces@ietf.org Wed Jul 06 10:39:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqB3l-0000RB-UW; Wed, 06 Jul 2005 10:39:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqB3j-0000PY-0J for nemo@megatron.ietf.org; Wed, 06 Jul 2005 10:39:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04553 for ; Wed, 6 Jul 2005 10:39:26 -0400 (EDT) Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqBMh-0001Wx-Cd for nemo@ietf.org; Wed, 06 Jul 2005 10:59:08 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id CA2B9803E; Wed, 6 Jul 2005 16:30:34 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.50) id 1DqAtP-0008EC-NI; Wed, 06 Jul 2005 16:28:51 +0200 Date: Wed, 6 Jul 2005 16:28:51 +0200 From: Julien Bournelle To: Chan-Wah Ng Subject: Re: [nemo] About section 2.5 in ro-problem-statement Message-ID: <20050706142851.GD31385@ipv6-3.int-evry.fr> References: <20050706123343.GE28487@ipv6-3.int-evry.fr> <1120659168.9472.204.camel@bach.psl.com.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1120659168.9472.204.camel@bach.psl.com.sg> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: IETF NEMO WG , Julien Bournelle X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, thanks for your quick answer, comments inline, On Wed, Jul 06, 2005 at 10:12:47PM +0800, Chan-Wah Ng wrote: > Hello Julien, > > First of all, thanks for reading the draft, and bringing comments. > See my response in line (I would expect Pascal to give you better > answers, but let me attempt any way). > > On Wed, 2005-07-06 at 14:33 +0200, Julien Bournelle wrote: > > Hi all, > > > > I take a look at draft-ietf-nemo-ro-problem-statement-00.txt. > > > > I basically have 2 questions concerning section 2.5: > > > > In the first paragraph, it is written that: > > > > "When Mobile Routers have no prior knowledge of their peers..." > > > > In this sentence, "peers" means other MRs, MNNs, both ? > > Used in this context, "peers" should refer to other Mobile Routers who > are trying to do the same thing (i.e. trying to "cooperate to improve > the network availability for all parties"). ok > > > Then it is written that: "In particular, it is possible to adopt a tit > > for tat (T4T) strategy and forward traffic unless the other party > > proves to be uncooperative when it is sollicited." > > > > I don't clearly understand this sentence. If we consider the Figure 1. > > MR3 uses MR2. So MR2 forwards traffic for MR3. But I don't see how MR3 > > can be uncooperative from MR2 perspective. Could you clarify this ? > > > > What this sentence tries to illustrate is that mobile routers may wish > to relay each others packets to the Internet. Remembering they are > mobile, there may be times when MR3 is attached to MR2, and times when > MR2 is attached to MR3. So when MR3 is attached to MR2, should MR2 > prove to refuse to provide connectivity to MR3, when the times comes to > MR2 attaching to MR3, MR3 may refuse to help. how MR2 knows that it is forwarding traffic for MR3 and not from a MNNs ? I mean that your text implies that the MR2 is able to detect that MR3 is a Mobile Router and not a MNN. (maybe by inspecting BUs sent from ingress network ?) regards, > > /rgds > /cwng > > -- julien.bournelle at int-evry.fr From nemo-bounces@ietf.org Wed Jul 06 11:11:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqBYx-0000Xe-Rp; Wed, 06 Jul 2005 11:11:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqBYv-0000Vg-7C for nemo@megatron.ietf.org; Wed, 06 Jul 2005 11:11:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08079 for ; Wed, 6 Jul 2005 11:11:40 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqBoZ-0001P0-W7 for nemo@ietf.org; Wed, 06 Jul 2005 11:27:57 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 06 Jul 2005 16:59:52 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j66ExYDs028743; Wed, 6 Jul 2005 16:59:48 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Jul 2005 16:59:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] About section 2.5 in ro-problem-statement Date: Wed, 6 Jul 2005 16:59:34 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC010F71D9@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] About section 2.5 in ro-problem-statement Thread-Index: AcWCOMQlBXMximmRQUGIFSI9+8x3pQAAln6A From: "Pascal Thubert \(pthubert\)" To: "Julien Bournelle" , "Chan-Wah Ng" X-OriginalArrivalTime: 06 Jul 2005 14:59:41.0326 (UTC) FILETIME=[5658AAE0:01C5823B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >> >> What this sentence tries to illustrate is that mobile routers may wish >> to relay each others packets to the Internet. Remembering they are >> mobile, there may be times when MR3 is attached to MR2, and times when >> MR2 is attached to MR3. So when MR3 is attached to MR2, should MR2 >> prove to refuse to provide connectivity to MR3, when the times comes to >> MR2 attaching to MR3, MR3 may refuse to help. > > how MR2 knows that it is forwarding traffic for MR3 and not from a > MNNs ? I mean that your text implies that the MR2 is able to detect > that MR3 is a Mobile Router and not a MNN. > > (maybe by inspecting BUs sent from ingress network ?) > [] This might depend on the RO solution :) Also, there might be some minimal handshake between routers when the form a mesh. All to be defined. Pascal From nemo-bounces@ietf.org Wed Jul 06 21:42:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqLPn-0000Cz-LZ; Wed, 06 Jul 2005 21:42:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqLPl-0000AI-Uj for nemo@megatron.ietf.org; Wed, 06 Jul 2005 21:42:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23664 for ; Wed, 6 Jul 2005 21:42:56 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqLqm-0004dk-9r for nemo@ietf.org; Wed, 06 Jul 2005 22:10:58 -0400 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 7378C4C55A for ; Thu, 7 Jul 2005 10:41:06 +0900 (JST) Date: Thu, 7 Jul 2005 10:42:18 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] About section 2.5 in ro-problem-statement Message-Id: <20050707104218.26b308bd.ernst@sfc.wide.ad.jp> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC010F71D9@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC010F71D9@xmb-ams-337.emea.cisco.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > >> What this sentence tries to illustrate is that mobile routers may > wish > >> to relay each others packets to the Internet. Remembering they are > >> mobile, there may be times when MR3 is attached to MR2, and times > when > >> MR2 is attached to MR3. So when MR3 is attached to MR2, should MR2 > >> prove to refuse to provide connectivity to MR3, when the times > >comes > to > >> MR2 attaching to MR3, MR3 may refuse to help. > > > > how MR2 knows that it is forwarding traffic for MR3 and not from a > > MNNs ? I mean that your text implies that the MR2 is able to detect > > that MR3 is a Mobile Router and not a MNN. > > > > (maybe by inspecting BUs sent from ingress network ?) > > > [] This might depend on the RO solution :) Also, there might be > some minimal handshake between routers when the form a mesh. All to be > defined. A scenario where MR2 is providing access to MR3 and later MR3 providing access to MR2 seems to suggest an ad-hoc netsted NEMO. Is this intentional ? Isn't this crossing a boundary between MANET and NEMO that we should better avoid crossing ? In the general case, there would be a MR in a bus and then a passenger with a MR. The MR in the bus would always provide connectivity to the MR carried by the passenger, never the other way round. Thierry From nemo-bounces@ietf.org Wed Jul 06 22:05:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqLln-0004dh-7n; Wed, 06 Jul 2005 22:05:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqLll-0004ag-Cr for nemo@megatron.ietf.org; Wed, 06 Jul 2005 22:05:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25282 for ; Wed, 6 Jul 2005 22:05:37 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqMCo-0001K2-8t for nemo@ietf.org; Wed, 06 Jul 2005 22:33:39 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j6725P7Y005717; Thu, 7 Jul 2005 11:05:25 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j6725Rx21562; Thu, 7 Jul 2005 11:05:27 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id j6725Q627455; Thu, 7 Jul 2005 11:05:26 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 10:03:05 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 79B9B20C1D2; Thu, 7 Jul 2005 10:17:12 +0800 (SGT) Subject: Re: [nemo] About section 2.5 in ro-problem-statement From: Chan-Wah Ng To: Julien Bournelle In-Reply-To: <20050706142851.GD31385@ipv6-3.int-evry.fr> References: <20050706123343.GE28487@ipv6-3.int-evry.fr> <1120659168.9472.204.camel@bach.psl.com.sg> <20050706142851.GD31385@ipv6-3.int-evry.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 07 Jul 2005 10:17:11 +0800 Message-Id: <1120702632.9472.212.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 07 Jul 2005 02:03:06.0001 (UTC) FILETIME=[03C81010:01C58298] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Wed, 2005-07-06 at 16:28 +0200, Julien Bournelle wrote: > > > > > Then it is written that: "In particular, it is possible to adopt a tit > > > for tat (T4T) strategy and forward traffic unless the other party > > > proves to be uncooperative when it is sollicited." > > > > > > I don't clearly understand this sentence. If we consider the Figure 1. > > > MR3 uses MR2. So MR2 forwards traffic for MR3. But I don't see how MR3 > > > can be uncooperative from MR2 perspective. Could you clarify this ? > > > > > > > What this sentence tries to illustrate is that mobile routers may wish > > to relay each others packets to the Internet. Remembering they are > > mobile, there may be times when MR3 is attached to MR2, and times when > > MR2 is attached to MR3. So when MR3 is attached to MR2, should MR2 > > prove to refuse to provide connectivity to MR3, when the times comes to > > MR2 attaching to MR3, MR3 may refuse to help. > > how MR2 knows that it is forwarding traffic for MR3 and not from a > MNNs ? I mean that your text implies that the MR2 is able to detect > that MR3 is a Mobile Router and not a MNN. > Lots of ways. Layer 2 identities, etc. > (maybe by inspecting BUs sent from ingress network ?) > Perhaps. The point is that there are scenarios where security policy is forbidding traffic from visitors to be tunneled into the home network, and RO may be able to resolve this. The T4T example is, just that, an example. The specifics of how the example will work is hypothetical at best, and would be clouding the point of the sub-section. /rgds /cwng From nemo-bounces@ietf.org Wed Jul 06 22:16:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqLwK-0005jL-Q4; Wed, 06 Jul 2005 22:16:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqLwJ-0005i4-3L for nemo@megatron.ietf.org; Wed, 06 Jul 2005 22:16:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25922 for ; Wed, 6 Jul 2005 22:16:33 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqMNO-0003p2-UJ for nemo@ietf.org; Wed, 06 Jul 2005 22:44:35 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j672GNxU005893; Thu, 7 Jul 2005 11:16:23 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j672GOa11830; Thu, 7 Jul 2005 11:16:24 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id j672GNt25396; Thu, 7 Jul 2005 11:16:23 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 10:14:03 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id C321A20C1D2; Thu, 7 Jul 2005 10:28:09 +0800 (SGT) Subject: Re: [nemo] About section 2.5 in ro-problem-statement From: Chan-Wah Ng To: Thierry Ernst In-Reply-To: <20050707104218.26b308bd.ernst@sfc.wide.ad.jp> References: <7892795E1A87F04CADFCCF41FADD00FC010F71D9@xmb-ams-337.emea.cisco.com> <20050707104218.26b308bd.ernst@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 07 Jul 2005 10:28:09 +0800 Message-Id: <1120703289.9472.224.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 07 Jul 2005 02:14:03.0254 (UTC) FILETIME=[8B88E960:01C58299] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Thu, 2005-07-07 at 10:42 +0900, Thierry Ernst wrote: > > >> What this sentence tries to illustrate is that mobile routers may > > wish > > >> to relay each others packets to the Internet. Remembering they are > > >> mobile, there may be times when MR3 is attached to MR2, and times > > when > > >> MR2 is attached to MR3. So when MR3 is attached to MR2, should MR2 > > >> prove to refuse to provide connectivity to MR3, when the times > > >comes > > to > > >> MR2 attaching to MR3, MR3 may refuse to help. > > > > > > how MR2 knows that it is forwarding traffic for MR3 and not from a > > > MNNs ? I mean that your text implies that the MR2 is able to detect > > > that MR3 is a Mobile Router and not a MNN. > > > > > > (maybe by inspecting BUs sent from ingress network ?) > > > > > [] This might depend on the RO solution :) Also, there might be > > some minimal handshake between routers when the form a mesh. All to be > > defined. > > A scenario where MR2 is providing access to MR3 and later MR3 providing > access to MR2 seems to suggest an ad-hoc netsted NEMO. Is this > intentional ? Isn't this crossing a boundary between MANET and NEMO that > we should better avoid crossing ? > Not entirely. Think of a PAN with a laptop and phone, and other geezmo gadgets you have nowadays. At times the laptop provides Internet connectivity through its built-in WLAN or even good old traditional Ethernet, at others, the phone provides Internet connectivity through its 3G access. > In the general case, there would be a MR in a bus and then a passenger > with a MR. The MR in the bus would always provide connectivity to the MR > carried by the passenger, never the other way round. > Of-course, and the point of the sub-section is still there (although I can't fathom why a company that deploys a MR on a train would have security policy to forbid traffic from visiting nodes to be tunneled back to its home network). But, train is just one of the countless examples of NEMO, a fleet of ships on the sea is yet another. Even in the train situation, suppose the MR is using 802.11. Alice with a bluetooth gadget handphone would not be able to connect through the train MR. Bob may comes along with a personal MR allowing Alice to connect through. When the train go into blind-spots where connection is lost for the train MR, Alice might wish to return the favor for Bob to connect through her phone. /rgds /cwng From nemo-bounces@ietf.org Wed Jul 06 23:41:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqNGs-0004YZ-K6; Wed, 06 Jul 2005 23:41:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqNGq-0004VS-Ok for nemo@megatron.ietf.org; Wed, 06 Jul 2005 23:41:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00230 for ; Wed, 6 Jul 2005 23:41:50 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqNhu-0002zt-91 for nemo@ietf.org; Thu, 07 Jul 2005 00:09:54 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id AA9A24C65F for ; Thu, 7 Jul 2005 12:39:57 +0900 (JST) Date: Thu, 7 Jul 2005 12:41:10 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] About section 2.5 in ro-problem-statement Message-Id: <20050707124110.32582afc.ernst@sfc.wide.ad.jp> In-Reply-To: <1120703289.9472.224.camel@bach.psl.com.sg> References: <7892795E1A87F04CADFCCF41FADD00FC010F71D9@xmb-ams-337.emea.cisco.com> <20050707104218.26b308bd.ernst@sfc.wide.ad.jp> <1120703289.9472.224.camel@bach.psl.com.sg> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > > > > A scenario where MR2 is providing access to MR3 and later MR3 > > providing access to MR2 seems to suggest an ad-hoc netsted NEMO. Is > > this intentional ? Isn't this crossing a boundary between MANET and > > NEMO that we should better avoid crossing ? > > > > Not entirely. Think of a PAN with a laptop and phone, and other > geezmo gadgets you have nowadays. At times the laptop provides > Internet connectivity through its built-in WLAN or even good old > traditional Ethernet, at others, the phone provides Internet > connectivity through its 3G access. I don't call this a nested NEMO, but a multihomed NEMO. I would rather since this as a PAN with 2 MRs. 1 MR may be the default router at a time, and the other one at another time. > > In the general case, there would be a MR in a bus and then a > > passenger with a MR. The MR in the bus would always provide > > connectivity to the MR carried by the passenger, never the other way > > round. > > > Of-course, and the point of the sub-section is still there (although I > can't fathom why a company that deploys a MR on a train would have > security policy to forbid traffic from visiting nodes to be tunneled > back to its home network). > > But, train is just one of the countless examples of NEMO, a fleet of > ships on the sea is yet another. Even in the train situation, suppose > the MR is using 802.11. Alice with a bluetooth gadget handphone would > not be able to connect through the train MR. Bob may comes along with > a personal MR allowing Alice to connect through. When the train go > into blind-spots where connection is lost for the train MR, Alice > might wish to return the favor for Bob to connect through her phone. I think your scenario is better solved by a MANET routing protocol running in the NEMO train between Alice and Bob. Of course, a nested NEMO could also do the job, but I can see this solution as "walking on the path of MANET". I'm not saying this is bad, but that MANET protocols are just designed for this kind of example. However, I do think it's better to let MANET taking care of this, as I don't see why Bob would provide Alice a CoA when it could simply operate his WIFI in adhoc mode. This should push us to consider inter-operability between MANET and NEMO. Thierry. From nemo-bounces@ietf.org Thu Jul 07 00:02:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqNaS-0005ED-PA; Thu, 07 Jul 2005 00:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqNJH-0006St-Md; Wed, 06 Jul 2005 23:44:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00329; Wed, 6 Jul 2005 23:44:21 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqNkO-0003bt-Gl; Thu, 07 Jul 2005 00:12:24 -0400 Received: from [24.52.170.51] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 423832; Wed, 06 Jul 2005 23:38:41 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 6 Jul 2005 23:41:45 -0400 To: int-area@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Thu, 07 Jul 2005 00:02:07 -0400 Cc: Subject: [nemo] NEW!! Internet Area Mailing List X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org [This message is bcc:ed to all INT area WGs, the IESG and the IAB.] Hi All, We have created an Internet Area mailing list -- int-area@ietf.org. This list will be used to announce Internet area BOFs, to discuss Internet area WG charter updates and to discuss other issues related to the Internet Area, as they arise -- such as whether we should hold an Internet area meeting in Paris. If you wish to join the list, you can do so at: https://www1.ietf.org/mailman/listinfo/int-area The archives should be available at: http://www.ietf.org/mail-archive/web/int-area/index.html (Hopefully this will be the first message in the archive). If you are interested in issues concerning the overall structure or scope of the Internet area and/or are interested in influencing how the Internet area is managed, I hope you will join this list. Thanks, Margaret From nemo-bounces@ietf.org Thu Jul 07 01:41:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqP8H-00072f-AK; Thu, 07 Jul 2005 01:41:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqP8E-00072C-Vk for nemo@megatron.ietf.org; Thu, 07 Jul 2005 01:41:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07300 for ; Thu, 7 Jul 2005 01:41:01 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqPZI-0000TE-Ke for nemo@ietf.org; Thu, 07 Jul 2005 02:09:05 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j675epUF029603; Thu, 7 Jul 2005 14:40:51 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j675epa29686; Thu, 7 Jul 2005 14:40:51 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with ESMTP id j675eqG18042; Thu, 7 Jul 2005 14:40:52 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 13:38:30 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 79E9620C1D2; Thu, 7 Jul 2005 13:52:38 +0800 (SGT) Subject: Re: [nemo] About section 2.5 in ro-problem-statement From: Chan-Wah Ng To: Thierry Ernst In-Reply-To: <20050707124110.32582afc.ernst@sfc.wide.ad.jp> References: <7892795E1A87F04CADFCCF41FADD00FC010F71D9@xmb-ams-337.emea.cisco.com> <20050707104218.26b308bd.ernst@sfc.wide.ad.jp> <1120703289.9472.224.camel@bach.psl.com.sg> <20050707124110.32582afc.ernst@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 07 Jul 2005 13:52:38 +0800 Message-Id: <1120715558.9472.242.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 07 Jul 2005 05:38:30.0953 (UTC) FILETIME=[1BA73990:01C582B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Thu, 2005-07-07 at 12:41 +0900, Thierry Ernst wrote: > > > > > > A scenario where MR2 is providing access to MR3 and later MR3 > > > providing access to MR2 seems to suggest an ad-hoc netsted NEMO. Is > > > this intentional ? Isn't this crossing a boundary between MANET and > > > NEMO that we should better avoid crossing ? > > > > > > > Not entirely. Think of a PAN with a laptop and phone, and other > > geezmo gadgets you have nowadays. At times the laptop provides > > Internet connectivity through its built-in WLAN or even good old > > traditional Ethernet, at others, the phone provides Internet > > connectivity through its 3G access. > > I don't call this a nested NEMO, but a multihomed NEMO. I would rather > since this as a PAN with 2 MRs. 1 MR may be the default router at a > time, and the other one at another time. > True, it is not nested, but it illustrates the case where MR2 and MR3 may use each other as default router alternatively. > > > In the general case, there would be a MR in a bus and then a > > > passenger with a MR. The MR in the bus would always provide > > > connectivity to the MR carried by the passenger, never the other way > > > round. > > > > > Of-course, and the point of the sub-section is still there (although I > > can't fathom why a company that deploys a MR on a train would have > > security policy to forbid traffic from visiting nodes to be tunneled > > back to its home network). > > > > But, train is just one of the countless examples of NEMO, a fleet of > > ships on the sea is yet another. Even in the train situation, suppose > > the MR is using 802.11. Alice with a bluetooth gadget handphone would > > not be able to connect through the train MR. Bob may comes along with > > a personal MR allowing Alice to connect through. When the train go > > into blind-spots where connection is lost for the train MR, Alice > > might wish to return the favor for Bob to connect through her phone. > > I think your scenario is better solved by a MANET routing protocol > running in the NEMO train between Alice and Bob. Of course, a nested > NEMO could also do the job, but I can see this solution as "walking on > the path of MANET". I'm not saying this is bad, but that MANET protocols > are just designed for this kind of example. However, I do think it's > better to let MANET taking care of this, as I don't see why Bob would > provide Alice a CoA when it could simply operate his WIFI in adhoc mode. > > This should push us to consider inter-operability between MANET and > NEMO. > Point taken, but I just wish to probe this further. The concern you have is just with the example given in sect 2.5, right? Or do you think that the problem illustrated by sect 2.5 is non-existent once the inter-operability between MANET and NEMO is clear? /rgds /cwng From nemo-bounces@ietf.org Thu Jul 07 01:53:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPJt-000860-06; Thu, 07 Jul 2005 01:53:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPJq-00084t-Lf for nemo@megatron.ietf.org; Thu, 07 Jul 2005 01:53:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08480 for ; Thu, 7 Jul 2005 01:53:05 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqPkx-0001JT-EI for nemo@ietf.org; Thu, 07 Jul 2005 02:21:08 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id ADA0D4C562 for ; Thu, 7 Jul 2005 14:51:39 +0900 (JST) Date: Thu, 7 Jul 2005 14:52:53 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] About section 2.5 in ro-problem-statement Message-Id: <20050707145253.3f25813e.ernst@sfc.wide.ad.jp> In-Reply-To: <1120715558.9472.242.camel@bach.psl.com.sg> References: <7892795E1A87F04CADFCCF41FADD00FC010F71D9@xmb-ams-337.emea.cisco.com> <20050707104218.26b308bd.ernst@sfc.wide.ad.jp> <1120703289.9472.224.camel@bach.psl.com.sg> <20050707124110.32582afc.ernst@sfc.wide.ad.jp> <1120715558.9472.242.camel@bach.psl.com.sg> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > Point taken, but I just wish to probe this further. The concern you > have is just with the example given in sect 2.5, right? Or do you > think that the problem illustrated by sect 2.5 is non-existent once > the inter-operability between MANET and NEMO is clear? Hi, I don't have a concern with the content in the draft, just about the example given in this thread. Thierry From nemo-bounces@ietf.org Thu Jul 07 03:09:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqQVJ-0002vC-5v; Thu, 07 Jul 2005 03:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqQVG-0002sg-T0 for nemo@megatron.ietf.org; Thu, 07 Jul 2005 03:08:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05193 for ; Thu, 7 Jul 2005 03:08:55 -0400 (EDT) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqQwK-0007y4-CS for nemo@ietf.org; Thu, 07 Jul 2005 03:36:59 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 846954A37C for ; Thu, 7 Jul 2005 09:08:34 +0200 (CEST) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 652E64A369 for ; Thu, 7 Jul 2005 09:08:34 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: nemo@ietf.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-87ZOjSyiuYSsIjQ1sx6a" Organization: UC3M Date: Thu, 07 Jul 2005 09:08:34 +0200 Message-Id: <1120720114.8269.6.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [nemo] Comments on draft-ietf-nemo-ro-problem-statement-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-87ZOjSyiuYSsIjQ1sx6a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, After taking a look at this I-D I've have some comments. First of all I want to say that the draft looks pretty good to me. Now it is closer to achieve the goals that are in the charter. After saying that, here are my comments: - Section 2.1. I would add some comments on TCP performance in the paragraph that deals with the longer route leading to increased delay... The increased delay has not only a significant effect on real-time multimedia streaming applications (here the effect of the delay is more obvious and maybe it is the kind of application most affected, but it is not the only one). The delay has also a severe effect on the obtained throughput by TCP applications, since the throughput is related to the RTT, therefore, if the RTT is inflated due to the MRHA tunnel, then an application may experience a low TCP throughput compared to hosts that communicate directly. Then, if a Route Optimisation mechanism allows to overcome this tunnel (and reduce the delay) that would help at improving the overall TCP performance. We have performed some measurements in a testbed, showing the performance decrease. - Section 2.2. I think that this section could be an additional bullet in Section 2.1. I see the HA being a single point of failure (and the Home Network a bottleneck) as a direct consequence of the MRHA tunnel introduced by the NEMO Basic Support protocol, so I don't see why it has to be in a different subsection. - Section B. Typo: I think it should be "involve" (second line) instead of "involves". - Section B.1.3. I would remove the last paragraph (the one starting with "Providing Route Optimization..."), since it is related to the solution space, not to a problem statement. - Section B.4.3. I would add a comment clarifying that a VMN could also communicate with a node using its CoA as source address (Mobile IPv6 and RFC3484 offer also the possibility of using the MN's CoA as source address). In Case L , there are some communication scenarios that seem to be very convenient for the VMN to choose its CoA address instead of its HoA (for example if the communication is known to be short-lived in advance, like in DNS queries for example). Thanks a lot for the draft. Kind Regards, Carlos J. --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-87ZOjSyiuYSsIjQ1sx6a Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCzNTy7QxZUr+JuXQRAiHcAJ9rHrHT7rjvbBmL6riPqw+Z5PUrWQCfap80 v+IJKJZC7dmDVHn0XqOWtko= =47q+ -----END PGP SIGNATURE----- --=-87ZOjSyiuYSsIjQ1sx6a-- From nemo-bounces@ietf.org Thu Jul 07 03:54:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqRDi-0001DO-GW; Thu, 07 Jul 2005 03:54:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqRDg-00018k-C5 for nemo@megatron.ietf.org; Thu, 07 Jul 2005 03:54:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08821 for ; Thu, 7 Jul 2005 03:54:50 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqReo-0001ui-5a for nemo@ietf.org; Thu, 07 Jul 2005 04:22:55 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j677sd8Q022974; Thu, 7 Jul 2005 16:54:39 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j677sdH14652; Thu, 7 Jul 2005 16:54:40 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id j677scu06146; Thu, 7 Jul 2005 16:54:38 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 15:52:18 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 0D83920C1D2; Thu, 7 Jul 2005 16:06:27 +0800 (SGT) Subject: Re: [nemo] Comments on draft-ietf-nemo-ro-problem-statement-00.txt From: Chan-Wah Ng To: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano In-Reply-To: <1120720114.8269.6.camel@acorde> References: <1120720114.8269.6.camel@acorde> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 07 Jul 2005 16:06:26 +0800 Message-Id: <1120723586.9472.269.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 07 Jul 2005 07:52:18.0926 (UTC) FILETIME=[CCB2B0E0:01C582C8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Thu, 2005-07-07 at 09:08 +0200, Carlos Jes=FAs Bernardos Cano wrote: > Hi all, >=20 > After taking a look at this I-D I've have some comments. >=20 > First of all I want to say that the draft looks pretty good to me. Now > it is closer to achieve the goals that are in the charter. >=20 Thanks for reading the draft, and your kind comments. > After saying that, here are my comments: >=20 > - Section 2.1. I would add some comments on TCP performance in the > paragraph that deals with the longer route leading to increased delay... > The increased delay has not only a significant effect on real-time > multimedia streaming applications (here the effect of the delay is more > obvious and maybe it is the kind of application most affected, but it is > not the only one). The delay has also a severe effect on the obtained > throughput by TCP applications, since the throughput is related to the > RTT, therefore, if the RTT is inflated due to the MRHA tunnel, then an > application may experience a low TCP throughput compared to hosts that > communicate directly. Then, if a Route Optimisation mechanism allows to > overcome this tunnel (and reduce the delay) that would help at improving > the overall TCP performance. We have performed some measurements in a > testbed, showing the performance decrease. >=20 You are right. We would add something there too. About your test results, any paper we can reference? > - Section 2.2. I think that this section could be an additional bullet > in Section 2.1. I see the HA being a single point of failure (and the > Home Network a bottleneck) as a direct consequence of the MRHA tunnel > introduced by the NEMO Basic Support protocol, so I don't see why it has > to be in a different subsection. True. The authors had a similar discussion too. It was my editorial decision to separate the two, since (1) we don't want to bloat sect 2.1, and (2) the nature of the problem is slightly different in that sect 2.1 views the problem from the perspective of a single flow and Sect 2.2 view the problem from the home perspective which is the aggregation of multiple flows.=20 One other point worthy of note is that Sect 2.1 will happen to any flow that pass through the MRHA tunnel, whereas Sect 2.2 may happen only if there is a lot of flows. Conversely, the implications of Sect 2.2 is more severe, as it will affect all flows, even those that does not pass through any MRHA tunnel. >=20 > - Section B. Typo: I think it should be "involve" (second line) instead > of "involves". >=20 OK. > - Section B.1.3. I would remove the last paragraph (the one starting > with "Providing Route Optimization..."), since it is related to the > solution space, not to a problem statement. >=20 I would discuss this with Watari-san, but I don't see any concern why not. > - Section B.4.3. I would add a comment clarifying that a VMN could also > communicate with a node using its CoA as source address (Mobile IPv6 and > RFC3484 offer also the possibility of using the MN's CoA as source > address). In Case L , there are some communication scenarios that seem > to be very convenient for the VMN to choose its CoA address instead of > its HoA (for example if the communication is known to be short-lived in > advance, like in DNS queries for example). OK. Thanks again for the comments and feedback. /rgds /cwng From nemo-bounces@ietf.org Thu Jul 07 04:56:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqSBI-0000DS-5v; Thu, 07 Jul 2005 04:56:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqSBE-00008B-Sa for nemo@megatron.ietf.org; Thu, 07 Jul 2005 04:56:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13463 for ; Thu, 7 Jul 2005 04:56:22 -0400 (EDT) Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqScN-0007ZK-1Y for nemo@ietf.org; Thu, 07 Jul 2005 05:24:28 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 05F1EEC9A3; Thu, 7 Jul 2005 17:55:57 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (unknown [2001:200:601:200:20e:cff:fe08:e137]) by mandala.kddilabs.jp (Postfix) with ESMTP id 20658EC98C; Thu, 7 Jul 2005 17:55:56 +0900 (JST) Received: from [IPv6?2001?200?601?200?a920?64d0?afe5?e060] (unknown [IPv6:2001:200:601:200:a920:64d0:afe5:e060]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id 0B43C340015; Thu, 7 Jul 2005 17:55:56 +0900 (JST) Message-ID: <42CCEE5A.2000007@kddilabs.jp> Date: Thu, 07 Jul 2005 17:56:58 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Chan-Wah Ng Subject: Re: [nemo] Comments on draft-ietf-nemo-ro-problem-statement-00.txt References: <1120720114.8269.6.camel@acorde> <1120723586.9472.269.camel@bach.psl.com.sg> In-Reply-To: <1120723586.9472.269.camel@bach.psl.com.sg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Carlos, Thanks for your comments. Please see my reply inline; On 2005/07/07 17:06, Chan-Wah Ng wrote: > On Thu, 2005-07-07 at 09:08 +0200, Carlos Jes=FAs Bernardos Cano wrote: >=20 >>Hi all, >> >>After taking a look at this I-D I've have some comments. >> >>First of all I want to say that the draft looks pretty good to me. Now >>it is closer to achieve the goals that are in the charter. >> >=20 > Thanks for reading the draft, and your kind comments. >=20 >>After saying that, here are my comments: >> >>- Section 2.1. I would add some comments on TCP performance in the >>paragraph that deals with the longer route leading to increased delay..= . >>The increased delay has not only a significant effect on real-time >>multimedia streaming applications (here the effect of the delay is more >>obvious and maybe it is the kind of application most affected, but it i= s >>not the only one). The delay has also a severe effect on the obtained >>throughput by TCP applications, since the throughput is related to the >>RTT, therefore, if the RTT is inflated due to the MRHA tunnel, then an >>application may experience a low TCP throughput compared to hosts that >>communicate directly. Then, if a Route Optimisation mechanism allows to >>overcome this tunnel (and reduce the delay) that would help at improvin= g >>the overall TCP performance. We have performed some measurements in a >>testbed, showing the performance decrease. >> >=20 > You are right. We would add something there too. About your test > results, any paper we can reference? >=20 >=20 >>- Section 2.2. I think that this section could be an additional bullet >>in Section 2.1. I see the HA being a single point of failure (and the >>Home Network a bottleneck) as a direct consequence of the MRHA tunnel >>introduced by the NEMO Basic Support protocol, so I don't see why it ha= s >>to be in a different subsection. >=20 >=20 > True. The authors had a similar discussion too. It was my editorial > decision to separate the two, since (1) we don't want to bloat sect 2.1= , > and (2) the nature of the problem is slightly different in that sect 2.= 1 > views the problem from the perspective of a single flow and Sect 2.2 > view the problem from the home perspective which is the aggregation of > multiple flows.=20 >=20 > One other point worthy of note is that Sect 2.1 will happen to any flow > that pass through the MRHA tunnel, whereas Sect 2.2 may happen only if > there is a lot of flows. Conversely, the implications of Sect 2.2 is > more severe, as it will affect all flows, even those that does not pass > through any MRHA tunnel. >=20 >>- Section B. Typo: I think it should be "involve" (second line) instead >>of "involves". >> >=20 > OK. >=20 >>- Section B.1.3. I would remove the last paragraph (the one starting >>with "Providing Route Optimization..."), since it is related to the >>solution space, not to a problem statement. >> >=20 > I would discuss this with Watari-san, but I don't see any concern why > not. Yes, this should have been removed. Thanks for pointing this out. >>- Section B.4.3. I would add a comment clarifying that a VMN could also >>communicate with a node using its CoA as source address (Mobile IPv6 an= d >>RFC3484 offer also the possibility of using the MN's CoA as source >>address). In Case L , there are some communication scenarios that seem >>to be very convenient for the VMN to choose its CoA address instead of >>its HoA (for example if the communication is known to be short-lived in >>advance, like in DNS queries for example). Right... I missed this one from my previous draft. Thanks for the reminder. regards, watari From nemo-bounces@ietf.org Thu Jul 07 06:01:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqTCA-0001ek-AG; Thu, 07 Jul 2005 06:01:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqTC6-0001av-Ts for nemo@megatron.ietf.org; Thu, 07 Jul 2005 06:01:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18011 for ; Thu, 7 Jul 2005 06:01:20 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqTdG-0004YA-1Z for nemo@ietf.org; Thu, 07 Jul 2005 06:29:27 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 07 Jul 2005 12:01:12 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j67A15Di019223; Thu, 7 Jul 2005 12:01:08 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 12:00:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: [nemo] Comments on draft-ietf-nemo-ro-problem-statement-00.txt Date: Thu, 7 Jul 2005 12:00:48 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC010F7438@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Comments on draft-ietf-nemo-ro-problem-statement-00.txt Thread-Index: AcWCyd++r2DWgNknTiO7pBXb56ps+wAD9Qmw From: "Pascal Thubert \(pthubert\)" To: "Chan-Wah Ng" , =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-OriginalArrivalTime: 07 Jul 2005 10:00:53.0221 (UTC) FILETIME=[C2C6B150:01C582DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Carlos Thanks a lot for your review :) >> >> - Section 2.1. I would add some comments on TCP performance in the >> paragraph that deals with the longer route leading to increased = delay... >> The increased delay has not only a significant effect on real-time >> multimedia streaming applications (here the effect of the delay is = more >> obvious and maybe it is the kind of application most affected, but it = is >> not the only one). The delay has also a severe effect on the obtained >> throughput by TCP applications, since the throughput is related to = the >> RTT, therefore, if the RTT is inflated due to the MRHA tunnel, then = an >> application may experience a low TCP throughput compared to hosts = that >> communicate directly. Then, if a Route Optimisation mechanism allows = to >> overcome this tunnel (and reduce the delay) that would help at = improving >> the overall TCP performance. We have performed some measurements in a >> testbed, showing the performance decrease. >> >You are right. We would add something there too. About your test >results, any paper we can reference? > [] The 2 usual things, rate and latency.=20 At a given rate, the window size must be big enough to cover the = latency, like window >=3D rate * TAT-delay. In particular, if one router = on the way is responsible for the rate limitation (say it has a slow = link) then it will also be the queueing point where all the extra = (window - rate * TAT-delay) will be queued up.=20 So if TCP windows is too large on the host, this router queue builds up = and he enters random early discard. In turn, this causes TCP to backoff = and the end point of the connection. As a result, if the window is too large, then additional latency would = reduce the queueing at the congestion point, if it is common to RO and = non RO path. Which is the case of the mobile router egress interface... So it's not really simple :) Pascal From nemo-bounces@ietf.org Thu Jul 07 08:38:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqVeZ-0007OW-Bw; Thu, 07 Jul 2005 08:38:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqVeY-0007NL-I6 for nemo@megatron.ietf.org; Thu, 07 Jul 2005 08:38:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01417 for ; Thu, 7 Jul 2005 08:38:52 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqW5h-0003SA-Af for nemo@ietf.org; Thu, 07 Jul 2005 09:06:59 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9D75449B1A; Thu, 7 Jul 2005 14:38:41 +0200 (CEST) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 6419249B22; Thu, 7 Jul 2005 14:38:40 +0200 (CEST) Subject: Re: [nemo] Comments on draft-ietf-nemo-ro-problem-statement-00.txt From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Chan-Wah Ng In-Reply-To: <1120723586.9472.269.camel@bach.psl.com.sg> References: <1120720114.8269.6.camel@acorde> <1120723586.9472.269.camel@bach.psl.com.sg> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Kzw5PS1HxkJHx8OksOsw" Organization: UC3M Date: Thu, 07 Jul 2005 14:38:40 +0200 Message-Id: <1120739920.7670.45.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-Kzw5PS1HxkJHx8OksOsw Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Chan-Wah, El jue, 07-07-2005 a las 16:06 +0800, Chan-Wah Ng escribi=F3:=20 > On Thu, 2005-07-07 at 09:08 +0200, Carlos Jes=FAs Bernardos Cano wrote: > > Hi all, > >=20 > > After taking a look at this I-D I've have some comments. > >=20 > > First of all I want to say that the draft looks pretty good to me. Now > > it is closer to achieve the goals that are in the charter. > >=20 >=20 > Thanks for reading the draft, and your kind comments. >=20 >=20 > > After saying that, here are my comments: > >=20 > > - Section 2.1. I would add some comments on TCP performance in the > > paragraph that deals with the longer route leading to increased delay..= . > > The increased delay has not only a significant effect on real-time > > multimedia streaming applications (here the effect of the delay is more > > obvious and maybe it is the kind of application most affected, but it i= s > > not the only one). The delay has also a severe effect on the obtained > > throughput by TCP applications, since the throughput is related to the > > RTT, therefore, if the RTT is inflated due to the MRHA tunnel, then an > > application may experience a low TCP throughput compared to hosts that > > communicate directly. Then, if a Route Optimisation mechanism allows to > > overcome this tunnel (and reduce the delay) that would help at improvin= g > > the overall TCP performance. We have performed some measurements in a > > testbed, showing the performance decrease. > >=20 > You are right. We would add something there too. About your test > results, any paper we can reference? We have already published one [1], that includes some preliminary results. We have also results from intense testing, but the paper has just been submitted, so there are no public available results. Anyway, I can elaborate something (write one or two paragraphs, maybe summarising also some of our experimental results) so it can be added to the draft if you think it could be useful and valuable. Thanks a lot. Kind Regards, Carlos J. [1] A. de la Oliva, C. J. Bernardos and M. Calder=F3n, "Practical evaluation of a network mobility solution", EUNICE 2005: Networked Applications - 11th Open European Summer School, July 6-8 2005, Colmenarejo, Madrid (Spain) >=20 > > - Section 2.2. I think that this section could be an additional bullet > > in Section 2.1. I see the HA being a single point of failure (and the > > Home Network a bottleneck) as a direct consequence of the MRHA tunnel > > introduced by the NEMO Basic Support protocol, so I don't see why it ha= s > > to be in a different subsection. >=20 > True. The authors had a similar discussion too. It was my editorial > decision to separate the two, since (1) we don't want to bloat sect 2.1, > and (2) the nature of the problem is slightly different in that sect 2.1 > views the problem from the perspective of a single flow and Sect 2.2 > view the problem from the home perspective which is the aggregation of > multiple flows.=20 >=20 > One other point worthy of note is that Sect 2.1 will happen to any flow > that pass through the MRHA tunnel, whereas Sect 2.2 may happen only if > there is a lot of flows. Conversely, the implications of Sect 2.2 is > more severe, as it will affect all flows, even those that does not pass > through any MRHA tunnel. >=20 > >=20 > > - Section B. Typo: I think it should be "involve" (second line) instead > > of "involves". > >=20 > OK. >=20 > > - Section B.1.3. I would remove the last paragraph (the one starting > > with "Providing Route Optimization..."), since it is related to the > > solution space, not to a problem statement. > >=20 > I would discuss this with Watari-san, but I don't see any concern why > not. >=20 > > - Section B.4.3. I would add a comment clarifying that a VMN could also > > communicate with a node using its CoA as source address (Mobile IPv6 an= d > > RFC3484 offer also the possibility of using the MN's CoA as source > > address). In Case L , there are some communication scenarios that seem > > to be very convenient for the VMN to choose its CoA address instead of > > its HoA (for example if the communication is known to be short-lived in > > advance, like in DNS queries for example). >=20 > OK. >=20 > Thanks again for the comments and feedback. >=20 > /rgds > /cwng --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-Kzw5PS1HxkJHx8OksOsw Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCzSJQ7QxZUr+JuXQRAu8oAKCLbs0xBs6yw7OvP4oTQFlE/xmYrwCfZUNo 4rH0tIPu9p6nq8/THe3oqwY= =fMH2 -----END PGP SIGNATURE----- --=-Kzw5PS1HxkJHx8OksOsw-- From nemo-bounces@ietf.org Thu Jul 07 08:46:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqVli-0005CC-8C; Thu, 07 Jul 2005 08:46:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqVlc-0005Ao-Q6 for nemo@megatron.ietf.org; Thu, 07 Jul 2005 08:46:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01900 for ; Thu, 7 Jul 2005 08:46:08 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqWCk-0004wL-Rz for nemo@ietf.org; Thu, 07 Jul 2005 09:14:16 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2FB9D5E13E; Thu, 7 Jul 2005 14:45:59 +0200 (CEST) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 7D8E45E10B; Thu, 7 Jul 2005 14:45:58 +0200 (CEST) Subject: RE: [nemo] Comments on draft-ietf-nemo-ro-problem-statement-00.txt From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC010F7438@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC010F7438@xmb-ams-337.emea.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1ecRGiN0aTf52WgPDfXr" Organization: UC3M Date: Thu, 07 Jul 2005 14:45:58 +0200 Message-Id: <1120740358.7670.53.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: IETF NEMO WG , Chan-Wah Ng X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-1ecRGiN0aTf52WgPDfXr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Pascal, Please, see comments inline. El jue, 07-07-2005 a las 12:00 +0200, Pascal Thubert (pthubert) escribi=F3:= =20 > Hi Carlos >=20 > Thanks a lot for your review :) >=20 > >> > >> - Section 2.1. I would add some comments on TCP performance in the > >> paragraph that deals with the longer route leading to increased delay.= .. > >> The increased delay has not only a significant effect on real-time > >> multimedia streaming applications (here the effect of the delay is mor= e > >> obvious and maybe it is the kind of application most affected, but it = is > >> not the only one). The delay has also a severe effect on the obtained > >> throughput by TCP applications, since the throughput is related to the > >> RTT, therefore, if the RTT is inflated due to the MRHA tunnel, then an > >> application may experience a low TCP throughput compared to hosts that > >> communicate directly. Then, if a Route Optimisation mechanism allows t= o > >> overcome this tunnel (and reduce the delay) that would help at improvi= ng > >> the overall TCP performance. We have performed some measurements in a > >> testbed, showing the performance decrease. > >> > >You are right. We would add something there too. About your test > >results, any paper we can reference? > > > [] The 2 usual things, rate and latency.=20 >=20 > At a given rate, the window size must be big enough to cover the latency,= like window >=3D rate * TAT-delay. In particular, if one router on the way= is responsible for the rate limitation (say it has a slow link) then it wi= ll also be the queueing point where all the extra (window - rate * TAT-dela= y) will be queued up.=20 >=20 > So if TCP windows is too large on the host, this router queue builds up a= nd he enters random early discard. In turn, this causes TCP to backoff and = the end point of the connection. >=20 > As a result, if the window is too large, then additional latency would re= duce the queueing at the congestion point, if it is common to RO and non RO= path. Which is the case of the mobile router egress interface... Maybe I've not understood you well. Let's me explain again. The case I had = in mind, as an example, is the following (btw, it is one of the scenarios w= e have tested): "slow" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CN -------- R ---- R --| Internet |-- R -- HA link O =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D O O O O o o o o =B7 =B7 | | IPv6 MR -- MNN host =20 In the previous scenario, the performance obtained by the MNN compared with= the one obtained by the "non-mobile" IPv6 host (for example when both are = downloading a file from the CN) is significantly better than the one obtain= ed by the MNN. We also tested to vary the delay introduced by the "Internet= " cloud to check how this affects the performance of the MNN. We also performed tests enabling our approach of RO in the NEMO, and in tha= t case the performance obtained was much better. Therefore, I don't get wha= t you said about same performances in the RO and non-RO paths. Could you pl= ease clarify me this? >=20 > So it's not really simple :) Fortunately! no complexity, no fun! :-) Kind Regards, Carlos J. >=20 > Pascal --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-1ecRGiN0aTf52WgPDfXr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCzSQG7QxZUr+JuXQRAv9kAKDrb8Fww14jBVNpJBq+3i6cxr8ZfgCffI8+ 1+5cB7qOcvO1qSeH1B8Wy1Q= =YY4C -----END PGP SIGNATURE----- --=-1ecRGiN0aTf52WgPDfXr-- From nemo-bounces@ietf.org Thu Jul 07 10:45:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXd7-0007k0-H5; Thu, 07 Jul 2005 10:45:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXd3-0007hK-N2 for nemo@megatron.ietf.org; Thu, 07 Jul 2005 10:45:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13816 for ; Thu, 7 Jul 2005 10:45:27 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqY4F-0003kg-C5 for nemo@ietf.org; Thu, 07 Jul 2005 11:13:36 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 07 Jul 2005 16:45:19 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j67EijEA012930; Thu, 7 Jul 2005 16:45:16 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Jul 2005 16:45:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: [nemo] Comments on draft-ietf-nemo-ro-problem-statement-00.txt Date: Thu, 7 Jul 2005 16:45:03 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC010F7576@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Comments on draft-ietf-nemo-ro-problem-statement-00.txt Thread-Index: AcWC8d8Edbz6j0xgRFWax4YHrHlw0gAD4ufA From: "Pascal Thubert \(pthubert\)" To: =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= X-OriginalArrivalTime: 07 Jul 2005 14:45:07.0247 (UTC) FILETIME=[77C48BF0:01C58302] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , Chan-Wah Ng X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >> >> So if TCP windows is too large on the host, this router queue builds = up >and he enters random early discard. In turn, this causes TCP to backoff = and >the end point of the connection. >> >> As a result, if the window is too large, then additional latency = would >reduce the queueing at the congestion point, if it is common to RO and = non >RO path. Which is the case of the mobile router egress interface... > >Maybe I've not understood you well. Let's me explain again. The case I = had >in mind, as an example, is the following (btw, it is one of the = scenarios >we have tested): > > "slow" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > CN -------- R ---- R --| Internet |-- R -- HA > link O =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > O O > O O > o o > o o > =B7 =B7 > | | > IPv6 MR -- MNN > host > >In the previous scenario, the performance obtained by the MNN compared = with >the one obtained by the "non-mobile" IPv6 host (for example when both = are >downloading a file from the CN) is significantly better than the one >obtained by the MNN. We also tested to vary the delay introduced by the >"Internet" cloud to check how this affects the performance of the MNN. > >We also performed tests enabling our approach of RO in the NEMO, and in >that case the performance obtained was much better. Therefore, I don't = get >what you said about same performances in the RO and non-RO paths. Could = you >please clarify me this? > >> >> So it's not really simple :) > >Fortunately! no complexity, no fun! :-) > [] Could you play with the TCP window size? Maybe it was not enough = to cope with the internet latency? Was the Internet throughput higher then you "slow" link? If not, then = the internet somewhere was your bottleneck and if si, it was prone to be = the place for RED. Which comes to the next question: Did you have a measure the packet loss = over the internet?=20 One good indication to figure out what's going on is to compare the = results in TCP and in UDP. Did you toy with that as well? As you know, there are many parameters to this equation, and RO will = generally - be not always and not for sure give - better performance = results. Pascal From nemo-bounces@ietf.org Thu Jul 07 13:35:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqaHm-0008G5-Us; Thu, 07 Jul 2005 13:35:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqaHm-0008Fw-5D for nemo@megatron.ietf.org; Thu, 07 Jul 2005 13:35:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28126 for ; Thu, 7 Jul 2005 13:35:38 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqaix-0004x1-8r for nemo@ietf.org; Thu, 07 Jul 2005 14:03:50 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0C61A49B7E; Thu, 7 Jul 2005 19:35:28 +0200 (CEST) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 61A9A49B7A; Thu, 7 Jul 2005 19:35:27 +0200 (CEST) Subject: RE: [nemo] Comments on draft-ietf-nemo-ro-problem-statement-00.txt From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC010F7576@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC010F7576@xmb-ams-337.emea.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3d7Ld3sJZZ2WCdku1R6w" Organization: UC3M Date: Thu, 07 Jul 2005 19:35:27 +0200 Message-Id: <1120757727.7670.92.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: IETF NEMO WG , Chan-Wah Ng X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-3d7Ld3sJZZ2WCdku1R6w Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Pascal, El jue, 07-07-2005 a las 16:45 +0200, Pascal Thubert (pthubert) escribi=F3:=20 > >> > >> So if TCP windows is too large on the host, this router queue builds u= p > >and he enters random early discard. In turn, this causes TCP to backoff = and > >the end point of the connection. > >> > >> As a result, if the window is too large, then additional latency would > >reduce the queueing at the congestion point, if it is common to RO and n= on > >RO path. Which is the case of the mobile router egress interface... > > > >Maybe I've not understood you well. Let's me explain again. The case I h= ad > >in mind, as an example, is the following (btw, it is one of the scenario= s > >we have tested): > > > > "slow" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > CN -------- R ---- R --| Internet |-- R -- HA > > link O =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > O O > > O O > > o o > > o o > > =B7 =B7 > > | | > > IPv6 MR -- MNN > > host > > > >In the previous scenario, the performance obtained by the MNN compared w= ith > >the one obtained by the "non-mobile" IPv6 host (for example when both ar= e > >downloading a file from the CN) is significantly better than the one > >obtained by the MNN. We also tested to vary the delay introduced by the > >"Internet" cloud to check how this affects the performance of the MNN. > > > >We also performed tests enabling our approach of RO in the NEMO, and in > >that case the performance obtained was much better. Therefore, I don't g= et > >what you said about same performances in the RO and non-RO paths. Could = you > >please clarify me this? > > > >> > >> So it's not really simple :) > > > >Fortunately! no complexity, no fun! :-) > > > [] Could you play with the TCP window size? Maybe it was not enough t= o cope with the internet latency? We did not play with that. We just used the default window size that Linux-2.6 kernels use. >=20 > Was the Internet throughput higher then you "slow" link? If not, then the= internet somewhere was your bottleneck and if si, it was prone to be the p= lace for RED. No, it wasn't. Actually, the "Internet" cloud was also a network of the testbed, but running some software that allowed us to modify the link characteristics (latency, bandwidth, etc.) >=20 > Which comes to the next question: Did you have a measure the packet loss = over the internet?=20 No, that's not needed, since the "Internet" cloud actually is just an internal network in our lab. >=20 > One good indication to figure out what's going on is to compare the resul= ts in TCP and in UDP. Did you toy with that as well? >=20 > As you know, there are many parameters to this equation, and RO will gene= rally - be not always and not for sure give - better performance results. Yes, of course there are many parameters (TCP is quite complex), but we were interested in evaluating the effect of having a longer path - since that's one of the consequences of using the NEMO Basic Support protocol without RO - in the TCP throughput (and the RTT usually has a significant effect on the throughput). Additionally, we tried to evaluate how good was the improvement - in terms of TCP performance - we could obtain by using a RO approach instead of just the NEMO Basic Support protocol. One additional remark: we are considering the scenario in which there are, besides the MNN, other nodes (not located at the NEMO), competing (i.e., sharing) the bottleneck ("slow") link. In this case, the flows with higher RTTs are penalised, thus the increased latency has an impact. Kind Regards, Carlos J. >=20 > Pascal --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-3d7Ld3sJZZ2WCdku1R6w Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCzWff7QxZUr+JuXQRAkSKAJwPArfEca6zRkN36E3MvovHXNBd6QCgjiRr akCCrDMRIZjoI6nmyyLj+Xk= =n/Km -----END PGP SIGNATURE----- --=-3d7Ld3sJZZ2WCdku1R6w-- From nemo-bounces@ietf.org Fri Jul 08 03:57:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqnju-0004N5-Ln; Fri, 08 Jul 2005 03:57:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqnai-0007eO-Gg for nemo@megatron.ietf.org; Fri, 08 Jul 2005 03:48:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07062 for ; Fri, 8 Jul 2005 03:48:07 -0400 (EDT) Received: from nproxy.gmail.com ([64.233.182.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqo22-00026q-AL for nemo@ietf.org; Fri, 08 Jul 2005 04:16:24 -0400 Received: by nproxy.gmail.com with SMTP id g2so85773nfe for ; Fri, 08 Jul 2005 00:47:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=q1j55zEVaftn/diXC0z7gykOyoDF/WKE51c4BPDVkkVwru3vVozc6CS+98evltZ8sljmBEUvSEldxQr1lL65HQrQz2oswbUdnkS3+4fa8mVEkBSiHX6DA3YzW7KRZqdJwCwWEiCzBEGMVAUTerUFgcIuixzRDn/7ZUtjf9qHk64= Received: by 10.48.240.16 with SMTP id n16mr55622nfh; Fri, 08 Jul 2005 00:47:54 -0700 (PDT) Received: by 10.48.144.20 with HTTP; Fri, 8 Jul 2005 00:47:54 -0700 (PDT) Message-ID: <29ed16a4050708004728ed10c9@mail.gmail.com> Date: Fri, 8 Jul 2005 09:47:54 +0200 From: Ana Minaburo To: nemo@ietf.org, rohc@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 08 Jul 2005 03:57:36 -0400 Cc: "E.K. Paik" , Carsten Bormann , Vijay Devarapalli Subject: [nemo] New version for draft-minaburo-rohc-nemo-01.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: anacarolina.minaburo@enst-bretagne.fr List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello,=20 Please receive the new versionof our draft, taking into account all your suggestions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-minaburo-rohc-nemo-01.txt thank you Ana From nemo-bounces@ietf.org Mon Jul 11 03:08:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrsOf-0007Ga-56; Mon, 11 Jul 2005 03:08:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrsOe-0007GP-6U for nemo@megatron.ietf.org; Mon, 11 Jul 2005 03:08:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17329 for ; Mon, 11 Jul 2005 03:08:06 -0400 (EDT) Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrsqV-0008LI-QF for nemo@ietf.org; Mon, 11 Jul 2005 03:37:01 -0400 Received: from [147.46.216.57] ([147.46.216.57]) by mmlab.snu.ac.kr (8.12.10/8.12.10) with ESMTP id j6B7KPAH019824 for ; Mon, 11 Jul 2005 16:20:25 +0900 (KST) (envelope-from jhryu@mmlab.snu.ac.kr) Message-ID: <42D21AC7.9040708@mmlab.snu.ac.kr> Date: Mon, 11 Jul 2005 16:07:51 +0900 From: =?EUC-KR?B?t/nB9sij?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ko-kr, ko, en-us, en MIME-Version: 1.0 To: nemo@ietf.org Subject: [nemo] New draft: Failover for multiple mobile routers Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Score: 1.5 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi all,

We have submitted a new draft on the failover for multiple mobile
routers in a mobile network. Your comments are appreciated.

http://www.ietf.org/internet-drafts/draft-ryu-nemo-mr-failover-00.txt

Abstract:
This draft proposed the use of multiple mobile routers in a single
NEMO. Failed mobile router is replaced by another mobile router
using "prefix peer" relationship among mobile routers in a NEMO.
"prefix peer" relationship enables a mobile router's prefix to be
handled by another mobile router.

Regards
Jiho Ryu. From nemo-bounces@ietf.org Mon Jul 11 23:30:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsBTP-0005oV-DU; Mon, 11 Jul 2005 23:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsBTN-0005oQ-7J for nemo@megatron.ietf.org; Mon, 11 Jul 2005 23:30:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20995 for ; Mon, 11 Jul 2005 23:30:14 -0400 (EDT) Received: from root-dhcp-126.qgpop.net ([133.69.136.126] helo=fuk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsBvV-0008G1-01 for nemo@ietf.org; Mon, 11 Jul 2005 23:59:21 -0400 Received: from localhost (localhost [IPv6:::1]) by fuk (8.12.11/8.11.6) with ESMTP id j6C3U9NV000839 for ; Tue, 12 Jul 2005 12:30:09 +0900 (JST) Date: Tue, 12 Jul 2005 12:30:09 +0900 (JST) Message-Id: <20050712.123009.35846792.hmorioka@fuk> To: nemo@ietf.org From: Hitoshi MORIOKA X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [nemo] New draft draft-morioka-nemo-mrcoop-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi all, I submitted a new draft on multiple mobile routers cooperation. Until the draft becomes available at the official site, you can get it from the following site. http://www.root-hq.com/~hmorioka/draft-morioka-nemo-mrcoop-00.txt Here is the abstract: This protocol intended to provide cooperation between mobile routers in a mobile network. A mobile network is usually connected to the Internet through mobile routers with wireless interfaces. Link quality of the wireless interface changes frequently and rapidly. In case of several mobile routers in a mobile network, MNN should use the MR that has the best link quality. This protocol makes all MRs in a mobile network share link quality of MRs each other. Propagation of routing information in a mobile network is not out of sight of this draft. Any questions and comments are welcome. Hitoshi MORIOKA (hmorioka@root-hq.com) From nemo-bounces@ietf.org Tue Jul 12 00:34:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsCTO-0000mm-J4; Tue, 12 Jul 2005 00:34:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsCTM-0000mh-HL for nemo@megatron.ietf.org; Tue, 12 Jul 2005 00:34:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24647 for ; Tue, 12 Jul 2005 00:34:16 -0400 (EDT) Received: from [163.152.33.121] (helo=dsys.korea.ac.kr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsCvN-0001ev-Ka for nemo@ietf.org; Tue, 12 Jul 2005 01:03:24 -0400 Received: from shkim ([163.152.21.123]) by dsys.korea.ac.kr (8.12.11/8.12.11) with ESMTP id j6C4S2eY012742 for ; Tue, 12 Jul 2005 13:28:05 +0900 (KST) Message-Id: <200507120428.j6C4S2eY012742@dsys.korea.ac.kr> From: =?ks_c_5601-1987?B?sei8usij?= To: Date: Tue, 12 Jul 2005 13:33:26 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcWGMYAQQCJlxWGcR0u3EkRH+O5bjQAaTANg In-Reply-To: <200507111559.j6BFxL1r007465@dsys.korea.ac.kr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Subject: [nemo] refuse message X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear Admin for NEMO I'd like to refure NEMO message... I can't receive this message anymore Thanks... -----Original Message----- From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of nemo-request@ietf.org Sent: Tuesday, July 12, 2005 12:59 AM To: nemo@ietf.org Subject: Nemo Digest, Vol 15, Issue 6 Send Nemo mailing list submissions to nemo@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/nemo or, via email, send a message with subject or body 'help' to nemo-request@ietf.org You can reach the person managing the list at nemo-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Nemo digest..." Today's Topics: 1. New draft: Failover for multiple mobile routers (???) ---------------------------------------------------------------------- Message: 1 Date: Mon, 11 Jul 2005 16:07:51 +0900 From: ??? Subject: [nemo] New draft: Failover for multiple mobile routers To: nemo@ietf.org Message-ID: <42D21AC7.9040708@mmlab.snu.ac.kr> Content-Type: text/plain; charset="us-ascii" An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/nemo/attachments/20050711/a78bc3d2/attachment .htm ------------------------------ _______________________________________________ Nemo mailing list Nemo@ietf.org https://www1.ietf.org/mailman/listinfo/nemo End of Nemo Digest, Vol 15, Issue 6 *********************************** From nemo-bounces@ietf.org Tue Jul 12 09:56:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsLFp-0005vK-6C; Tue, 12 Jul 2005 09:56:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsLFn-0005vF-FG for nemo@megatron.ietf.org; Tue, 12 Jul 2005 09:56:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22874 for ; Tue, 12 Jul 2005 09:56:54 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsLhz-0005GI-Rb for nemo@ietf.org; Tue, 12 Jul 2005 10:26:05 -0400 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJI009TGPEFXZ@mailout2.samsung.com> for nemo@ietf.org; Tue, 12 Jul 2005 22:56:39 +0900 (KST) Received: from kishorem ([107.108.71.69]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPSA id <0IJI0066WPE0AY@mmp1.samsung.com> for nemo@ietf.org; Tue, 12 Jul 2005 22:56:39 +0900 (KST) Date: Tue, 12 Jul 2005 19:22:57 +0530 From: kishore mundra Subject: RE: [nemo] New draft draft-morioka-nemo-mrcoop-00.txt In-reply-to: <20050712.123009.35846792.hmorioka@fuk> To: "'Hitoshi MORIOKA'" , nemo@ietf.org Message-id: <000001c586e9$0b8dee00$45476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7BIT Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Hitoshi, I have a few questions in the draft: 1. Are we assuming that all the MRs have the same HA? Because whosoever becomes primary MR may not be able to send Binding Update for other MRs in case they have different HA. 2. There can be situations (because of dropped packet or at the time of transition from one primary MR to another) where a few of the MRs chooses some MR2 as primary MR and few MRs may still use the previous primary MR,say MR1 as primary MR. During this phase, what if both of them send a Binding Update to HA? The previous primary MR may send BU as the timeout of sending BU whereas the new MR sends assuming he has become the new primary MR. It can be that the Binding Update from new primary MR(MR2) is replaced again by the Binding Update of previous primary MR,MR1. 3. What about the synchronization of BU to the change in routes between MRs. I am asking so because once a BU is completed successfully, the primary MR is responsible for transferring packets to the other MRs. So what if routing table gets updated first and BU got delayed, the previous primary MR may not be able to route the packet and vice versa! 4. U have chosen a value of 300ms for deletion of entry from LM and 100ms for sending LMMs, any particular reason for going for so less value. It may flood a lot of messages in the network and may change primary MRs too rapidly which will create its own set of problems!!! Looking forward for your reply. In case I have misunderstood any part, please do clarify. Regards, Kishore. -----Original Message----- From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Hitoshi MORIOKA Sent: Tuesday, July 12, 2005 9:00 AM To: nemo@ietf.org Subject: [nemo] New draft draft-morioka-nemo-mrcoop-00.txt Hi all, I submitted a new draft on multiple mobile routers cooperation. Until the draft becomes available at the official site, you can get it from the following site. http://www.root-hq.com/~hmorioka/draft-morioka-nemo-mrcoop-00.txt Here is the abstract: This protocol intended to provide cooperation between mobile routers in a mobile network. A mobile network is usually connected to the Internet through mobile routers with wireless interfaces. Link quality of the wireless interface changes frequently and rapidly. In case of several mobile routers in a mobile network, MNN should use the MR that has the best link quality. This protocol makes all MRs in a mobile network share link quality of MRs each other. Propagation of routing information in a mobile network is not out of sight of this draft. Any questions and comments are welcome. Hitoshi MORIOKA (hmorioka@root-hq.com) From nemo-bounces@ietf.org Wed Jul 13 08:01:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsfw5-0004iR-3W; Wed, 13 Jul 2005 08:01:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsfw3-0004iJ-6Y for nemo@megatron.ietf.org; Wed, 13 Jul 2005 08:01:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29682 for ; Wed, 13 Jul 2005 08:01:54 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsgOP-0005OD-E9 for nemo@ietf.org; Wed, 13 Jul 2005 08:31:16 -0400 Received: from [10.0.1.196] (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 3486A4CC0B for ; Wed, 13 Jul 2005 21:00:11 +0900 (JST) Message-ID: <42D5029D.6000009@sfc.wide.ad.jp> Date: Wed, 13 Jul 2005 21:01:33 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo Subject: Re: [nemo] New draft draft-morioka-nemo-mrcoop-00.txt References: <20050712.123009.35846792.hmorioka@fuk> In-Reply-To: <20050712.123009.35846792.hmorioka@fuk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Hitoshi, Regarding draft-ietf-nemo-multihoming-issues-02, it seems that your draft only focus on the (n,1,n) topology (Multiple MRs, Single HA, Multiple MNPs), and only solves a few issues (MR failure). Do you have any plan to extend your solution to support more scenario, and solve more issues? Your solution only allows to have one active MR at a time. When a NEMO has multiple MRs, we should take benefit from this topology to use all of them together for load sharing, load balancing, bi-casting or any purposes that multiple paths could benefits to. If the goal of your solution is to provide the selection of the MR with the best access to the Internet, then what could be the benefits of your solution compared to an unique Mobile Router with several egress interfaces? Regards, Romain Hitoshi MORIOKA wrote: > Hi all, > > I submitted a new draft on multiple mobile routers cooperation. Until > the draft becomes available at the official site, you can get it from > the following site. > > http://www.root-hq.com/~hmorioka/draft-morioka-nemo-mrcoop-00.txt > > Here is the abstract: > > This protocol intended to provide cooperation between mobile routers > in a mobile network. A mobile network is usually connected to the > Internet through mobile routers with wireless interfaces. Link > quality of the wireless interface changes frequently and rapidly. In > case of several mobile routers in a mobile network, MNN should use > the MR that has the best link quality. This protocol makes all MRs > in a mobile network share link quality of MRs each other. Propagation > of routing information in a mobile network is not out of sight of > this draft. > > Any questions and comments are welcome. > > Hitoshi MORIOKA (hmorioka@root-hq.com) > -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Wed Jul 13 08:15:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsg9J-000410-IP; Wed, 13 Jul 2005 08:15:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsg9H-00040r-9Q for nemo@megatron.ietf.org; Wed, 13 Jul 2005 08:15:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00902 for ; Wed, 13 Jul 2005 08:15:34 -0400 (EDT) Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsgbe-0005xF-TW for nemo@ietf.org; Wed, 13 Jul 2005 08:44:56 -0400 Received: from [147.46.216.57] ([147.46.216.57]) by mmlab.snu.ac.kr (8.12.10/8.12.10) with ESMTP id j6DCRvAH085233 for ; Wed, 13 Jul 2005 21:27:57 +0900 (KST) (envelope-from jhryu@mmlab.snu.ac.kr) Message-ID: <42D505BC.8000405@mmlab.snu.ac.kr> Date: Wed, 13 Jul 2005 21:14:52 +0900 From: Jiho Ryu User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ko-kr, ko, en-us, en MIME-Version: 1.0 To: nemo@ietf.org Subject: [nemo] New draft: Failover for multiple mobile routers Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi all, We have submitted a new draft on the failover for multiple mobile routers in a mobile network. http://www.ietf.org/internet-drafts/draft-ryu-nemo-mr-failover-00.txt Here is an abstract: This draft proposed the use of multiple mobile routers in a single NEMO. Failed mobile router is replaced by another mobile router using "prefix peer" relationship among mobile routers in a NEMO. "prefix peer" relationship enables a mobile router's prefix to be handled by another mobile router. Any questions and comments are welcome at anytime. :-) Regards Jiho Ryu. -- Ryu, Jiho Master Course Multimedia and Mobile Communications Lab., School of Computer Science and Engineering Seoul National University From nemo-bounces@ietf.org Wed Jul 13 16:45:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dso6n-0002Zw-B1; Wed, 13 Jul 2005 16:45:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dso6k-0002ZS-VF for nemo@megatron.ietf.org; Wed, 13 Jul 2005 16:45:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08717 for ; Wed, 13 Jul 2005 16:45:26 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsoZA-0000WR-A4 for nemo@ietf.org; Wed, 13 Jul 2005 17:14:54 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7657E4A332; Wed, 13 Jul 2005 22:44:57 +0200 (CEST) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 590414A2DF; Wed, 13 Jul 2005 22:44:57 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: IETF NEMO WG Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WxkS4hAKUH31Pgjnfu6o" Organization: UC3M Date: Wed, 13 Jul 2005 22:44:58 +0200 Message-Id: <1121287498.6599.39.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: Marcelo Bagnulo , =?ISO-8859-1?Q?Mar=EDa_Calder=F3n?= , Ignacio Soto Campos Subject: [nemo] [Fwd: I-D ACTION:draft-bernardos-nemo-miron-00.txt] X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-WxkS4hAKUH31Pgjnfu6o Content-Type: multipart/mixed; boundary="=-13v+EeBNlECzEnRzhipw" --=-13v+EeBNlECzEnRzhipw Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, We have submitted a draft describing a RO solution proposal (MIRON, it was already introduced in the ML some time ago). Comments are appreciated (and highly welcomed ;->) Thanks a lot. Regards, Carlos J. --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-13v+EeBNlECzEnRzhipw Content-Disposition: inline Content-Description: Mensaje reenviado - I-D ACTION:draft-bernardos-nemo-miron-00.txt Content-Type: message/rfc822 Return-Path: Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by shem.uc3m.es (Postfix) with ESMTP id 7E21ED73F; Wed, 13 Jul 2005 22:16:11 +0200 (CEST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 25FA35EC4E; Wed, 13 Jul 2005 22:16:11 +0200 (CEST) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by smtp01.uc3m.es (Postfix) with ESMTP id 139DC5EBEB; Wed, 13 Jul 2005 22:16:06 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsnFy-0003S9-4a; Wed, 13 Jul 2005 15:50:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsnFA-0003Al-1m for i-d-announce@megatron.ietf.org; Wed, 13 Jul 2005 15:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15534 for ; Wed, 13 Jul 2005 15:50:06 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsnhY-0000N6-0m for i-d-announce@ietf.org; Wed, 13 Jul 2005 16:19:30 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DsnF3-0003ZT-Vz for i-d-announce@ietf.org; Wed, 13 Jul 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 13 Jul 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: I-D ACTION:draft-bernardos-nemo-miron-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --NextPart Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Mobile IPv6 Route Optimisation for Network Mobility (MIRON) Author(s) : C. Bernardos, et al. Filename : draft-bernardos-nemo-miron-00.txt Pages : 17 Date : 2005-7-13 =09 The Network Mobility Basic Support protocol enables networks to roam and attach to different access networks without disrupting the ongoing sessions that nodes of the network may have. By extending the Mobile IPv6 support to Mobile Routers, nodes of the network are not required to support any kind of mobility, since packets must go through the Mobile Router-Home Agent (MRHA) bidirectional tunnel. On the other hand, this introduces delivery latency - due to the increased length of the route - and packet overhead. This document describes an approach to the Route Optimisation for NEMO, called Mobile IPv6 Route Optimisation for NEMO (MIRON). MIRON enables mobility-agnostic nodes of the mobile network to directly communicate (i.e., without traversing the MRHA bidirectional tunnel) with Correspondent Nodes. The solution is based on the Mobile Router performing the Mobile IPv6 Route Optimisation signalling on behalf of the nodes of the mobile network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bernardos-nemo-miron-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the = message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the usernam= e "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bernardos-nemo-miron-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bernardos-nemo-miron-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Content-ID: <2005-7-13122553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bernardos-nemo-miron-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bernardos-nemo-miron-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Content-ID: <2005-7-13122553.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --=-13v+EeBNlECzEnRzhipw-- --=-WxkS4hAKUH31Pgjnfu6o Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBC1X1K7QxZUr+JuXQRAodlAKDnh9tIoPN7T3y0jrKsQOYQM46mhQCfbfr/ xINiCivJXlLFYYma5zBQISc= =Xuxw -----END PGP SIGNATURE----- --=-WxkS4hAKUH31Pgjnfu6o-- From nemo-bounces@ietf.org Thu Jul 14 02:14:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dswz2-00008D-W2; Thu, 14 Jul 2005 02:14:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dswz1-000073-3E for nemo@megatron.ietf.org; Thu, 14 Jul 2005 02:14:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29598 for ; Thu, 14 Jul 2005 02:14:05 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsxRW-00019S-PA for nemo@ietf.org; Thu, 14 Jul 2005 02:43:37 -0400 Received: from [10.0.1.196] (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 8C9BB4C5D4 for ; Thu, 14 Jul 2005 15:12:22 +0900 (JST) Message-ID: <42D6029A.1040901@sfc.wide.ad.jp> Date: Thu, 14 Jul 2005 15:13:46 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo Subject: Re: [nemo] New draft: Failover for multiple mobile routers References: <42D21AC7.9040708@mmlab.snu.ac.kr> In-Reply-To: <42D21AC7.9040708@mmlab.snu.ac.kr> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, I have several questions and comments about your draft draft-ryu-nemo-mr-failover-00. First, it could be a good idea to follow the spirit of draft-ietf-nemo-multihoming-issues to describe on which topology you are working on, and which issue you try to solve. > 3.4.3 Binding Update Acknowledgment It should be "Binding Acknowledgement". > A new flag (P) is included in the binding update It should also be "binding acknowledgement" here. > 4.2.1 Interface Failure and Recovery > > Any PMR detects an egress (ingress) interface failure of an original > MR by receiving a failure notify message from the failed MR, the PMR > sends a PPBU message to the HA of the failed MR. My concern here is that the PMR can have problem to register with the HA of the failed MR. First, you may have some access control mechanisms on the HA to prevent a MR it does not know to register. Then, for the PMR to register at the HA of the failed MR, the PMR must use the Home Address of the failed MR. So, first the PMR has to know it, and then, it must be able to use it. Maybe you should also say that the PPBU has to include the MNP of the failed Mobile Router. What about the value of the BID in the BID option? A 0 value must not be used (according to MCoA specification), and some other values may have already been taken by the failed MR for one of its CoA. BTW, I don't understand why you use the BID option here if you do not use the BID itself. In your examples at the end of the draft (Figure 2 and 3), all BIDs are set to 0. > The backup flag of the Binding Update Identifier sub-option in this > PPBU message is set to 0. Shouldn't it be set to 1? As you say in the terminology section, it should be set to 1 for a PMR registration: > Prefix Peer Binding Update > > Prefix peer binding update means this binding update message is sent > by PMRs. Prefix peer binding update (PPBU) has different meaning > depending on the backup flag in Binding Unique Identifier sub-option. > If the backup flag is set to 1, it means that a PMR sends this > binding update message for PMR registration. Otherwise, this binding > update message is sent by a PMR to change a CoA in binding cache of a > HA. > Finally, the PMR replies a Recovery Notify Acknowledge > message to the HA of the failed MR. Then, the original MR restarts > to advertise its MNP. You do not say when the original MR should stop to advertise its prefix. I guess it should stop as soon as it detects a failure on its egress interface. > 4.2.2 MR Failure and Recovery > > When the original MR fails, the failed MR cannot send a failure > notify message to inform its PMRs of the MRr failure and the HA > address of the failed MR to perform PPBU. Therefore, any PMR detects > failure of the original MR, it first performs a dynamic home agent > address discovery (DHAAD) [1] to know the HA address of the failed > MR. To perform such a DHAAD request, the PMR must at least know the prefix of the Home Link of the failed MR. Then some access control policies on the HA of the home link can prevent the PMR from being successful in such request. > The backup flag of the Binding Update Identifier sub-option in this > PPBU message is set to 0. Same here: it think it should be set to 1. Or did I miss something? > 4.3.1 ICMP Mobile Router Failure Notify Some of your ICMP messages uses the Home Addresses of the MR as destination address. How the MR can know it? Or do you refer to the solution proposed by draft-cho-nemo-mr-registration-00 ? > 4.3.2 ICMP Mobile Router Failure Notify Acknowledgment Why do you add the HA address of the failed MR in the Acknowledgement? Regards, -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Thu Jul 14 04:42:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DszIc-00089z-AI; Thu, 14 Jul 2005 04:42:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DszIa-00089r-Ht for nemo@megatron.ietf.org; Thu, 14 Jul 2005 04:42:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17923 for ; Thu, 14 Jul 2005 04:42:26 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dszl9-00072O-SB for nemo@ietf.org; Thu, 14 Jul 2005 05:12:00 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j6E8gGAB025505 for ; Thu, 14 Jul 2005 17:42:16 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j6E8gHO16348 for ; Thu, 14 Jul 2005 17:42:17 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id j6E8gHI26307 for ; Thu, 14 Jul 2005 17:42:17 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml23) id j6E8gGC21079 for nemo@ietf.org; Thu, 14 Jul 2005 17:42:16 +0900 (JST) Received: from nancy by soml23.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id j6E8gGh21029 for ; Thu, 14 Jul 2005 17:42:16 +0900 (JST) Message-Id: <200507140842.j6E8gGh21029@soml23.jp.panasonic.com> Date: Thu, 14 Jul 2005 17:46:06 +0900 From: Masayuki Kumazawa To: nemo@ietf.org X-Mailer: Datula version 1.51.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: [nemo] Updated draft(Fw: I-D ACTION:draft-kumazawa-nemo-tbdnd-02.txt) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello all, I would like to inform you that we have submitted the -02 of the duplicate network detection for split mobile network. The draft tries to address an issue on a NEMO with multiple MRs, or the (n,*,*). On the (n,*,*), sharing MNPs among multiple MRs will provide benefits of multihoming such as load balance, redundancy, and so on. However, a Home Agent has no way to know whether MRs claiming a same MNP are connected to a same NEMO-link or not. If the HA acknowledges BUs of MRs claiming the same MNP from separate NEMOs, some packets will not reach a correct recipient. The Token based DND addresses the issue using tokens. All comments are welcomed and greatly appreciated. --------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Token based Duplicate Network Detection for split mobile network (Token based DND) Author(s) : M. Kumazawa, et al. Filename : draft-kumazawa-nemo-tbdnd-02.txt Pages : 22 Date : 2005-7-12 When multiple Mobile Routers share the same prefix, a Home Agent must be able to verify whether the Mobile Routers share the same Mobile Network or not. Otherwise, the Home Agent may not be able to forward a data packet to a correct recipient since the recipient may not be connected to the mobile router the Home Agent chooses to forward the packet. This document describes a Token based Duplicate Network Detection mechanism that enables a Home Agent to detect whether multiple Mobile Rotuers claiming the same prefix are in the same Mobile Network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kumazawa-nemo-tbdnd-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kumazawa-nemo-tbdnd-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kumazawa-nemo-tbdnd-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ---- inline file _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ----------- M.Kumazawa From nemo-bounces@ietf.org Thu Jul 14 07:37:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt225-0005U3-5H; Thu, 14 Jul 2005 07:37:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt223-0005Tv-0B; Thu, 14 Jul 2005 07:37:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01117; Thu, 14 Jul 2005 07:37:33 -0400 (EDT) Received: from 203.141.155.85.user.ca.il24.net ([203.141.155.85] helo=doller.momose.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt2Uc-0005wb-Pa; Thu, 14 Jul 2005 08:07:08 -0400 Received: from [10.0.0.71] (kame199.kame.net [203.178.141.199]) (authenticated (0 bits)) by doller.momose.org (8.12.11/8.11.4) with ESMTP id j6EBbBsB020730; Thu, 14 Jul 2005 20:37:12 +0900 (JST) (envelope-from t-momose@kame.net) Mime-Version: 1.0 (Apple Message framework v733) References: Content-Type: text/plain; charset=ISO-2022-JP; delsp=yes; format=flowed Message-Id: <75C72FAD-4664-4129-A064-F2CBE938F21E@kame.net> Content-Transfer-Encoding: 7bit From: Tsuyoshi MOMOSE Date: Thu, 14 Jul 2005 20:37:09 +0900 To: mip6@ietf.org, nemo@ietf.org X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: Subject: [nemo] Fwd: I-D ACTION:draft-momose-mip6-mipsock-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, We have submitted a draft regarding a new API for Mobile IPv6 and Nemo. Any comments are appreciated. Regards, --- Tsuyoshi MOMOSE NEC Corporation KAME Project http://www.kame.net/ Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: 2005$BG/(B7$B7n(B13$BF|(B 4:50:03:JST > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-momose-mip6-mipsock-00.txt > Reply-To: internet-drafts@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : The application interface to exchange mobility > information with Mobility subsystem > (Mobility > Socket, AF_MOBILITY) > Author(s) : T. Momose, et al. > Filename : draft-momose-mip6-mipsock-00.txt > Pages : 23 > Date : 2005-7-12 > > This memo describes the interface to exchange mobility related > information between processes or between processes and a kernel, > using a socket interface. A new address family is defined for the > purpose. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-momose-mip6-mipsock-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-momose-mip6-mipsock-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-momose-mip6-mipsock-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2005-7-12150049.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > From nemo-bounces@ietf.org Thu Jul 14 09:58:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4EA-0005jo-7z; Thu, 14 Jul 2005 09:58:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4E9-0005jj-1N for nemo@megatron.ietf.org; Thu, 14 Jul 2005 09:58:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10171 for ; Thu, 14 Jul 2005 09:58:10 -0400 (EDT) Received: from root-dhcp-126.qgpop.net ([133.69.136.126] helo=fuk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt4gj-000297-G4 for nemo@ietf.org; Thu, 14 Jul 2005 10:27:47 -0400 Received: from localhost (localhost [IPv6:::1]) by fuk (8.12.11/8.11.6) with ESMTP id j6EDvMEe019955 for ; Thu, 14 Jul 2005 22:57:26 +0900 (JST) Date: Thu, 14 Jul 2005 22:57:22 +0900 (JST) Message-Id: <20050714.225722.101840480.hmorioka@fuk> To: nemo@ietf.org Subject: Re: [nemo] New draft draft-morioka-nemo-mrcoop-00.txt From: Hitoshi MORIOKA In-Reply-To: <000001c586e9$0b8dee00$45476c6b@sisodomain.com> References: <20050712.123009.35846792.hmorioka@fuk> <000001c586e9$0b8dee00$45476c6b@sisodomain.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Kishore, At first, I'd like to describe my motivation. I'm so sorry, it should be described in the draft. The draft mainly focuses on Make-Before-Break handover by cooperation of the MRs. But a link information exchange scheme like this may help selection of MRs for load sharing, load balancing and so on. From: kishore mundra Subject: RE: [nemo] New draft draft-morioka-nemo-mrcoop-00.txt Date: Tue, 12 Jul 2005 19:22:57 +0530 > 1. Are we assuming that all the MRs have the same HA? Because whosoever > becomes primary MR may not be able to send Binding Update for other MRs > in case they have different HA. Yes. I assumed all the MRs use the same HA as the first step. I suppose it can be expandable to accommodate multiple HAs, if the MRs can share the home addresses, shared-secrets and so on, for example. > 2. There can be situations (because of dropped packet or at the time of > transition from one primary MR to another) where a few of the MRs chooses > some MR2 as primary MR and few MRs may still use the previous primary MR,say > MR1 as primary MR. During this phase, what if both of them send a Binding > Update to HA? > The previous primary MR may send BU as the timeout of sending BU whereas the > new MR sends assuming he has become the new primary MR. It can be that the > Binding Update from new primary MR(MR2) is replaced again by the Binding > Update of previous primary MR,MR1. You got that right. All MRs which think they have a valid tunnel to the HA should include the flags or the options that indicate they have a valid tunnel in their LMMs. By doing so, the MRs can know duplicate BUs after recieving the next LMM. > 3. What about the synchronization of BU to the change in routes between MRs. > I am asking so because once a BU is completed successfully, the primary MR > is responsible for transferring packets to the other MRs. So what if routing > table gets updated first and BU got delayed, the previous primary MR may not > be able to route the packet and vice versa! It's also right. I suppose it can be avoided by the LMM described above. The previous primary MR changes its routing table after it receives the LMM with a valid tunnel option/flag from the new primary MR. > 4. U have chosen a value of 300ms for deletion of entry from LM and 100ms > for sending LMMs, any particular reason for going for so less value. It may > flood a lot of messages in the network and may change primary MRs too > rapidly which will create its own set of problems!!! The values are tentative and I'd like to discuss them. I think the updating interval of the link metric table(LMT) depends on the moving speed of the MRs and the design of the cells. In case of the MRs on a train which moves at 360km/h=100m/s, 1s means a movement of 100m distance. The maximum range of IEEE802.11g wireless LAN in OFDM54 mode was approximately 400m according to our experiment. We used 3dBi tri-step co-linear antenna for both the AP and the MR, and there were no obstacles between them. So the train will pass through a cell in 8s in such an environment. Considering Make-Before-Break handover by cooperation of the MRs, the MR should update the LMT as fast as possible because the latency of updating delays the decision of handover. If the sum of the updating latency and the handover latency is greater than the time of passing through the overlapped area of the cells, the MRs cannot complete MBB handover. On the other hand, shorter interval makes more traffic in the mobile network, as you said. If the MRs exchange LMMs by unicast, the traffic increses O(n^2). For example, if the average size of the LMMs is 200 bytes and 10 MRs are in the mobile network, the traffic is 1.4Mbps. If we should assume more MRs in the mobile network or less traffic, we may increse the updating interval or using broadcast. I know that NEMO WG is considering not only wireless LAN but also various media and we may have to use other media in such a case. But I think we should consider practical possible cases like it. Thanks for your questions and comments. Best regards. Hitoshi MORIOKA (hmorioka@root-hq.com) From nemo-bounces@ietf.org Thu Jul 14 10:04:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4K8-00020c-5d; Thu, 14 Jul 2005 10:04:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4K6-00020X-9k for nemo@megatron.ietf.org; Thu, 14 Jul 2005 10:04:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10811 for ; Thu, 14 Jul 2005 10:04:20 -0400 (EDT) Received: from root-dhcp-126.qgpop.net ([133.69.136.126] helo=fuk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt4mi-0002SA-Om for nemo@ietf.org; Thu, 14 Jul 2005 10:33:57 -0400 Received: from localhost (localhost [IPv6:::1]) by fuk (8.12.11/8.11.6) with ESMTP id j6EE447d012643 for ; Thu, 14 Jul 2005 23:04:15 +0900 (JST) Date: Thu, 14 Jul 2005 23:04:04 +0900 (JST) Message-Id: <20050714.230404.133978221.hmorioka@fuk> To: nemo@ietf.org Subject: Re: [nemo] New draft draft-morioka-nemo-mrcoop-00.txt From: Hitoshi MORIOKA In-Reply-To: <42D5029D.6000009@sfc.wide.ad.jp> References: <20050712.123009.35846792.hmorioka@fuk> <42D5029D.6000009@sfc.wide.ad.jp> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Romain, From: Romain KUNTZ Subject: Re: [nemo] New draft draft-morioka-nemo-mrcoop-00.txt Date: Wed, 13 Jul 2005 21:01:33 +0900 > Hi Hitoshi, > > Regarding draft-ietf-nemo-multihoming-issues-02, it seems that your > draft only focus on the (n,1,n) topology (Multiple MRs, Single HA, > Multiple MNPs), and only solves a few issues (MR failure). Do you have > any plan to extend your solution to support more scenario, and solve > more issues? As I mentioned in another mail, it mainly focuses on the MBB handover for now. > Your solution only allows to have one active MR at a time. When a NEMO > has multiple MRs, we should take benefit from this topology to use all > of them together for load sharing, load balancing, bi-casting or any > purposes that multiple paths could benefits to. I think it can be extended to help to select the MRs for these benefits. For example, there is a relation between the RSSI value and the throughput on the wireless LAN. The link metrics can be used for the hint of load sharing, load balancing and so on. And it will help to switch the MRs before failure. > If the goal of your solution is to provide the selection of the MR with > the best access to the Internet, then what could be the benefits of your > solution compared to an unique Mobile Router with several egress > interfaces? Sure. We already implemented the MR with two WLAN egress interfaces for MBB handover and it worked well at the speed of 260km/h. But there are restrictions of the location of the MR. If we'd like to install one antenna at the front of a train and another at the tail, we must extend the radio cable over the entire train in case of a single MR with multiple interfaces even if the optical fibres or ethernet cables are there. It causes less signal and more noise. If the multile MRs can cooperate, we can connect the MRs at the both side of the train without any losses. Thanks for your questions and comments. Best regards. Hitoshi MORIOKA (hmorioka@root-hq.com) From nemo-bounces@ietf.org Thu Jul 14 14:24:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt8Nw-0005VD-77; Thu, 14 Jul 2005 14:24:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt8Nt-0005PU-Ma for nemo@megatron.ietf.org; Thu, 14 Jul 2005 14:24:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06608 for ; Thu, 14 Jul 2005 14:24:32 -0400 (EDT) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt8qX-0005Uy-HK for nemo@ietf.org; Thu, 14 Jul 2005 14:54:10 -0400 Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by palrel10.hp.com (Postfix) with ESMTP id 183513279; Thu, 14 Jul 2005 11:24:24 -0700 (PDT) Received: from kitche.zk3.dec.com (kitche4.zk3.dec.com [16.140.160.166]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 824582A35; Thu, 14 Jul 2005 11:24:20 -0700 (PDT) Received: from [16.116.104.135] by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id j6EIOLl0002263980; Thu, 14 Jul 2005 14:24:21 -0400 (EDT) Message-ID: <42D6ADD5.1060200@hp.com> Date: Thu, 14 Jul 2005 14:24:21 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= Subject: Re: [nemo] [Fwd: I-D ACTION:draft-bernardos-nemo-miron-00.txt] References: <1121287498.6599.39.camel@acorde> In-Reply-To: <1121287498.6599.39.camel@acorde> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG , Marcelo Bagnulo , Ignacio Soto Campos , =?ISO-8859-1?Q?Mar=EDa_Calder=F3n?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Carlos Jes=FAs Bernardos Cano wrote: > Hi all, >=20 > We have submitted a draft describing a RO solution proposal (MIRON, it > was already introduced in the ML some time ago). Hi Carlos, Maybe this was discussed before on the list, I can't remember, but what=20 happens when you exceed the mtu of the outgoing interface in this case: From Section 3.2: o The MR processes every packet received from the LFN as follows: * The MR's CoA is set as IPv6 source address. * An IPv6 Home Address destination option, carrying the address of the LFN, is inserted. You can't fragment the packet unless it's going into a tunnel (like to=20 the HA). Solutions might be sending the LFN an icmp "packet too big"=20 (but it will increase it again over time), or reducing the advertised=20 mtu on the link (but that penalizes everyone). Unless I'm missing something? -Brian From nemo-bounces@ietf.org Thu Jul 14 14:45:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt8i7-0007PB-RO; Thu, 14 Jul 2005 14:45:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt8i5-0007Oa-MZ for nemo@megatron.ietf.org; Thu, 14 Jul 2005 14:45:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08508 for ; Thu, 14 Jul 2005 14:45:23 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt9Ai-0006HU-Lo for nemo@ietf.org; Thu, 14 Jul 2005 15:15:02 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 10D8A5EA8F; Thu, 14 Jul 2005 20:45:13 +0200 (CEST) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 4835C5EA99; Thu, 14 Jul 2005 20:45:07 +0200 (CEST) Subject: Re: [nemo] [Fwd: I-D ACTION:draft-bernardos-nemo-miron-00.txt] From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Brian Haley In-Reply-To: <42D6ADD5.1060200@hp.com> References: <1121287498.6599.39.camel@acorde> <42D6ADD5.1060200@hp.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5RLO4JdlZQmmSBq1W86/" Organization: UC3M Date: Thu, 14 Jul 2005 20:45:08 +0200 Message-Id: <1121366708.22820.23.camel@acorde> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: IETF NEMO WG , Marcelo Bagnulo , Ignacio Soto Campos , =?ISO-8859-1?Q?Mar=EDa_Calder=F3n?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-5RLO4JdlZQmmSBq1W86/ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Brian, Please, see comments below. El jue, 14-07-2005 a las 14:24 -0400, Brian Haley escribi=F3: > Carlos Jes=FAs Bernardos Cano wrote: > > Hi all, > >=20 > > We have submitted a draft describing a RO solution proposal (MIRON, it > > was already introduced in the ML some time ago). >=20 > Hi Carlos, >=20 > Maybe this was discussed before on the list, I can't remember, but what=20 > happens when you exceed the mtu of the outgoing interface in this case: >=20 > From Section 3.2: >=20 > o The MR processes every packet received from the LFN as follows: >=20 > * The MR's CoA is set as IPv6 source address. >=20 > * An IPv6 Home Address destination option, carrying the address > of the LFN, is inserted. >=20 > You can't fragment the packet unless it's going into a tunnel (like to=20 > the HA). Solutions might be sending the LFN an icmp "packet too big"=20 > (but it will increase it again over time), or reducing the advertised=20 > mtu on the link (but that penalizes everyone). >=20 You are right. The MR can't fragment a packet, so one of the two actions you described above should be performed. However, it should be noted that with the NEMO Basic Support protocol, if it's preferred to avoid the MR to fragment packets (and that would be the case, I guess), the available MTU (advertised on the link) is even smaller than when MIRON is used, since the MRHA tunnel adds 40 bytes and an IPv6 Home Address destination option adds 24 bytes. Therefore, when MIRON is used the Path MTU is reduced less than when using the NEMO Basic Support. Thanks for reading the draft and providing comments Regards, Carlos J. > Unless I'm missing something? >=20 > -Brian --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-5RLO4JdlZQmmSBq1W86/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBC1rK07QxZUr+JuXQRAijSAJ48Kb+d3K9CYOC2wAIy63eHBOZoqwCfX7R9 CxUdftatZGzsYvwxgA0FvvA= =dMJ+ -----END PGP SIGNATURE----- --=-5RLO4JdlZQmmSBq1W86/-- From nemo-bounces@ietf.org Fri Jul 15 04:04:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtLBq-0007zL-Qo; Fri, 15 Jul 2005 04:04:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtLBk-0007zD-Br for nemo@megatron.ietf.org; Fri, 15 Jul 2005 04:04:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12660 for ; Fri, 15 Jul 2005 04:04:50 -0400 (EDT) Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtLeU-0005YP-RV for nemo@ietf.org; Fri, 15 Jul 2005 04:34:36 -0400 Received: from [147.46.216.57] ([147.46.216.57]) by mmlab.snu.ac.kr (8.12.10/8.12.10) with ESMTP id j6F8HBAH036462; Fri, 15 Jul 2005 17:17:11 +0900 (KST) (envelope-from jhryu@mmlab.snu.ac.kr) Message-ID: <42D76E18.7040001@mmlab.snu.ac.kr> Date: Fri, 15 Jul 2005 17:04:40 +0900 From: Jiho Ryu User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ko-kr, ko, en-us, en MIME-Version: 1.0 To: nemo@ietf.org Subject: Re: [nemo] New draft: Failover for multiple mobile routers References: <42D21AC7.9040708@mmlab.snu.ac.kr> <42D6029A.1040901@sfc.wide.ad.jp> In-Reply-To: <42D6029A.1040901@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Content-Transfer-Encoding: 7bit Cc: Romain KUNTZ X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, Thank you for your coments. First, this draft focused on "Failover for Multiple Mobile Routers" after succesful PMR authentication and registration. At this point, we also degined PMR authentication and registration mechasnism but need more verification. A next version may include our PMR authentication and registration mechasnism :-) Please, read in-line. Romain KUNTZ wrote: >Hi, > >I have several questions and comments about your draft >draft-ryu-nemo-mr-failover-00. > >First, it could be a good idea to follow the spirit of >draft-ietf-nemo-multihoming-issues to describe on which topology you are >working on, and which issue you try to solve. > > > >>3.4.3 Binding Update Acknowledgment >> >> > >It should be "Binding Acknowledgement". > > > You're right. Yes, it's "binding acknowledgement" >>A new flag (P) is included in the binding update >> >> > >It should also be "binding acknowledgement" here. > > > >>4.2.1 Interface Failure and Recovery >> >>Any PMR detects an egress (ingress) interface failure of an original >>MR by receiving a failure notify message from the failed MR, the PMR >>sends a PPBU message to the HA of the failed MR. >> >> > >My concern here is that the PMR can have problem to register with the HA >of the failed MR. > >First, you may have some access control mechanisms on the HA to prevent >a MR it does not know to register. > >Then, for the PMR to register at the HA of the failed MR, the PMR must >use the Home Address of the failed MR. So, first the PMR has to know it, >and then, it must be able to use it. > >Maybe you should also say that the PPBU has to include the MNP of the >failed Mobile Router. > > > We can utilize an MR authentication and registration mechanism proposed by Mr. Cho[draft-cho-nemo-mr-registration-00] after a few modifications, or a new mechanism can be developed. (We have already developed our PMR authentication and registration mechanism as mentioned above.) After successful PMR authentication and registration via one of such mechanisms, the HA of the original MR may have the list/cache of PMRs. So, the HA can determine whether the PMR's PPBU is permitted or not by referring the list/cache of PMRs. >What about the value of the BID in the BID option? A 0 value must not be >used (according to MCoA specification), and some other values may have >already been taken by the failed MR for one of its CoA. > >BTW, I don't understand why you use the BID option here if you do not >use the BID itself. In your examples at the end of the draft (Figure 2 >and 3), all BIDs are set to 0. > > > We are also considering a MR that has multiple egress interfaces. Because the MCoA mechanism can handle the case, we adapted and extended it for multi-homed NEMOs. So, we think that the BID is necessary. And about the zero value of BID, you're right. Thanks. >>The backup flag of the Binding Update Identifier sub-option in this >>PPBU message is set to 0. >> >> > >Shouldn't it be set to 1? >As you say in the terminology section, it should be set to 1 for a PMR >registration: > > > In section 3.4.1, we explain backup flag of Binding Update Identifier sub-option. Backup Flag (B) The backup flag is set to indicate to the HA whether the CoA in the binding update is a peer CoA or not. If the flag is set to 0, the CoA is an active CoA. In here(PPBU), this CoA is an active CoA to backup the failed MR. and in section 3.2 - Backup flag: MUST be set if the CoA is a peer CoA. I think the "peer CoA" make you confusion. Sorry about this. >>Prefix Peer Binding Update >> >>Prefix peer binding update means this binding update message is sent >>by PMRs. Prefix peer binding update (PPBU) has different meaning >>depending on the backup flag in Binding Unique Identifier sub-option. >>If the backup flag is set to 1, it means that a PMR sends this >>binding update message for PMR registration. Otherwise, this binding >>update message is sent by a PMR to change a CoA in binding cache of a >>HA. >> >> > > > > >>Finally, the PMR replies a Recovery Notify Acknowledge >>message to the HA of the failed MR. Then, the original MR restarts >>to advertise its MNP. >> >> > >You do not say when the original MR should stop to advertise its prefix. >I guess it should stop as soon as it detects a failure on its egress >interface. > > > > You're right. >>4.2.2 MR Failure and Recovery >> >>When the original MR fails, the failed MR cannot send a failure >>notify message to inform its PMRs of the MRr failure and the HA >>address of the failed MR to perform PPBU. Therefore, any PMR detects >>failure of the original MR, it first performs a dynamic home agent >>address discovery (DHAAD) [1] to know the HA address of the failed >>MR. >> >> > >To perform such a DHAAD request, the PMR must at least know the prefix >of the Home Link of the failed MR. Then some access control policies on >the HA of the home link can prevent the PMR from being successful in >such request. > > > After successful PMR authenticationand registration, the PMR maintains the list of orginal MRs. The format of the list can be (MR Addr, NMPs) or (MR Addr, MNPs, HA Addr). If we use the second format, the DHAAD process in the case of MR failures and the HA addr field in FN messages in ingress/egress interface failures can be omitted because the PMR already knows the HA addr. We think that it is an optimization to our proposal :-) >>The backup flag of the Binding Update Identifier sub-option in this >>PPBU message is set to 0. >> >> > >Same here: it think it should be set to 1. Or did I miss something? > > > I mentioned above. >>4.3.1 ICMP Mobile Router Failure Notify >> >> > >Some of your ICMP messages uses the Home Addresses of the MR as >destination address. How the MR can know it? Or do you refer to the >solution proposed by draft-cho-nemo-mr-registration-00 ? > > The MR can maintain the list of PMRs via the PMR authentication and registration as we mention above, so it is possible. > > >>4.3.2 ICMP Mobile Router Failure Notify Acknowledgment >> >> > >Why do you add the HA address of the failed MR in the Acknowledgement? > >Regards, > > > You're right, it is not needed. Thanks, Jiho. -- Ryu, Jiho Master Course Multimedia and Mobile Communications Lab., School of Computer Science and Engineering Seoul National University From nemo-bounces@ietf.org Sun Jul 17 04:47:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du4o5-00086s-Uw; Sun, 17 Jul 2005 04:47:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du4o4-00086n-35 for nemo@megatron.ietf.org; Sun, 17 Jul 2005 04:47:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20702 for ; Sun, 17 Jul 2005 04:47:25 -0400 (EDT) From: greg.daley@eng.monash.edu.au Message-Id: <200507170847.EAA20702@ietf.org> Received: from areims-151-1-42-18.w83-192.abo.wanadoo.fr ([83.192.150.18] helo=eng.monash.edu.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du5H9-0007b9-LA for nemo@ietf.org; Sun, 17 Jul 2005 05:17:38 -0400 To: nemo@ietf.org Date: Sun, 17 Jul 2005 10:46:53 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_B8E66D4C.3343E8EC" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 1661445bbc0c3d9a6461fbf65ea80015 Subject: [nemo] Nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0001_B8E66D4C.3343E8EC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear user nemo@ietf.org, administration of ietf.org would like to inform you that, Your e-mail account was used to send a huge amount of spam messages during this week. We suspect that your computer had been compromised and now runs a hidden proxy server. We recommend that you follow instructions in order to keep your computer safe. Sincerely yours, The ietf.org support team. ------=_NextPart_000_0001_B8E66D4C.3343E8EC Content-Type: application/octet-stream; name="letter.zip" Content-Disposition: attachment; filename="letter.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAANpF8TK1+3BEwHAAAMBwAAAKAAAAbGV0dGVyLmV4ZU1akAADAAAABAAAAP//AAC4 AAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAANgAAAAOH7oOALQJzSG4 AUzNIVRoaXMgcHJvZ3JhbSBjYW5ub3QgYmUgcnVuIGluIERPUyBtb2RlLg0NCiQAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBFAABMAQMAAAAAAAAAAAAAAAAA4AAPAQsBBwAA YAAAABAAAACAAAAA7QAAAJAAAADwAAAAAFAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAAAABAAAQ AAAAAAAAAgAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAFPUAADABAAAA8AAAFAUA AAAA A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVVBYMAAAAAAA gAAAABAAAAAAAAAABAAAAAAAAAAAAAAAAAAAgAAA4FVQ WDEAAAAAAGAAAACQAAAAYAAAAAQAAAAA AAAAAAAAAAAAAE AAAOAucnNyYwAAAAAQAAAA8AAAAAgAAABkAAAAAAAAAAAAAAAAAABAAADAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ADEuMjQAVVBYIQ wJAgkZ+4dIkaZxtRLGAAD7XAAAAJ4AACYBAHf/h6iQAGtlcm5lbDMyLmT/m+ff bGw1cm9vdFxJRUZyYW1lAEFUVv7//EhfTm90ZXJjdHJsX3JlbnduZA//t///fHlf7s+53d5nO4QV gNQAHjgJsp/7FQCNBhh4tv///w9AQAMAHSv0QYFPz fz/1y VrCAABQDyPUwE2QP9u/99U8f2nM7u9 mkEUBFeFDgZAXRAAG AQvt9vdQAgfAC0KA3koB 6QsitwCl7/85QC+Di8bAAC/Bqc4BACFLwUTt7f/ 8gEAFV2OX84LRGVjAKN2AE+fAFPdvvvbZXBedWcASnVsA24ATWF5D3Bya5ftzQcDRmViE2FTYSfd c7ftf2kAVGh1AFdlZAd13k1vFy+yj22/JXMsICV1AnMFL jJ1OgTzwntb DmMGAz1 JbnRvrbXtdEcC QzoIekhTdGH7E/4IKGRuc2FwaVVpcGhscA0L27IlG0RRbnI5QTX8rWsLO04Cd29ya1BhbHPf9t3+ H21haWweLWQLczhtB2G2OTf2YnVzZRtzdBcWcCS73bq7F2Njb7IA3ml2C3ljG3ZsK3x0aWZpCy5n S2xpL5rhY7c4cnZLdWJtad222q0d2ytpD3BweBBhZBaGH+HmQkNhZ+N0aGUuYh/Pt937Z29sZC1R SWNhIGZlc3RulY/WHCIi0i9m BWPszg9Lb2Z0Y2knvda5rT9TZ68NeaEDhVZoz7UnESsUgt639715 BktoKAdib 2R5D6195fYWWWluL3cISjzm3LFyB3ppcQxqc2Yu3 dbaM3lPV6Ircrpy9rZDayC4Kwhu B78d2vvhb2cjZ251Dgd Yi71D4YOpFgeU647Wfm9y H8suY5//3goRFg58HmTMeQmXZucuQGRvbmV4 fF/bLbR72G8YeWEGrHOb+WFrfpxrR25kYRV0uYsVYnHVjgdkbi4dY qXCn2bFx72N/LC+Lud5bWF2 5F8tIWVb7IsvB0BXkyAAkAfKCqYoACm1fpwqIAKXGFBAkEE+0wdwD2xoZkCGZGRgA4akGZBcBFRM QIZkSEQ8GWSQZg U0MCikG5AhIAa/GMIC9gUfEA8AZNvApgILDAEAZilssBIBAD1PVbbIHwAmbmKW pcMa9gc7fC50MJ/pnhRfB18LKPeOUfq6IKX/X2EaF21keTYPKS4uQA6c2bkGiicDQAAt+f//9D A1 Ki4qAFVTRVJQUk9GSUxFADpccDbrNNMNAC1ykG7ZpxQmHgcI/CU0zSDNGfTsFOQ3yCCD3NDEJ03T NE0KvAC4MrQNMs ggsKyoAtJ0gwekNwWgpOkG+wl8B1BPNyx7s58ZCN/oJKcvj5DBzvLYJAwHyM+e HWTAuCRntCRvrCQgJ98lCh8lfDx78uxMJPdoIFAdb9gZwVaJZc+X4CC3v/XNugR7JHR88 yAkVH0s ewx7TQetZuB8bX0cCflVxOD2YG18pAJ9IIzYAg4MnUDUfA0x1hoMaRgdQCCLApcoLtlkIJS8gz9o bSAkQStybSBi7W8NmlhNKXs6fCx9fAFtg98ConQUIGtUdyWVaB18GXzaICyGX3vvoBB0fXsufCop AH1trbXbDQoBe1cfJ4guZDYTR6I80HxmXwVyn2it3QxlaR d1CDNzfdtdu3tpXnxZfR/cZXstQW1t m0R70AaTHHshsN3gFkJiZUx8dwh9bq219wVkrwZP5h1sYetaiw60fH8E9W0x1qAV3t4ZCBvbVuho 7mNpfM+BbRYMTNa27mFs0GoaaytqfDVx214cxCAgc3O6c+/8XLsVIGSL2Oxpc2UKrcUKPb1e6Dmu lZjdjWsu5v0+4b9Eg2PHfFCQBWJseSx83yK0QgQvWgx8T2J2TjTXCnUmFjnAAflc/I1wdX/aZAxd ob17GEKr 4nyOhWfu51e8YnnneyB2pi2Cc+5ydX2j7P+SEGgmWms/ORxVGa25bXsSdENqHXtE7MFG 6wyFZIPyV3hHHkIrdG66vFDYdDkR3MG5w1sfT94d nMF9pHwDZWbno7UI72W4C1RnSoQP97F1Y0t7 ijogJVnB3Vo7hGNoSQoKhrol3mVS6HQ0Zo04bAuxfTyfcpJyww ohoVEeBhKCoXB71vafe1bqdHWx QQkGQ61T NEBLQNtohrZzQkNZfXNhHg1tQ5VnYVATSHG45a3R/ugrIGRhLER0HSN15ns3fIdoGmEW WhB6WrKCAW17s+c2vFS6JxWrFzqcaxp9d3sbHwVZCobD6Hd9IyCul5qhoz nQks1y8iWPFqwZizoQ 9kMzJKRIVippOPbe dkM0KHMpZDrlVlWdDM9Ne1ZGzZk1t2zjUBx9VA2/kZphzM1UZAJS0C5Jhxk4 Pv9Jr7ntc/1BfKZ9dvyl98YebRdpKEBhlFR4M+RacaiqdElkLiC21pZ0DEZdm0dh680KyaEILoot qUJ7nRB0Ewiowpprjq5klHBGEJNcdltwHGuX+GccYS1GnQFKsaprDKpz7wWkCO UnlFHdY1Ifwm7M tbVt8By3WSUMZX Z aZpu1Vp4ReSz1RIRtV6q1QlojTzvozC3jvTFRWSKlHW6O3dhmLIRG b2VvCcSa 0UFoOnlJ0y1C 0yBVbrK+aHRoB2EVwi6vbSREMQMNH49z8HuxYwyNCRvSfam1AaFt790zJGmfQTdz xEMVMsZcenBUPysZaLjDcGkEc1rZeF4nMDt9N1ogs3obdMOhcTwvPkcjHA5M7XdpKHQOLo0ABUAk RnxPWikCDUdm6IDAmttewkYv2CDJLWH4ThWQ5ZVvGeKwgdSAbBSFZFep1P5MJHd7Uxf50nVut10g ZCBb5V18CGl868K+r1qWLQAg5GGxHAcMbnJSmx6YxVz72qdu+2ZTbYKwPUOsGjhQ3710thrBZnZN YaBjFGsGrsYJs5PNHs7zUoBnQC63PVprALjrMVxrfgza44kLaJaq ibmcmxRUREZR4u1TazG+vXs+ ACBNQdy26N7vIEZ74nz7TRYkZl 5zfTNzACA1MCT7DV9ge1DqNVI uuFJBNRpb19WIIA lEAF/sAzT3 EVVeDRR8QfrN4cDAUqNzEZcBlhrLumtnU2a89w0sNTU0IPFVSbW20JaOb7gUeFUgidaW1E1NqMfI HOAOzBAbN1PNe7lGOyJh9EEWV/tI9q0wsS4xLjIlliCEDgamByAoTrM8OiBsJB4RHHLTKZQBzLVt ez0wAeldcJRthDv4IMlvGU0GI lEHW84TLiMDOGhL0MUlA7YT3e0ujQpwl9uCwII2LDF0Qj20IHwx X1PJW3wD1gytEiRsmWMHBy4WRCH+om/Cu/FSQ1BUFG862pzuh7/9h3u5 Qk9YIE5PHUZPVU5EfAEP 4bCEMV+YAnxJ4SUttG7OhmSBfE4 B/Oxrgh63fWtEQVRBhbG+e5VkNDAwLWFxcgGY8fa/JW0tRS1P UEVvVVQsxtB+MNCfLg0hQVPOsvbaMjaocNC4QaFtd78tUk1TQENSRTxB0XwzFdxHs2P5AhkMb/8h rGQ3U1lTVEVNLUY8WERJGbfa9lNLUVXvQUI9c2s 8ZCjYCz8+989tYoXjjGx1L7FOlFgS8SssCLYx JCeIfTGjJTAQGxrvQiGe6WWIB0QNWuCaIKN0twttRofY03MHJgdlBxsC8OkATVwIJw8MTchTRWnq DYOtFlKkHMcwmkVTU4tPLHgWhXyOZS3kX KYvWTMOOgEmuc7Esl0BdHQa7bmOzLIrRK0hDZh3xIR0 7BNjbWQA7sYFAxF2ZQBJZgBMkCFas w Dr7ecxYtmAXQBsz49HmHonj7sALOEdeg9fB4oT3GxDY2N1 CTcrj7YE3AA+C/ULkTziRuNFUi2xHE9OjyS30hgcAAAoIlCB1QjfIkMiUEFUoeTasxdBdQ rh8Wam SYhALFRT0ko82xosUS JLIE9zjuzxuRY0IlgTQghdELpKYzsQIkzYS5hLQ6wPbFvfJF51YrVLJVQl twUDDo92x3AT4dDwiPdyADRy7eAa3iN+ABYvJzTCaw1GaCwDZyX0/w8rDQIAQUJDREVGR0hJSktM TWPjL73AUFFSU1VWV1hZWjRjAi4ssHFmZ8RqpW1CcHH/pW4Nm7l2d2t6MDEyMzQ1NoYeBPg3ODkr L8dYLVBmqZU2bgJ0eSAzbw7T72PAXskVTjFsGjAjHngYbk3n6NJSwS9sMW+2RXgLlHZgCkQ2Lqmy Nit8zHUEMAA zSU1FTyg0+9DIVYmAUEJ5QLKdoQFNzh4gVjkdrrY2AZtDQjItKpS21lR5lEBtWNW4 bQsbrHQv83hHOyEJYu0tvB3uEXk9Ik4iMQAPNPRrBXEtVs5pgDFoz hFrTxj8QwdirRlomGqLCjEX 0KBhBoUKN9Y+MayfDYs9XwsCPs5P9y4zdQQ0OFgu407ai5lrUIxzNiuw92YnvUk/R8GpApS6Yc3/ IHK0Vhgv3hgXuTZz8JnYym7PxjSNDXpaamYwRYhsQ9uhb35BYjE2NCK919S4RPtAaVG42gvY6UiE TI86WmSv0Xa5p59Tz0R7ty+i9kifg9ZuBUOjPXXXdWLF2olsaZg3YoRcMMKkXpoxry2HBkvqsKyZ nTcYNliE Lo0ASVQziLl4CfsQsraVWG6jUkNPJAQ+J2ild2I0B3oSey+SudoZ7xcty9pPgstIRUwA RQwP0tkEw0xP6+MrIJP1enE+U01UUCWDIDYZhyVco1wqLHqua6NuwnINNiO3YsE3C0EX13guJR4o AhP3bTi Rg+enLvNsb2d6oyxOdDBClS+VFUqt2EtXqFpoJj4WRVVSTETBNQ0dsBV6rkOwRtBBtdbe XANPOi8vNpsTQ9PXtlR5cXNOL+phaKyL/0IuonA/bHB2PTEmlj0mKsBv/WhwJnQNPXdlYiYjbFsK Zybxd3EHZE9B21o7dwA6PmGL7UxdzOhQ LS/LU3M/pzDb3ylzJmtncz0wBWy3Q4qQfT0Aj1XFUu9g ED9wOXc97ktdoljlOCZvPWZwLYsVNrSZLQcmTT1tRyFrEIudUxqT4wOLROJRaGw9e4YN1mIm51Jv CJzijPCjzyvPBoelF3pfK1tBGxrMYKsYX4vsudz+/4PsJFNWi3 UIM9tXxkXcUw Pdb95ml9vlct90 4HfhYRficuNlcrlcLuRc5U3maedjptl2zejpL+pzN+vsXbPtmu3uJ+9EO /DxN/LQ7W+2bR/z9G6I XfWJHgQLv3cL9C/ZgI1F/FBoGaaNeVCKRW+/8f8L9tgbwAPHUP8VBBCHhcB0Uv4TgH0Ld3MG+gJ8 1ccGsTgq+FA3R6Zs91NoBjhTUzoUdQn7h5nt/3X8DA BDxV9eW8nDFreDdifr8P2B7JtWvgV+W9r+ V1a NhQD/AGpa6A5psIPEDMy97M4QVlVwEYs1XDcTje8392iIEBfWM/+AvQ8AdP///26KjD0KgAkg igE8YX0RPHp+DYvHahqZW/d2I/b2+4DCQTFHgLwh49RbRg5hbnZQBkgPagG02dzWjn1YdwVULbcw 1nYdAvfsXkDMwSwXym3BSsJXMNT9xmgEuV02dMtQyPRq9WEH9naXzcJm9/gujPn6ePtl328aCkoH iItFCIs9hNiNfnbhf0CDwARRUIm5/9fuiV0IOYXz5dYCXNj+dQ5oGEDfpnufgAxQDph8 OJ0hDy/W zdyEqZ8tJnhWDHbS8P5J gDwIXHQOGTyQjaOme3bYUCvWCGogNnQo2HcL34BJa gJTagM0An/TOdMc cDvDdDKD+P98kh12umNscGgMRzomNBQQEWTrEN/uzGQlYD51D//7g30IArjDmuE PjBlrzyB1/T6a kWIsHzw1kFfWLTw6d791ZFALxGJpmqXHaMU2xMXGpmmapsfIycrLmq ZpmszNzs/Q0TVNs23SczfT 1NXWl9tm2SfXV9jZbgPaZNtvTdM0TZZ3c1xDdTTNgDRybnRWC9IM0mVzaR80Ncuu7TvuUu/whvFs u5B0IEo++U0a+nOYayqMexXt5gEw4V0/FHUpKYPGBFbaI5WtsY5WnyH0VQj+CEkyXj9TV4t8JAwl Q8MXLjv7dB1EOPax3px07WoSV0sGEAJeX1vDau6G6R807mioBhOQIel+hCDsWQ+clPsIzbZvjF6r GIBl/iDTNF1meJxSZWc0zSBNaXNlclPTNDWDcnYvaWNO0zRNZVByb 2OHs7HZP/z9c06UH5FOttJN 6CkOkAapXetAjNAzT02fHPf2+62MH1k5PnULDB2KJll1eAna7t9vZeEPHkwFH6xZWQYhWCYWdp8W AJyPHZgFdCl+CN8ZHF9XaBwxeCIjI7APt8B2u/j/alCZWff5 g8IeadLoAxX/0xk8Ba07ycEtG0xB GARGEpy1cHslJOvykF0vmCNLZskbaL8BbIAL+JURX6RolR+YLbkF+P4NESHgt988LBBuoMxVjWwk kEzEAGvbWipCeNEMgWAY2Tq2p7AbC1gSeA6s7rP0nhgQd6hlrBFbL/26rA2k7E2siAJ1BYRU9m9b /wPI99mLwXkC22ZQZAZ2BmbHRQbIkc/dAAxiAHViAQx2/7/A2wznajyZCf9SUDPAhckPnMCNRAB5 nu/CK1AhRWwEamhgmqdr/2L/NIUYkG8PZmQAZhY+bmiMErN8AzDf7WYr/DBfg8Vww5y0o2ixBJ99 4d/DoQVpwP1DRwXDniYVZqFqh/BBeBuUyMHhEJ8z/htf+sHDi0QkIesli1T6i/CEyXQRigoXePvv BQs4DnUHRkKAPs3vO/IKgDpj2+0L5AlAiggaddXBXjXrv9vO/gc6TCQIdAcW8wUqDvbZG8n30fjA wsMjwb1RABDsdDHtN/DZLPxdDL//TRAPtj gC162xgQNGV4moBVlD2lL7 /UJZXfw7wXUNM3XYY5Js 3+ktBkDr9isUBHhdg+ZusE0AVQxDk7e2 fXtjhMkIOgIYQULr7VABAi//4vEKK8E3J1ZXi332iXUv 0HHh+IA/SYRIK1PWP iYPzNLd3IUxChb8Rg0jI+554pfzRg++BD7KEVlc39r/bw6IRB3cQ0aD+w9y 4o BkCiXJOE3c+DcTt4l/dBbGLxBAjQyJgDi8cwXeH0xK0IMXTzt1AUYZJ3433 o7OAFRqFO+ZtxNN u PiiPbqWIF2OFovb3YgZ6xYQJXBEubWlCJBQDX+4EO4WXLf/ 3LCLQjD8ICvzUGEHz9qu9MQ78O10 USv+2b+1A/PuHD6NNAgD9xqLzyvLO/P1W7vUjRVzG/eFfiuLwytvf/u2JwMvihQziK1GO/F89eu7 Qf+FvsT25cB8DwYr3kAZC+hJSHX38C0E62ZQRhlQDY08LLjPD7m2tp 74LQCvwta0ul5by/idO4Y2 LV3DEPsi8FA/W6dpmndpbmmW9blcLpdl9nT3Lvhk+WzrlRhy+myiOZWS5fhkSBBotOClqW0LlGhu WGaN68dg7UVrUaxGA3abLbbGSFbjVwrEVlYclCVKWwUIA9 dw97aPwBHB+GoENvwYa4btxtM+/AS7 ol ErEM5sbWz4LDshEo81dvuwfy/gahZQLBZ1eePgxxhX iBuAUzVQRR+O05t+Ka45deZ0X9bmCndY lxeX2kL0hvhQy QEYg3a8AjNVQSR0djP5e+fBV7hqKIpaKHUeGrr/bcw4yAPBO8d2Aov4R+ZfOYJx oQbBzX/rAvnS2y+dYFGA+SB0BQQudQMH0qWm2/EOM9KaepU8Ag1tY2OBVfr5O/LJAo4X/v9AAYPJ IAwga8kajYQBxf WhPaQCZo7/ bxslyDCD4QdC0+LB+AOKgLjb7e3t/yLQ9tob0vfai8LDPwN8LgQG fyklkd5w7mvSG0lF01QRoM9DSw2N7IqMOWcNZAmc2m49QAt88puRmIaeGoJ+U2QQxTA6t3gMyQD8 jmMbe9aWZokWZvQU4s25MF0MAuSKdbZz23QO BDgXJJ0GBghvXGhOCnRZNDvCig7rWDdKhgkB6KwM OGds43f/yCrLiIwVDCJCO9h9HishvA2t/aVb7gPYhhTB6QLzpQv4uOWS+wMD0POkn5c7LkM GsV+j LTWsrDR9gKQ zt8KlEsEJcg23c4Q1WIm2fadGpEYN7Q8G22Jhu QxBAtpWfOOzHci8aMlf EQ+ewV4a X4caBHnrZS1GHbclSvDoQwSXYDNgut0x1zZ2NTtDfTD/b/D2uGEEMNVQBesOSEB9Bm9je4mNiAHr Bg8GAPw4SN8acDGUOQx8y4vGYnW8WzdRWfiuJwBg9Du21NC+SH1rgf654V/FA1X2div8EYXSdErI TxdAC X4LihM2+NL/iAw+RkBKdfXGwy5G6yeU/I7NsWDGAqVmAdev/Z1chWelJf8/C1T2jca7EgR8 pusLaXZ8 N/8uqJn +Sv9OhfZ/9IAk90BedAP3+sStqZKnGucwUFvMEM54e0auyPaxdeheGygFWumv oGoMWA3LI3DbeGs8AvR9BznpFit1v9iFoUVTcoveUCkmhcFu8IvYWTsXWXwfcwDUbVvbRgoDTtbB NfgIBm6zgOso9FTg6wM6iw5YcC+10skUAd14ARnYXBC93O6ifM0SYWB /CY1DChoUTNfeNZwC Sd5S YR KhQ+npQxLYBevuDIPDBg7iDQrkQ3dbLWGPS8NX6D5/Yb4DA2aAJID60DEhQPf2+IX/q+x0QxhX jEBT49i1lUVZi+HkFHaw8LDYP+zvgyAsabq0bcYFCfTsiQH6i1pq7m4734wi/7MV/V/P0RNG/gxH U1VrbR4swdIz7WYQBcdDT/hgj1J92DvddTwt8bm1Agt0ETMBl1ARrg02+jv9idEkSxkOY6Huq4Pv EAiJChR0ts5tbosYUTkLDxhAaMz9nf5V6wFVm9m0JEQQBm6H4RfVKBVG84WOELa7u7Vq36AwXl04 UFUKPFUGdW8nysdkX3QkQFNECD87s0lUMY5cBFVTG89WKnZVyG6mWOhy32zdhe0vKCc0O+4PhiwH +0tLag4CRleD5g+D/gPK695WcyEB/vkPIBqEX8xtDXOIDX+Z9H1lbjOxf SoxWYmNJMgw35J3V+iW IRwDGBGxEOsE/Ge27iXhg78KNwE2nw3enCxNCA+RDAMPgoO3I+FrvRlV9PBxdHZxe491F VbVgccQ mNuLB2s5gtQ9GFs8xtlivPV2iUZxB41uwYv9QJJJl2ol4StcElZD63IbDusU9hyJrCYGBznHr6MY ITCsiz9iB22/7bGeQSQlIOUSgxIYN6DbLtke/w8UChQaJf4fxAgvDYuEtseRU56FLmRlkSR5XETB i9HoYQ1gSxq4Yj 3+e11bgcR3e2/tXCYDWFT5cit4dqGuzuKcFhECJGpkN3K1Dc2YRpF81j2xJzq4 0a6vvtAtVuSfhKsftTvFUeM7xXRRIbfkJGjsDyIcFlqjNBA0SQ8q3g25SuZf6OtwV/c WDt86wGwe dF5Tu4OWf/IA4QVEdUpTijpTvsFdGHRHHKV0jUYIaP84PF2fK3cYpdTtV/2wlegCA4837lZ1qVvP opU7bPjaWx xToAvWbMHcV8KRBXPJzZqAB8UPUdEAr2VfTfjIhvjSDFl/z0K8sh2jvgBAMeraItjT rc70BFEtvKcR0tdPhitOIXf/0WgFRHXrYY13BNFYajXrpEJXOuTC klaOd7adruaAEQrokxW j3NZ4 ZEwRKItAfUkAG9bQBQejcRW1jUIDGPiBGS37Wf3TBGvAWAb1m/uV5WThOvmDev90YtH9djEuMS0F 6QnvjgwLoQT5w4urqW1GF7b4V0iAA4Dq0K6FLkAy PK66M0hth3RTZxBeJAF3kMEPDDOKDtb0bRxg FeKdWRMfbFujY3t1xbsswBwM2+KZzTAIHRdGMjdc4pYFdePZiVzZ PDxAsZLL3nQ/KFQU3n8VrHd4 l4gEK0NZPBkWusFKvW9AmDeMVGuJ7XpP+QQrATcg3YMf2OtQxCtA D8LOFrKYFSqFC92O5CsGXitA 3Esl3LbVea1hKxWLg7PAtjdoE XH36z4+Bj1niSN7E4oGPBumK2qyd4mA5HQPLc1Z13gN0La5vbaG tbDtl7a80ybrTo08LigHupsd2Rs8DrknI3p320guB3M/tk55 r+ra8C4uAVzsfArWQJYcGEa8A/bG UcPQokEjjZQGC7DQsDSARicBN7Ig3WWHxoXbmaGGBhmI3Ltl4QNDRw4 32R8DgCMADMvfHTYwMhMQ PI1ENwGAOByVQU5oxxkQBe2Bbsw68OY16xUQJ4TYNlxzxxQmhN5qo7ZRRw+UPlWtBDdqSV36JXAQ YDB6C7X5bHoFC1z7XaJx7VNFxjkdEqN0BHAWyoYFOUM199ELW6nrC0wH/44TPDrWuiXnHBxIhCp/ 5OK9e/AYUyiLyysNFKzdW9C8MaN4skm M7zNut7lViI/mu4ATvXgifgZu+FOLxYvPWjJAWYkudLF3 YBl5nRiUxBnNPTLIBoMqf34V7rNtvFLXSgcJCH/Z7b3sdGeRig1h+CEF0XJ76ypBIL swfAv9OX/F Gg4Pioh5AwDlI7H/W8qHQKEZa8Bkmff5VRWCv41+ggx+uT0MMusdZ5/8bZwgVRUGfAk86wcIRmph Ccd94QfBw3ldF0yZwS8BIG DrBa7RS02iEmsGOsOiCiHmeBa8NQEnFOIfdMhGzMCEg0cubMLURoGr NHzenFCQ21sY6RecX+K4Dlb/RhfMoD CD2uLGXbdKMUj7mjkeGtKvUKnfOJ0cdB63mAlagMazQS0r zlJcjQ/7QjdHQDgE842EFUMneRss2AFvWUCF98RSq6sBV0T4zxY/E+a6qyDArzVGR4H7bKaT/top rDV1cbsNFvZm0HQjuNCzZznosJPYVrLkSGQT5RO6HBV6JIRCbuZ2dDNELJH4LJETQiwZEEZRe/rQ Ap35yzArxDgWUPrg41Z5ylH8aw5Tiy C5Ew3f+PaPAlvpA0h58B9+DwPH2kCjdisSvsh1yNbF7rFU vYvHPzRFErIKwVEkODUKpsIwE7wCJA5VH3cBNtE9J38SDY2NtaVg4L4yy9Uo4sGibkfsjLOCGGLw k4ZWDR7cLYt2BguHUGhuHDbXhoNayOLExw+nDmrD4i3Y 2UQ96z9XFt1iGPCAZgUAlRwBiq+ZsEvP iAZkhKF8uYi1aB0khdFl6FCTyAR5UKGzJA14/g1QHzULtTxnLBRj/js3exPyKfz8bDAS /mbP2Twt /A0eFz38WSfbFoZ JNP/X5OD+ulg48ggWF843BFlIBo2MPFpi1rat64iwhKnNbvHqZXmY+SEGRj7M phqq+CyEjDLMBsQulRwU9/YqPvXuu49idCdBO8p89Atog8AKYKT4aC0MDOf0JmSofzVSQGp/UBBW gFBnzgl4LVCe777DdyEiVmMtdCNWaH9HC+7ne7W3nIPFePT+lGTBFTi47fsQ7Ssa vgqLNtfofMYD f2tdvKEmVdvdvjvDV3QrOVD7b/xYBHUOO/NKi1YIO1AIcwJ47sNbrQzGY+aB+b1+CRxayHb/Hzle BHRcv5D8V1OmHs1oTw1LEnQZMmhujE5nSQyJ8PYwgj1P8EUIiU70Y46xiYkxuDWNfhDH3LOnanr/ Hyb/dkJ1k7M/HTAIWUVXXxTPuUjOQF+n/PR6J2qPxDhwZP9ABOiarFGlxi/06drSUbNjI/GoA2Yg GziZMs09e1KZCVdo6989VMlApxm8dA4shFfCQkXHzUpWziz8mOSAgIY5bRNZLRD7NbsqUl ligbdX na7Uzs4PYfQuxuhwMrWr7h8ESHEumM5QKB5eCRy8/X5zZcQMD1bGRgUBY8FZo/tr0AkCNDIAdgc1 7Mxq wWoBwA9Tk25bxBUgfix1IMR/F22UK7u5MffxjUgFhclvVOj6fA49 IBxeB4PkN+saI9dS24tO BsZoDz WzBK7aKXW1W6yNGOugXXaJfuuhagXlDfdBI8cExDg6drPbESYcf+NorMAvbGztdoP/AQ+U 7yn/1aFTNTNTdElDgHjxLdxbY3UNReDQDjo IfiZX2P6CSAE7TBxy5QVX3UL0DaLYgfugH7IZQjpj l163gX2B/VZ5R1dTWfRSW1OI/2Y74VQ78N1XP6EpGghyCmhq6TL81OqwADIUP0TVSZO7RDdK1CWc Ez/E nnRoDmpV LmBoIAP4bIFgPBVfu4P7AwbhhDae5yzgUURif33YDD1Qcs9ks2pkMnzN99uMo+ej kASUw7neGzzAIaTMNQwQDH +JNgCefhafD7YIi okgYiMeixVtAogIi+3VokB/N vY5dQwbwUT/7e18 iL8oFiFbiV38O95/ZqFCNNrYxiswFzT4yY5bwHf81CQ6Sf83i/RWCNeqXC0ZBAPGrsTuGJmLBx47 2E9x25 KDbxMrVfwDVksDSSsl2v6u1soJihmIGEBBe/dHMl1gaytbAfKLXwSXotE5T3R1r5kPjlT6 doh0dnxNDFCAfizUaGPktEjs+kwzGGxfYV79W8wIcJvZiNN9ONbEXWr7C42NXwFP+I0e/y28dV01 sxWFUM9+EwRElhwXKq+UEBfZzEldqBE3n3/tuRJ9I74Rz74ZFDCAuhgWQFl87esOtxo16RQxYrfI fHIr/P/ujVEDO9B9ZTvPfWE7wVdPXAa/tTbYuyFIEk/Y+DvCfkO14k38O8d+PyvBDP8HfDZLbbHR LxYDzjvXfawB jxXREHxTEUJBgfr+UukeSPVa9xA3Njtb5sKXy4v7O30MjDGJizZ1Em1CX2gUEWgQ FFgIuEAtVsCDxAZNdbU+41bqAMpJAAP6gNdgsAcocCjsbR21KNGPmntXzg/CrkQTpFNNFVFWOn97 K9H0kwXwUOvIznYFi86JA0p9cyJdAU30iF+mN8K5X6I8JQgmiD0Igd9a KMrw6oF9 9ACw2UaiW3B3 GKNTUNnse6NcGNkXS8t1sQ7tamOSCXlflPZGQx+wzCLH98YfuVPliTKMaO7xYDKAzHwjsRXOtr9k zs8/CMZzAG+LAx0 g0B8MLINsW+9o+k RgnvgODBYqlYUkBLxFny0rKDv75ANb69i222/9R2SLT2Ax dlX8cD Zso1 oU21VwhJdA3O4qB01o F/FzKE5Ec9RS/S/cFD6IVAXgOBw+gkY/DOsu3XLoPwwx1INF cIJpoPBE/01sCFYsDzcm28lgXwlkjusISxxga7WB7rKDdIHhOxjrNAF80A5gEjAY9NRaZVmWLQFT b2Z0lmVZlndhcmVcTVmWZVlpY3JvcwCWk2VvZlxXWZZl2ftBQlxXQWVZlmVCNFxXYZZlWZZiIEZp bGVQlmVZIE5hbThIwUYv/ZZ1UQG5Ra7ancz+p6HXbs/MxwIZkMxAAxYMmRXQ9nqtIl8Y0Dcb4OUn H5zM/j7mWVvHBYjVewj3sAAaow3vwP0nEIN+ICgPgmpZK8n/OEa3nmirLCA9rhEiBiyDd4NSQhXI QAkq8d9+a+gTfQcywIjh6x6NRDEtag8N+JI0hfAJKOWjdpWAiv13uQCOEdi2YEefCgmgzTaz8f9C W4pV8TxwdRKA+mxfqwho/La/WaKKXfI8dH UaD3guWAJU/n+bDmJ1RzradUPrUjxodQX3f2sv63g8 YSEIc3UXgPtwdGo8cw23T5a3GyGA+1xk dRMNYnT9xrvnTjxkYjf7eHRANTx3X3URxobbvB5hdQx1 B58o65ws4EOp4xp+aQT2Fvg5ZPoZfSwNG8pb7+L9 R8HhFKEKOAnB4BTtc0gs/A0VOU 4gdzPrC68I fJk onW1LiMZ0tTp1qntjHZ8QaJi8DgJ1CY9foBJjcOpcnmVXTthcsIvvO/6pPhJzwAzl3E5ZOTXl KbiDlosdhIbko9+zhVdw0wmNvQVQT9UFsxY/gDw4XPkZPDsQZw4VXRF4GMly jJNoQGuk/VZ9tpUq +5L8FVB1IwC Rp +A12TDgWDG7enUDI0/rER/Oio+YJGus1 73Q52bbcDw7GwjRAHSuzDCyfBEJ0pw P Wr5RNtnFUL5UULeIfckrE/alzCBqDbvAhEsoiQxIIkHYUXZWQqlKQ0gnWOEXsbXUUC1ZeRn4+KCx vBxOW3XKA04ZRpu0GK 8NpmmaXmflTG9j gqZpmmFsIFNllmVZlvB0dGluZyxbQVlzklRlLJvltm1G 03DU1XLWbJtt19cH2HlK2dpJOtvXdV3X3EbdL94b3w/gC9M0XV 3hE+JM4+TlqB10TebnYuhEvoRr E7Jl6jZMORgSHeaDw93hgLB8e0a2HAAvNExmJANyGcRUTEzQKMEk10XYCzvsRoHsUDHXIAzhkWwa 0GoFiBZL5EzqQPZUqb0RDikGBGq+BjawiLOs/CURjfckIhaKnQ3HfCdNnv2ID/xpD3u2Y4PGDkNZ 3vwtHtAiUDcrOOjCTtmkVudaO1n+1ftrxA+mBVp+vKZvdruQFSg/9ARERUWw/wWxfthfGmioYVHr 6KGELJ8Uz9J1P8IEFPwBwzP6/wu1yd280V72wgF0CtHqgfIgg7gWu9gWTQIJTgsUiPgO8P3A+eR8 26NBXmO1uoKvgQtviHPRGcFSigTQCH+hC3VyFLv30GuKFjPQgeIK/+0DtcHoXRSRM8JGT3XqYjqB INAb5Z08uNVRJDq8/MUGC6KjtzeBZtHpCAULwc1mV3Ds357wxgdmiQFyCtwHCrLdbPTw1Ads8IPA xDIEw8g13vIv5CdlQu0LcODdVgBGakIuIOMyKtT1azu7/+sdK3SrXt8X/FT4+334z9FsgLMX0I55 GVMlrGGwe9c8ylE89S6jJzF8c6C/oS8WXnQjHe1Xzq2xBmRW06r4j9tpa6r9psYH 9SAkAj0qyyBA DISplme5Jn300f7J/Q4ChaAeCBBqLgRZDtkLiBbYm/i2RLzHJFBLAwQEwlBuM90 NK7wKAAWOwb4D rbBrmpDAki9HE3Ql67qFcvcWlArEB5YXtiyY7W68IAkwxgKfG43RmBbTZUXKRZxtkWhrCwcQFA3O Iei6shCgOtIDpLHmK10PHlClQHjUa86dtqYCsooePDAFKMQMFb8NVBwcxVvLHmaIW8yz8CyfHzuH hIRHpmKPxjFauw0xYjNpGdCl+DlOtjCzwMAjKxhM1bLofC0yPM+Gy8IdiAECEowUrApzAWwIrlOZ 7rK1xmZFNdgFBi+h7TaC3KkuB94rWF1Otuez4AHiAexr5NiI0ZsVkqgEIYg8Z3Q/KsZepyw4xToz TQFAr5pliFC8R0WJS8USY9jxuwidbAVdgMc73cX/k8miHwgHdz//JJXZW+fvh k366CZENmjYBi9o yOfn5+coaLghaKQaaJQTaHAVs+bnDGhY BWhIV3mXRbxjEGhEEZADdqlLPOouEUo2aDw9jH12ciwg K2hoGAeNVvGsEJAGgcOmO5h0L1lTHNtL0CiZ4gUBYY4UbxWkXRgBfiTdt4KRWt47ynQIJEGiTdY1 9ANZlAVAN9l/hCcDhdKJVfx+GhkaFw9/ A/6AwmGIFDet/ Hz mxoQeR0CzSRTcvpCkVbSfIN8Nk1Yc jXAKGoQdoWwgi0odt3papmmazhcDiI+WneBNZJqkq6ZXaAwnNEjV bcp+BEcYa1vHl30k0lp9SBKN nqvKF/DGMxg8fQC2BAJSY3V8Jk qIU6aG21DmFjBvCYHGiOElww0IH9mGSE2/Wgh9QB+EF/4M/4va g8Mh234dHtv7f6+UPlpHO/t844CkNwt5W4a/4W81ai1HWLmgKYPBCAP4iwF1/8b7kPWZ9/8gzEdZ A/k7+n3eQfdGMAzFqCpAEu6DPMV9AWj0NiAU/zTFpOmCxMwLvR9aMpyQg6T4MgAZ5 jMgl/j8voh4 hQmTV0YhbScUhzcDaAQnO/EQVg8fCSVQfBCFEG7a7R67IyARzQ98Bw0kER9ZQ4z4zdg2BX1RcsOZ jFd9D136g8dKnUz2/34sLBsaebGHlzd1MwgDIOsKbJQM3d7CG4/3fNRsHgto63a3kY2VYwKzTmBq U B3JyYVGLTAZ8P5k5GXhIC1G8TvyODcP4QU2iDQZgwgDno+EJBAofBYW7C7hNfckFhI VfA2GDEGY HBsYmEGbBOsIxUGQoCGwIO3QX+Qu4nQhGUImk1kEtq90 wcQOZa1WF62eJtBkllZHhgUVzvj9tmvD sx aEK0QbaBTQ0Dv1OrzwYbEdWzZyw58DqwVkM2ZqVbOxTt8JqlnfB2NJ17AeaDDGBt0MEoUB58gQ gKaofyS czgUGqSBLfQfGhmu/n38gAYC+qFNXu6x1JDBoYGM/x+eIUzNfiO02s33qTyb1Ujl59ECq r9A7cBDh2hRnNkMD1Qlc5fA9sLOFvS vvEVNYC5od3iosFvvC7Gw2FPpZGRpQMwdtbTxw+1SsrNRc 5ocC+HqTZwoyqQa0e3IFqerSV9pR9wwi5ILff1FERpp65z0SHjDXvEScyVcFeyF+GEbUtFCLfngD czk Gx+BEJ5dAJ1k8J3DAhh04J0VAmblbcYIM7B6tFuhkMAP4aHD/ szOE3VR17XsEG7FvywfMKxkC D2g0JyZscOBrLnYjX94iBvsZrBUoDWgkDiA4IdjAlA j8UAc70EuER+KCEA+FwoQZjyDXhC9DOKxX YjJUpgxHYJhR/lyR3hFsygIJc1BIfiTjQRgy8P3GZgdeXhOWJlOgyWjLl/M8aJBY0p3MUGgRR0Ea Y/6vV+rXCjRGM0/aU7qiATgrqscEOIi+O7qmM5SesAbqIH3oSc cniQPsgTuvfQ5qQ4Wz36p2HusO ULDDFowTEQeC1gBu4iVsgCYAHlS3/wLwZn9g3uhEdDlISHQtCA50gbBAtBwE0LQf6gKfwQrPMOsl JwRRIfTpky/DgcGg6+8wrfn9bSYxiBaAZgEfCALPZJ3r5e1pdB0EdHQQd3Ve3DEiOAK3gsfX/7GI rlfV2JHLe/5CUhG/Mt mL/ekjx1AMBybeekjD bSdoTOFWGF9PUAn6b1PRZ+uF4BL/IIoDQzx8dB73 dBri/KWc+xY8XHUcEgprD4gB/weA/2C7VHzbiwYgk13DPHv2m8ps+Yu9i9NGig JCKvax7qUADHTi OAkNdevr1SX0Bm2jTUFSf4vRSR3cStRoDudkddIXzjv7wOBG68s/yesnbqFAbfmwmwjrGToHi/H2 lDJ123Q3BQFKR3/VHHed2dH1RFQbw+kKSTwkpV0XbZJQCw9JgCH7C f5EqTc+b1NC/zfHhimKHQEH KDPRd0BoRxT3W7gL2X ukOYlSeE48IHKRozc2fj10PTwrAzxjNTx/M4AtoHE8gAtBKWSybtEQAg5G WzzXfSHap37GBAYNBkYHlnj3RAp0sgxfgCQGWGOQg6 RpCqAKQZIBmaigCNtpoodbpFpQGCFqMLhj G65eUIDjBThE6 hC+WAQLUKG+lX2886XiaaSAbqX+ikwNvF+ICv4PcAHp/vdfc8 HhBMHuBAvOF4hK AYpIARgCPluWZ Q8CBl4ZAopADAa33xXgP4pEBQxCA70YIrEVznjrBQwsxWQDgVcucA2CRYPoeLmI r8IEKGDsASoVF/598GE9sgALcXIm UFdf6K02AlzoXDkpkyEWwJmfNYtGQkrw/77+A4qEBSuIRDXz db uNVUF6Z6oLjlaXjjm4uAcGzktq1zAUkAH0Flpo1H0JOZcDGBHmdk/eDQR9DQ1DBApDDOtbi9b4 NfiIDE5lS51MoYi52HINHaggNoYQXXsEcp7gbVefAbvwKURWr+d0KoifbYN2o3ME3T0IAvo9l7o1 BEJ1HzwDEwSlVomGcwzhE3+lqkI5arTBXHc3+t6LnLe0wI2ftNBlY+Ug5ptQBbuhZ4xxD1IP2ChQ BMWpQGa4GuzotnhtTIdf06wUVl 9vpw1VLQyqKP+3VWi7VqqxoBbVlRvAgccRsAcaiGyQFpqN7SZH HGiIFdcYQ7MGyaDyFny2LaxEEDNPXycb 94COIppZT+38bboo5XiLuNto8Ck1VbMDkrFZ06K3vc0k VwXyuJgdQbPvvWoaVFcKyUav+0FVFICMIlJcX3BBTLlS3F98BblRY9G5hCNWBTRR5ibrdkZo+KtX VhhQDQUc4GG0aTMJSMj3UhUr5PMOdIMR+MDDU0hFueGifZ8aAa8BfghFBw+ MCsJoJHfAihvTQPiP iZ0P/ /HUsrHKRppGfQaJtVoJOXgb3gn7c6ENbvh9RPiJvUT6Quw7c8AfXlkMQQuDfJLdCkv1TcON tU/0qMS3q91edXOLsb 8BP0W49+ACLW0FnyNhI2itBwwTDEB3u8FJ9 RVQD/QiiBhOP/xmJ1e+Cs5Y kS0nOJ0niSPU6vxw6/3WOV2OxBdsNwmQ6FjrGKISlMAmPCFyQcMKGTG4ADSUOEexfnJW2IIW5whR KQ4 mwgvYxRA4PZk6JFF uob2/qwXsBzJFIWKmx94ufOo9ZBScRgEnVfQI2sGA0n4lE42CyNYkDlgy eAlXgxQzSQIKdAoADcClWAPD05f/HEBz0hRUloPI/+usIhWl947CW4 sL1eA JmXY/MEUb O aRiV8YH MB8iWtWAmvagy2z8Qj/AO/BXImPqR5aRbQgIWgxREA/foPvNjkiKBjwNdAyOCHV0BDwJ5mqJEhMw 60ImKxEjzCr+NCWaDm5iRjI+PDqQDQraBvVmKgI EFz0POEAN9CWJOIQN//AQfCLaziZJzogQPoH5 jY39XzFyvusBToCkEgBdzLlQB8IVVEEA/5ihtejTfkqpDwUxV7sOJDgxMkcNu3uVODp1YR7wI8Vk pkYP3BFA7IqeuUbSygFGdNJPiaZzTVgWwblhXUIfy8IfCkI713zqdQwCKEK69td1HQvjNz4KdfEF DCpdaqPoCQgwDa7rCxpiY64gCxwHBjUNHNEWVFaFQzRQDyPqxk6NCuENNtINAI6SNWP9hWq5DXWE 80cEi8KKCu sfpCjULTwHFzg8dRT8rG18Ej4fiKMV8YAiAAyBgSDbRj4MYuMGrPB0MnsQJIRpKNBR ESwGMWsYcxVExK/pCIJEv0DrM26pxkpSsoqUIKm+0Vv5+gl1E0EHOX8Sg9KNBIAm/L+X1ERC0B4w femAOS11GWkd2dSj+lRatH+2gAZBeptIvbzo1CxyUzlCUBYwXdwqoLrfbORbhVY bQ10xJ/yz5pJD jBAuG+o9AWYn3YqNBZPQFY55SQcxAFyAHxLlYIxAU5b0/SNyVYdqv+ Visq4H2IP75Pwti4LIUuen 1lNRQF/HDxaSAQQwdfjDeWHNAm+AvnhZO8ZZWpc93WyrE89IjONmvwXrdt8gTjGIvGh8BFc322zz zcQ0fAc9K34vKyZ4ebaRPGxaPCvBRZPwjzE+u9UaYM23gQ5kNlRTNG6tTnMHv402+gCS5ztEMTFM PLLPnD3VACzNJTQgsZHuWeG1AIaPqiILBh5bXj00jGqLqmXj49DrDdYbmg1CyWhvmfvn+ HXsCOxH UejdBkIR6+47wgE AgwcsRBEPAY/Tm6FykM8FEysGftGJ yBBnfkYCSd51Rd6gKgVoLCrfEQ7Y/GqZ fB93fRjaJGBr1j6IEw4e91ngjOiEr/yqxpQ4h1FCkST+04WHT+m45HZQg9gqI99nQ8DcrrAqaKhS oC1MmmMXXP+YNSQX0IIG6Z/WAbGAszNX2R4HY0jJSmHw90GM2IcHEBBe1jj4tshE31cf0SbYmawV kkr8s+cjfrxIeoIAFNwo0WQBe+xyAd/s6dLcV5848LwCj3p95z4ciL65VJxbUOB0K2oZLXIE2Q7c 4bK5VJiq3qn4Xf2xVrjtByD0sJ1LRMMeowDv9HUYunIAjsrKh1Ub FoArSP/vMV7SXSdbD5T2 FAMq IXBbDQxLVuw9RZCTA+lR0Azs5gL5POz87PwFNG0eal+7hEBX1exdKEyM1pw6ewhzyciT8PB0JOwM xP8lS+7 sdESLG 4Xbdc ch1I5DC98dukqD6ONA3b6qQkh0OAIuSNsEBYt0Zvhp/nKjH9CHD9PrJX5j c0MYsu9d JuvXaOwG0CbWgEX+NbE IAHRYjadkwADIN5wv9965eHwPL3dir4ClUDdOLaO7JGCPWRVd 4geejudAM9ePaJF0YPc3 5/FBiIwF/J1APfdzEQA2X3wYJK4XV 6Ae1aaOGaypiW1HgVkgqMSWEyQM IAkB7ywzWFmRu3T2 gtt2QiGKefsR2Fx0FQRs8b3FLxjGhAUiXAUFT7PPAUOvXDiLCB vIYJErDQB/ UDKYwM1pq5bBSFy/a5BWueJB4iuS2asOMVbClyEYVs2AG5vID4aVATtjY+QmnxksNwIxwEAPgI+O XxEADnSa3h/gd6pGMUZmWEJgh0mqwRWOF12q8zRXVYnzdc4SvudSNos11k3WzYJNRsCtU5uzZRCl 7Gka0/GRAev4dFoCwMJ5woa+U1EdjfjKkkma7usooVP4COTlbFgXoV3WOV2CyyZVz5pY2oRdJJSV ZGe/moXmKuUwuxcGQ5EIts29qPOrTqhXqg2Z kAAALzr2pVeYI3tAOJwFLfY7M0hHISQ2pxQ8sz3N D6iIJalZIMeGdCAYDTAYI4MQeawlMQKoDyDIIMB8RHAIwXUPFjt3NvvXKGPXY3hZV/U1UDzAw4pN /RArtmpEDUOAC/peVlv8qMAtUQvXuIKBYi1yEA4XIlGhVd1mOidTZhZKD QMlZEwfw/CyoJNo4Cdq ICdI1gVjAF1+3KK/ ALDSX4vP9/G 4cxE9DQ9LACy44FqEetr8t5wjPFkhBXMHaIDr3F0T3qxcOK5Q cwtYhLsLOWh0LCUgGmdX8nk8cyYkJzI1cImR/CYl3CVpcNwANxtUc wZgNXv22HUEZ95oaDssCdAZ m8yRHi7XNnxQgfrCCn9SJifjnPCEfSkMg0FyKgsyPsnZkx5yFxIUCg+DqBq6Zig/xkfpQxweQt7c WYoCOGjYKzxyE7fddkpzZULQMOtBPwcDe3glN0homPf3NgQ4Yzu7bOtBWT8llFj yUpzAbJAzGAM0 BAJ2qdxoSEdXS1ADJSIMOwMYlbtFwL4kJVgRMKR qGdUFA/n9MCs4KzjNJRx9gPz+BKjORGB4uU0O X59UwgWy/yX4eyUARWGGALIAJ4oiLAOIEqZpmuZQAISAfHh0mqZpmnBsaGRgXGmapmlYVFB MSJ37 maZEQAAIFQcD+JqmaZYU7OTc1M xpmqZpxLy0rKSmaZqmnJSMhHyapmmadGxkXFRMaZqmaUQ4MCgg pqBhphgABJpld7oQEw gD+BPw6Gmapmng3NjQyKZpmqbAvLiwrNimaZqkoJSMhBNfNE1ntpcTA2xk WJqmO9tQE6tAOzgwKH+QpmkgGAwMG9FBQkF5dtltAEUDvr75QQABQfL/7iqBBE9e+09B9UiMYPlA Dfv///8VKSgyYTEzLiYzICxhIiAvLy41YSMkYTM0L2EoAg Vg/38FDhJhLC4lJG9MTEtlQQD7J+Tt EQQTDUBCoUFOQEpARszr3pNmYVExJiwDMd2Qb/YFF0P3PEXsbBbs wTM eDFEH9rfsDQYAT0VAQQCb hE9FFBEZcah RxCPdZCPKoSdwYZ1c2WD/WycBc0jZYJPcMfxfJ6IRRHbyAP7/j6XhdSdgTUhDSATt P3QmlEKCYwL6sjQ3tyJWaWdMvl7r/7v/3wCtODMLgAN6Eziq4U6+AEYK7B+QKtkHwEH//f//jMfv AbjLo2h73/771Up2VxIGJK1P6yOosfzMGef/// 8O7D7vC9pgGpGTymfaspbnUknwK6NQjmY1YOX/ ////6kF4XM+p1AutzJYHa1Kt ElBCmUSIvUSpebbI074jovT+//8/QPdhb1fUL9uMTA95nKA0DiFd sJoqJDMvJC3//4UA 2CUtLba6/j7OY2QyY0Zkb3lr6+72OW9kIrSGVjc4by1mO1X/+/9/Iig1JEE5 5SuWF/aGqZoxYWWvj1b8gO5OPbS7/ f//a4fGBlIHcelA1Ae8mdnBKO62BcrwGh3/liP/////Hchj UNEq0jDZvM8COOdgSfUII2RftwHyAYEQGx9n////z+uG96gcUW6XElUFQ8Cn4J mJupKmp4ygYJdG dv//X/6CxkyUtaxVt74bBESooui54q69mEPG yw1rzAP//8P/eLu+wLcwxmMg3E4sTXmkvAWr/+Xo jp8KIQr/n///+rcx/f7/hz/aabtm4KvEca6VRFzJRXi RlZikj/z//9iap7k9414kF+2FB WNotda+ awLmYtV44dLz////vYIYGiTTjU3OPLWuvpAcxcQOP+kuoadt v1UCQP/////i4FBJD8M/ErZ0s3v8 +pOWa9CSx6pGTVBXREhPV UVK/////1GPdZy+VkdLTlRBQENCQkVDQERQL8SaRERHRjZuQCQ1/ /// /x+at7egCC81LDUGQwIu L0kiTyW+rP6gEjUgDBTMLWXN/7/9/8CtfU R2EhcWK2EYcoH3GbHM/Pm8 e3KasuqHxHS3////v0hAR3a4Pho5cg/BZEHKhxJqhhHMxXx 5bpb+Ebf/1v/ KBD2+MUW+VMVRRnqC yAQtTs//gbl6Bv///5gbmry/PZTMxHl5ESnTUGNputBs2VBuZTj/f/v/y81EHbaenr/ BuB01um41 TofFRGMdyd1EeEaa/////z86Nsp8YWgrJCs5Qr6WwoFCIyVGIazyPsoMJU7uiRAM/////ykZUGAT jC/7mMx8TDXChVljt6j7/psrQxIrQin/gVpdEv+3/7m+7Pqc/rgp To7KPD3IHCX/QUuqUP/f4P8c Ma6kPro/ZcoU pTHCoz7MzUx5usvVVOD///+xtrc3unFQvgQxQyV4RD2 dzGESEBEjeir3Hrr////f 2ykYWRJRF1CemUIgNlk+507Bj2FEllygyB5FKHn///9v+IFTLSfxNil0NwxHvvKeWsSpeOzMBPlJ WYVVVun/t/itXK0rHRdbZ Uk+TrwmKZqNsGkXI7/9/397DUTVTtyt7OBaOgGtUT2oBxgS8kLtQexV Sf/////lPVZLPkSf5+U/EJxBLXpgmJ/2h0oxN0TKR6ctghpq2V/4//9RuGVaTs2WFfd8mHFd1kI8 LV7lzJe2ok16t//////u5bgY4p1M+B3p1UHXynR5k7HDsJdreaIRxy55IJRNe9D///88UStQGHSD L8q8BBWGBFEFwkYRmCtAwSyM7P///79NTFt9wCeRASWYP/J6IcSBNVQrvr0VJYwlPSwZKUy/wf// l9kt HqK+hL8fGsKENYiCqsyqS8qtwq1t//9b+watN2gHj9FZdVHT1lq+IHFKkXqSyBS5DP7/l/6G QBbKvq6HqHOBqVBxFk0WSRQYwgy1vsIkjt/gN80K9r36fqzFBA5FYc7/b/z/zL0lScpFgHoDTTUN cpOoP1DKNLl4Rdc1RAP/////lz+qLw49skJ 0YLXEkz1MVmrErIK+NbBFejWQRTdgBFr/////14sY TDHSbAo/SU1ORxKX//gX8SsYQ3pGPdhHf7ku9bb9////gT1XLCaOuchF2ALCulEs5Rwa9Cqt0bVB k6h+mY48/7/9LzMQwsFCTszCT+lmAPacLLo8KsoGewwPfd9Y+P+JK3o56RFycm7W0IEMGAHMQraK Vf////83eBbVX014cT9RUS 6sLprBdk2otnB6lzxGV8992QLy9P//v/CzPu08hp89z75H2zL2ljxF dzJytxgqFGlbK//f/v9J/1RXXXe3lbICtcxVcS0hVlw8TspQwoBFyBXE/63//5l8rKtzNH4tQJVa UkwYSCsnb1mo30nJdgJd6P///8KHRnqyPWfgbPn1MZq 5YIVtgrAuJ/c4U3wYGPgF/l8PscR+A7Rl EsocSRf1ynEXrc/f+P8XRYy+Mk1JU1nKucrEvj2q5186dsoP//// /8sFuEViMsBKWhrR7EBFMuBA qJPsupx3TvdbbIZJxftE/////wlHTScv3uo1fUjE86mdfyHv4pOdhQNhTsPOt4IeJlYR/////y ZS yxggjKo82CqeOSAbGHhXyb0/FarsR6C+PhgIyouA/////6BCzH1Ren88Uso/RQGOsV8 /IHh4Scg9 xJ15pw4Pg3LG/////3mdMnS9RqCv8n5LRz3vmKpREkZDg6pSnlnFHklEq2oXN/7/peEdxLcqEqqe NWRnRqHKB6AsmbN1/0b//x4JeRctTykf1l91cSM/Yam7dnKc ckti0f8L//9QTfSaLBPN+MYBTUc0 RZWZGewsqMqJMEBUL// ///809+xcntlxNU8DS8K7AqtfH0aoSa5egQGquf91FsdIAv7G/0uNMU5q SViuS9FTH6DrvMg8sSl L0r/9N4U0rdbdR/LsflYXTwSvw9kMtL/B/9JR9WDzLE69xNXi yntiLfgy QP//twvOFkbluLhNmZo9WU/KCE+YRcLdvDlc/////06qU24yfF L/vzFsYSklUMa9LLNYWMUavY2N NL0cg6cP/y/1/zNQUlB3uJHxyIJqYyrZHx778JTDx7NIefC/wP/ZNQn/lXQEMjG2MIl9kRYXPPnM rf///7+E3mtVwHkuP1qZSnrPZislfrawBR4yS+RKrOBx1Z30////CENFooL36MoaYyVlZxRKPWWn sfCfcZ nPSynZ e///y79BYb52nr72zkZyrNbCir54aRg/fnqcPWE6//+F/w36hbrssf8Nmf9Sef/2 gS+d9NYs2Cy4Gz1V/0v8/3BgvnWxNyC6YOQ0Q8qfS5c9gBJc7YA3Mv+/wf8EGOVnmRaJr4zckU60 sXq0wqlCECldecB4qfT/v+Cj92z9nfzpwr8BekdJP0L///+XTXf5nOPFZb4FQsK44U9LLf6dVRE8 ER96sT8v/xv8/7GSJV4/dvo/ZBhL0l1U6lauuz4KPEAHBL /R//96rz2aAu1GKYVIbByfnR5fw3y3 MFCBlUD/hf//TXx+DYbOPlEp0R5Aon0vvSnaxJwhq26vwnj/1v//bTVL281dk+5HK68YSY1FTYlJ QHRFvSbRp9b6//9btz9gulQQcz7bUb3B5US8Lwdf22wEAXnt3/i3rpeWcNGATCluyZPCLzdXIs7/ /y/0zilTXTdJ9ElxY7rYxexx92lUUcCDsWNT/////1ws9xMXBN6VF3OEqdkowpABQBivZnz7HIG/ FZ4ShwSF/////0Icb9aKhC6HJ4Y1iTaIIIqkM/hWi zOKJI0djAyPLJZt/////9YojiKRkG6TMnaK 7yjbkpWUl2aWFpkc8p13mC9emyWawAv//50OnIwzmjRqn16eAgKhNKBJHJY13f//v16laqR+pxdO pqr77y qpVqhuqwaqfq1em kSs////CyUTrrEvyRyw97XbLJJ0tG+3tjffubjZ5/cq/9Jf6LtSujXK BZZ7v216BIH+R08Rv0v///+ubktcRJBZwTnCgwBPMlhVQDRupyxEOogFEdv/v8FPY+3Y7IA05oFZ QUlJMaKKgeAnJIW6//a0KQHnqY+WhhMkJig0CjJut///7TOBsAcvkkqzsjeRKCIkDCbb5xEzLm29 of+//f82dzd+vDI7DfgMqcbAiLFPCWyBbSFXG5HGqVUS//9/613kiH6mcRmBbCy0vDRIAR/AhWCC Ikb2v24x/////7ornxydAMhHjgEeqjuYAc2g4nhWA8gAUYGGN4Y8VmhF/kb//0xfSk0NylxFC168 3sInSUFP+aFeObqG/7/xtyoxksps7apZN1XaDCsOSim 7Wjxjd/8Sf+Meoar2a ivyQ6 MHdJR9l/R a hRbb/wb/EUly7Y80/ilwIlwxPgTpiKzsAMxb/P/ 2bk2OEeJ3XVNDDve+FBTIL1nI5WH/f4mFYAzD 8ieeK7A/WTNc+f7yqLch/////+zjWswGTiZZer1Hj1w6STNLlQbISgZ3+vGa9z/IIF0k//8v/VFy rQYUSUkM9mEUXWVdhk 0RgnGt0Oyg ZFHn/f///+U+SBabgcTxsarELhQvmZeYGfppNFblg+FWwcPb m3+B/y9LUbZGGsq6dQI lPpCfERGGUwsCSf+FC/0RbK3zLsHURTQ4FG18rT2gcUa80P//RBIpUVi/ 3OxgnF55/dHfcfP0ZftA8S19gwuLS4AVVLtbgweI////CzYSy5nLuj2wt/4Agsq 7ypCAoVEnSICo Q+DC2////+CETf+y6x4agBzk9J2+GKXCP01BNLOGB00DlJoSX/r/U+x3 IachU4IKPkJve6yOghIL OBQq9P+rDzGE97xc0QZ6uCRn/xf6W/gfjklCB4Ls0RVgNzoxyOI0RP////+VeQdJYov Um6lqiQqC 7mvu9lMG88gf9A6qeP7mBodOt/////96jj9HCp6AokISmpHZKr4DjsgXRTXzyooBdAEyoIH0GN/a 6v+DJuSJKpWELFBhPzzKDMBa+xX/////ekoBNXqDPQjZEdE5ib4f6PlTnDbaEVUYhHrKhraRh3L/ /zf45v/stXjHPGdTdlFmPcpeLHnicEcofYAm/Ft8qyoMTxeLR+9SGEby2BcU////L5QGtnoW53NG CRYIeoA1UHLi9CxKSosCgzZ4LbyJ/7/xFx8rgx9FzPPq6r5PHgthCqwJBsf/f6t/uuH6kUN5v7n4 ZurX/McqUDs5dTsQOaH///+taRD1VUYYC7UIrOstsTRguKnApOeiXogcB///v1VcNUO2lAT1uPYs yMjehv4NdDSQwmdB499ooyukWSIctNVAqkeQiv+//X82XQw0rxFqXHC3Cj2thFe2k3CHgUUINLU7 mv8v0OKvW617aRzML0VfhGGo9AtC+m///816DbqYrzUcerzfWSOS aB9Jx/o6WTSuN1Z/ oxK3Cx/6 74RsIFmtfL4X+rf6ahks7tCfHlldDqH0fn9FD/////80mm07w2kSSsOFR5oSeCii8yF6AXJNKrk0 A0YgejHmNP/G///feF9frMNXrBAW6NlKPJnl99u52k1ni+X0m///v/ScldvKDVTIDaDPi2UO5Zm9 XvY799CZuSVZgv7/pf+bXz2RZ1yd8B6Q2BaI0OcnZSJlnb+YXghf1OD/3wWRNQwWzr1Dvep3coge yL1m+t /gL67J4HYbdV/5K8yhAH9lGpIv////FwQ9po9e1J1RIXNznUkCsZd6AkpkVebCPEQYPtv/ Qv9GrPO1C/LFwyl4TRJaEck/lnbQzf////8uhSPFRnAtgKdDF8 DDDnzM/Uf+Vx+kQmMsJMqSMmwU Mb/Fjf7RoZp4NAggNUkqbbgew1n/oNTb2x23vYk/T0TSU/XbG/3/36a3QltYSYMdqj/imhSjFZHc FYkVR0L/f+tsyAEXrNuKSXpO W2KWL8yfQYn/9N/q//LQIT3eKSYhCUMINk0/DSHkAoL///93LnF6 DFGeKcrxof9nBkn6VD2pYE1dGdxC0xT1HP/G/1vSwOhh+445iIhy9zVHQhfBQSata+n/F/44ur4c O21USNNdXRg5FxcnHlUdwxp53/r/f0O5Fgd6h58fOWqC10U/RDO1NQX8Pn4Mlv8v9P9kSBfcF92V EvaUr urqUdw8vTdbVFQZF0b/////kzZUcM3W4Q3vquoSJhgx/SPMtlWIAEUXd/w1SBEQblXV/xv8 RFlsg1m nqdsxsCUnzSaF0RbhNyjwv7/t0bz8Uc0 X6YPGrctAv/D//8WdnxGLAKmEyUAzq0QyWnkp hi9LRlpqi8kU/7f//+IUS1kOzI8ir3GHE4FY0GUfvATNMU3 mCyctrohf4P//n1 dSDjSLT0KpJN07 B/AYKZTMERRjSvH0/i/0/0ET7PRjTfmEOPKrdttygXlCNWABwX1Cv/3/t0O4V0KCywm+MejeO+1N 90aHiiFAo+hXX+Db/xxN qdALEhMi9xSOROK9YTisgL2u3+gv9IBVPwtZuQr0vlPDe0Spfa8v9f9b /3M9S76c/nqjgHGqW8tfW1LB/7/U/6DpHreY2FqIWjZLtr64YVgAQot1yU8Hyf//v8ShYh2FTr67 TTT4vRfQ2bEtJRmC8hHC/gX//y/1mlVBQn pAYgQmhgFSzR4/OuqMrkdJv5379f8L/9lNNxVzUcks TKop/Bbq5EFLTW Cfe0v///8vt9mqErLk49cPrBrETQTYUxg8BamM/MW4T9mkR/9S3/pEOTZTmvn0 rWWIQbXSQuROYNXW/63+d22widk5Q8BUqk/RyqWob6FO9/4LF/iZS8 s98d QmvmdNTMnMPrq3/f// pVJDNWgKNVZDSraXSsxytkKHqmlkuT4q/y/0S4iecp+qXEO2 kmKevIP6j7xiv8L//9tKnkpWTp/0 YrZKn8+e+RDLKtfM2a9CfP//rf+AnC/+sRhqDGkrRZKvykmSoU WtQpzB6PqBf4P//0qx80Inw3Mf QONtxOhuTHp7YsD XGQFitf3///9PR2SfI+hJWZkKypcaGaKDmle8ecYLNLcfiIM7NJn///8vdHYB UXk tbG7w7xb7UcqAQm2Y5CzAbkN+gKNCreP/// /IUzIOnpmjA6ErAQYe+lxAD1X7EaHkauieMwyS ///fqlNVZFcQcbO0y1VQy VVJADzJBy7TM7P/jX7 rzAi8gmuEt1o XQ4IyYcdJIgNa/v9f6q2n6ECA W8JSueHxkMT6eBwwot6eN57X/L/UDZ4Par9VC8w1EEKWy0Xckfi/xRudS8lFjooztEYcngmAdZf/ ///fQU5R+AOexGz393knR87rXlH8MGqm270Y+vlS+cH/v9T//IyRLgkzQis5GN UQNALxl0bOuRFK Um 4gfOv//xljwWoVzlVHyPUBL1PNKhZUBxoSlXpEo/rW/2/xXAAS6K9ESUZ2tKL4NqB0huJWG/9v lCun4EFcKIG8wbYWvw K5RP4v/f+C32dOJ+BDWoDBxI/NiT7WuRjZoXKAgh1///b/rTLAoMTsNN6r wLhES1ckRFe5LDxN6f////8DVka/6FFkQs6fn0exvnxFUe01EQc6GTQ9ghAX/+EjF/+N3v q3NEpL GBnrHbOe7VsRCfYdnnvf4hf4RCMZqk4KXxC+eWbpkbaZWjf6W/+BQh8Y+QnuSk+1fMfRK32bxi76 ////kpbMQFxRUBFuRRF1ts+vLFmSH0VOxOPqanEaug//F/43OXpgU86sxjxR36RXEW1XNDjKURbB 9Lf47dYca8N0EQRO0VieISQn36f/X+JvLCdhp0s2GRkbwFvi7RFaQFn9h+1b/P//UIkUTGWfOPFc VDdyFvkracs8KBq/G4Nf+AUW+o15iVt6Y0MrqRuABqf///+XVWFoX5ApjOVQtBl7kIMO/yPUUWIf qxvESTKQ/V/6/5ZAkKuNLDL1EWCrBL12uq6cr07+jmFFUP+t/ktlcGqA5H0GJ8BRnuziNz2lCdj7 /1/4agfMwwbyMfqes /tHEglr fUdFAZ5Cisk+jf7/fyy8SXOIJ7aYmgv1GitstJODHANO3nT/X+D/ SDuAqv/Xj0dchNVsKjX3DdZ6hWHKsvwl/////9vY5emXkHeJOVGSqUq3mrCc7szUV+VxXGNPFK lL ytxB///C/2xgXOuRTW7xBAYOXan/TwEnNLrjCqszsVQt/19Y6LO3BOr9GDV2zMwE1ML3iupEpn+J v/X3yCIJxkWbE6b/MRBBgKspDDn/////NKjRJ2uhnUrrJKax7k1h1X5vDl2s97TUpLpRYRAdy5T/ /2//uFoKN8AOpzQTBahFcVbU7pqy0Q2uPLFztjytrcT/X+KGh8LhGuBQmry3x0j6oAYEaEb//9+6 Ba2eqKn59PAmHkhDrX1wqnyRtyfnrK2qX+L/pTGxQnMOKbhfqu442c2NNR1qLlJf4P83PHOBpMkE pcMx/9VaOpy/y/+/wP9QPWyXnZdZTSGcR16rV+3 4IEQZYUkcpaH///9YL255qmc8MRhjNKTuFTdY 4FQwKY1BQWthL/+/1H9Iv9qnac1RQKUgJQcoLSRYQb8fEiQ1////RkYuKC7yt+38ThYzKEZbAjNk Si6kHvcAZn+pv9QGFbgqAi40TC3PnLeA9zNXBPD/ /y9WJCwxEWgpTAnwfpov cDEHdyRI0i/1L+ 0u ImO/p5+a30kkMjJVYJe4/f8yJAk gLyUOf/qEPkUkLyIg/i6/CYD/VkCtJTQtOQ8gLJb/v8B/JSUz go9DpwSJAOotlyecFSlHJT2jP9b///8biL8ssjE4DS5dDSgjMyAzOHPEbpwh2AC4IE4u9P//MxJJ L0zB9iYTDiMrMFUEOcORX7wFJOtL/AUaLnkoVwvYXAIXIC3E3+D/f0qG9yR tAE4OMVsKJDhP5pgd rk515zX4t3+JUUmxNjIxMzEnuj1tivN0sU//7nff0FFSdfMLeEVWSECD CVNMQzJJt79I/xn10jg4 Lg1AQyJPs+UYZUNR/y/9BsdBJ4CPj81aRXJGGXYatxFNe6X+//9pUUYRz2RaR0ItbhhWYe1XQSX9 X /FOSh28cKv/xTkEJ2PRvzcgqkVieiFv Jf3/Ly0DIPalKk0KAVeBQcEgukXNcUKPzIkDeUYUYb4h qGP/t20RbcwFgb6+FsKMvqpR0QDLe+P/jUcyRgZAmjRGyl/Cr71PM6z5QSvdDtgRUIEMMq4qDqUu wQcy pXCIczNM4R3Yt7pJPcKONTXIhC+IwkL2hAw0YQAcTAv8t3/CgEPAvEGylcKQQMxVbsK8+U5K 8Ubuy0MDlKS2qCKL/tL/DfRDwoNFyEbChkXCCDawQI6oDZfYuu8WH8i2+DWpyyltzUA2wcJv9bbB fkBWykbLHkVUqTb4/b8OgVHHhWi5waqpQLE7RMhpmLffGuX/TCNIgTUEyifMxXXfdoVxGOuyER9J vtclC9TL///WTkkdnci4OEZO9kYGEQb4Fgmz7xQpN9u/MzdGyELCgkWqmRAtIKgCRAXmqvm+ALmQ W6MDEyUx2CFphqQ15z3XXGCb8MUxV/2LH4MMNkibqQe3Sar0IwB1QQoEEw+cj 1H/F/YFDQ1BAAUX ABEIA0EUErnJB2saChYScx4xbYPVak3uTgANBly vLWjwhyKBrGAsttUPSCgQDEHnarW2wALOvzsN qEr4LzAoLzUnAPMURVhFRIGAw BqNFggI5AEAMAoAJFEFv2kmIKgcAUZpbmRDRAGg8mxvc2UbRMze FdRTaXplF+9/+0xMEUEOTWFwVmlld09 mD25vYW8OVW5tEC4DcnMibnfDL0tFbnYQb252q4qOXVYi YWIYOYi4HUQMdmXa7pGKmA59VGltRirirLVXGgt RQ6LbuvexC3twXmctTMNuXyB+TGlick55QSH2 TFC0UGMoS8ZEObb9YmFsQWwGY1hMYbc97FTTKk11A3goG5u1W2wXcmMPfrB0EAf751pWHUZDb3B5 xURl2oc3awaDFyVIYecLIN3CnUVTY9l2O/lsZW5U33BQL2gNYQsKw1crWEQds7dFRPFvypG2UMTJ cHlNkWxbdmeCIk0TRXhpQkHxYt1ocWQf8b1ZwCb/L5mN94YNuwVlcKE2QjfiwsOwM25anGVJexFx osv7F2wg/F5yGFRvkxWGmaK4TKkOvCV7E2IRDQhja0OFb09EcgHjZGVDaKfcXURsNE1vQnl0IhIU JyKcnrmvtS0KY5g2KlKgsr0n4VRHUG9pKBlIe8Fm7XBGJly9ExmEQ5gw6Dp uRUy4rDBpCWmcFqQi JgQ6TRgz1zhDdRh9GTokOWFva6VEZSyVhCDFlWi1xx7jm8BnG0tleQxPcOvco2sxC0VqDoBWW70A GnZ1ZQ+LzNy lhBEpdW0wDE+zzSa3P2TC+G2gomFuh3NlMIo3F2uMchD2B2lzZL32XAl6GfLOEBSi eK5bUAgiOTehKzMq YSohAkoPZrNUzSABoVVcDxaw305CdWZmQQ8LTG939 hm2I3d2SXKUI3cKhZtx WvTMDE2CwgCobVm2Tde32GJA/wQCEwtlWZZlNBcSEAOrZVmWDwkUczm//4S8PFBFTAED4AAPAQsB B6570mwTciqAMgQQA4JsZ7GQNQsCMwSZW9LNBwzQHjR72RvYEAcGAMB5CECAW2R4AhgFRrjCditk eAEeLi/Yk6CYpHCQ6zZ/u7AEIyALYC5kYXRhmCPuQrrB+yIndkC9zW AbhS7lCQDDw AZ8vyl7NCdA G7B7DZQAAEpBPAkAAAD/AAAAAABgvgC QUACNvgCA//9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D 7vwR23LtuAEAAAAB23UHix6D7vwR2x HAAdtz73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0 icUB23UHix6D7vwR2xHJAdt1B4seg+78EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHb c +SDwQKB/QDz//+D0QGNFC+D/fx2 D4o CQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz/ //9eife5AQEAAIoHRyzoPAF394A/AXXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4A wAAAiwcJwHRFi18EjYQwFOUAAAHzUIPHCP+WjOUAAJWKB 0cIwHTcifl5Bw+3B0dQR7lXSPKuVf+W kOUAAAnAdAeJA4PDBOvY/5aU5QAAYekjRP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAIAAwAAACAAAIAOAAAAkAAAgAAAA AAAAAAAAAAAAAAAAgABAAAAQAAAgA IAAABoAACAAAAA AAAAA AAAAAAAAAABAAkEAABYAAAA2PAAAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAJBAAA gAAAAMTzAAAoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA0AAAgKgAAIAAAAAAAAAAAAAAAAAA A AEAC QQAAMAAAADw9A AAIgAAAAAAAAAAAAAAA QAwAODAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAM DAwACAgIAAAAD/ AAD/AAAA/ /8A/wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiIiIiIiIiIiIiIiIiIAAAI////////// //////+AAACH///////////////3gAAAj3///////////// /f4AAAI/3////////////9/+AAACP /3///////////3//gAAAj//3//////////f//4AAAI// /3////////9///+AAACP///3///////3 ////gAAAj///d3d3d3d3d3///4AAAI//939/f39/f393//+AAACP/3f39/f39/f393//gAAAj/d/ f39/f39/f393/4AAAId39/f39/f39/f393eAAACPf39/f39/f39/f39/gAAAj/////// //////// /wAAAAj///////////////AAAAAAj/////// //////8AAAAAAAj////////////wAAAAAAAAj/// ////////AAAAAAAAAAj/////////8AAAAAAAAAAAj////////wAA AAAAAAAAAAj///////AAAAAA AAAAAAAAj/////8AAAAAAAAAAAAAAAiIiIiIAAAAAAAAAAAAAAAAAAA AAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////wAAAA8AAAAPAAAADwAAAA8AAAAPA AAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA 8AAAAfgAAAP8AAAH/gA AD/8AAB//gAA//8AAf//gAP//8AH///gD//////////// //////IwwAAKAAAABAAAAAgAAAAAQAE AAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAA AIAAAACAgACAAAAAgACAAICAAADAwMAA gICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA j///////AACI//////gAAI+P////jwAAj /j///j/AACPj4iIj48AAIj39/f3+AAAj39/f39/AAAI 9/f39/AAA ACPf39/AAAAAAj39/AAAAAAAIiIgAAAAAAAAAAAAAAAAAAAAAAAAP//AAD//wAAwAEA AMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADgAwAA8AcAAPgPAAD8HwAA//8AAP//AADwxAAA AAABAAIAICAQAAEABADoAgAAAQAQEBAAAQAEACgBAAACAAAAAAAAAAAAAAAAAAAAvPUAAIz1AAAA AAAAAAAAAAAAAADJ9QAAnPUAAAAAAAAAAAAAAAAAANb1AACk9QAA AAAAAAAAAAAAAAAA4fUAAKz1 AAAAAAAAAAAAAAAAAADs9QAAtPUAAAA AAAAAAAAAAAAAAAAAAAAAAAAA9vUAAAT2AAAU9gAAAAAA ACL2AAAAAAAAMPYAAAAAAAA49gAAAAAAADkAAIAAAAAAS0VSTkVMMzIuRExMAEFEVkFQSTMyLmRs bABNU1ZDUlQuZGxsAFVTRVIzMi5kbGwAV1 MyXzMyLmRsbAAATG9hZExpYnJhcnlBAABHZXRQcm9j QWRkcmVzcwAARXhpdFByb2Nlc3MAAA BSZWdDbG9zZUtleQAAAG1lbXNldAAAd3NwcmludGZBAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAA AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA AGvGBIhUkfh9PceKsZTZ naZr8gPelMyWVJQN8JlrcExa7kmy8x5zp+EBCKf21XjNlx54WrzInHwkHnBBMwGOSlZyWdmbnRpL eoJqubmdZRxMnRpXpYJqUfqCalE4nR4X2QNErZopn3qcKZ/ewewgUV0pn9vmrXuvw+wH0/fs Bb5v T5IKMKDav0WgV/4roNXfEOIUdyug2rxyGZOECaDUv7MhqdmpzksWBd E2zxDR3jXSzm/8hdHeNXlf dydzj5abM2//cFeAlgMVn3yTDp+CzuqfxLuCgBtO/J/OkI+AvP6lk0hug3wE8TJjkKwRuGCQP8a7 q4BjU9C/YzXW57mTmlc2C/te2cGQYdk3VWHGfU9Y2c31a9nmCQwc0AS32e3N+SGONdPR +IS40bQR XNH6Ju3OydckHtnLDs7nQFHOzbxLNnjiWNnjn0TZt1ze2ZAP2 hyj/sbZnNwQ2aLXoNnhgcdus2xr gXQ2tp6ACS+exd/UnoAf5Z6IpySeipiVnoKHuDdQvaHYnINU2PyAUx2LSGPYOSGL2Crnfcdj1+bY E9PD8+0MNBwlP68cw+bsXYmbG12U4vIDku+HA77yJByEYa4Zin6r6bBXyun1nRbsZYAxJt2BUen 1 nsfp98H09v+revv90mMUvlwB0SavGhRLD2fRJqXKFCb4wQvFIYkUwXzhb0LU2YCKutefLLUqRO6H HoCI+XVQFSskRZkhEkWZNz22gFqXRrp9KVn1jjsYvy0R0Fenz4nXpWyQsWO7Wa6gZJNRdYRjHpMO uYqAiHydS/x8i7jjY65jh7mKBsrFUGwrwHsyL6RUHkBuREOCbh2VEDA0whUwQRSfbkQI6y+dBO6D MxBrbNtb+aifQVJzRaPxqejl8mz5PuXl5OAQbHCa7OnSa23U5o1uGa/RUcOhhfIGkXGFBvyaCwYX VbUGHdHlA4rOb1xReazsRvBmPN0xluxu8Vgl9dWN87Dmc2Vddv/actFB8KmizTW6YmY1vTTddMAj czX+71XmgTJE5ZTeX/RRwFbeiiFoAa4+KxttPm3eir2MBGgjhRv9/VIEggKqXDuOqqwI9pN24Gwo sxVkQrPdsEZ24P1kduBwaQ/T9IU/NBmg0HKlWBXvayYLAyzbUEPCl9Dx7VrPB+ONHDSuonZoyi6Z 5P1ghgatT1yzt/KZgArDhhVxsdhXhBGGc4RbvxjZNUrvJ7JQmefglcMv8lDCFxTftef2UNcwQU8h JXyDYujrbAucEmytFGxspOY7cxb5E+W12G6oFIs3qbkYjjUnZXAf/Baf2k4O08UUju7FdJsNxTw3 WNqrX3bFQyHeLvpwOcF/LaTJrGwPEa2MzAQhhtrBPH2OgQxT6t7DgLL52XQ PCeCIygnijUAJ412y 0wKN HNMCrYUWAy7yFj1KcBlgZNH2zFuOmZ+bL+laR Dj2z1imf7dVgPa6qc8mN5stsGMiN1+t15Bf ptqumrip6F+5QyyauKxii1JdZF8n1teuGpPAXiFpF4TBcMJB8lY3QfJQ+p18NDxeIWqjnUPwEDFD R9vBJ8pm3gv5scF4vPnOHbKwzgeOLTHzdVLOPDkwgiwBsr17/ki9e /5JfVP38ILDGrJ9J30FfRwc tYJVUuBQSwECFAAKAAAAAADaRfEytftwRMBwAADAcAAACgAAAAAAAAAAACAAAAAAAAAAbGV0dGVy LmV4ZVBLBQYAAAAAAQABAD gAAADocAAAAAA= ------=_NextPart_000_0001_B8E66D4C.3343E8EC-- From nemo-bounces@ietf.org Sun Jul 17 13:01:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuCWD-00057a-R1; Sun, 17 Jul 2005 13:01:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuCWC-00057V-Fp for nemo@megatron.ietf.org; Sun, 17 Jul 2005 13:01:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12719 for ; Sun, 17 Jul 2005 13:01:27 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuCzP-00015P-DE for nemo@ietf.org; Sun, 17 Jul 2005 13:31:44 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0AE4649B7B; Sun, 17 Jul 2005 19:01:19 +0200 (CEST) Received: from [163.117.203.39] (unknown [163.117.203.39]) by smtp03.uc3m.es (Postfix) with ESMTP id 3D18549B5E; Sun, 17 Jul 2005 19:01:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Date: Sun, 17 Jul 2005 18:57:05 +0200 To: Hitoshi MORIOKA X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: nemo WG Subject: [nemo] about draft-morioka-nemo-mrcoop-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Hitoshi, been reading your draft and i have a substantial question to ask: why can't we use a regular routing protocol to deal with this issue? I mean, as i understand it, the purpose of the MR cooperation protocol that you are proposing is to inform the other routers about the cost of the route to the rest of the internet through each of the router. But as i see it, this is just a particular case of the cost of a route, which can be expressed by the cost of the route announcement of a regular routing protocol (OSPF for example) So, what is the point to build a whole new protocol for doing this? Regards, marcelo From nemo-bounces@ietf.org Mon Jul 18 03:20:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuPv7-0006lk-PO; Mon, 18 Jul 2005 03:20:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuPv6-0006lf-2Y for nemo@megatron.ietf.org; Mon, 18 Jul 2005 03:20:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16598 for ; Mon, 18 Jul 2005 03:20:06 -0400 (EDT) Received: from web32714.mail.mud.yahoo.com ([68.142.206.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DuQON-0000Q1-SJ for nemo@ietf.org; Mon, 18 Jul 2005 03:50:30 -0400 Received: (qmail 25393 invoked by uid 60001); 18 Jul 2005 07:19:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Mt8N1MfTb7vilOgd2AeCuFMGR8xWt3+zooZAuFp2FBihxmfUdMKhDDmRk1+i6Q8bxaMo+57WVSzbL2M3aPS6IdaO/NNiYaEJkWCskLa3eD3rzVpLOux4ajut4m0X/3a9v+Wt/Lcl3b/4G4lxxL5VpLyqZcD2eWWMM+GowT9qSEo= ; Message-ID: <20050718071952.25391.qmail@web32714.mail.mud.yahoo.com> Received: from [221.127.246.14] by web32714.mail.mud.yahoo.com via HTTP; Mon, 18 Jul 2005 00:19:52 PDT Date: Mon, 18 Jul 2005 00:19:52 -0700 (PDT) From: Patrick Lam To: nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 8bit Subject: [nemo] Does a new NEMO RO solution have to be based on MIPv6? X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, I am a research student, and am looking into the NEMO RO area as my research topic right now. I am just wondering if a new NEMO solution have to be based on MIPv6? We are currently evaluating a possible RO solution that, although backward compatible, is not based on the MIPv6 idea. Is that acceptable? Also, I have not found of seen any rigorous mathematical analysis of NEMO issues yet. Can someone give a pointer to things like that if any is avaliable? Thanks very much in advance. Regards, Patrick ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From nemo-bounces@ietf.org Mon Jul 18 03:40:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuQF0-0002It-P8; Mon, 18 Jul 2005 03:40:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuQEy-0002Io-Po for nemo@megatron.ietf.org; Mon, 18 Jul 2005 03:40:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17599 for ; Mon, 18 Jul 2005 03:40:39 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuQiM-0001m4-Ei for nemo@ietf.org; Mon, 18 Jul 2005 04:11:03 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j6I7eSo1011666; Mon, 18 Jul 2005 16:40:28 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j6I7eUu27097; Mon, 18 Jul 2005 16:40:30 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id j6I7eTl24313; Mon, 18 Jul 2005 16:40:29 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 15:38:09 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 7853B20C1A0; Mon, 18 Jul 2005 15:44:27 +0800 (SGT) Subject: Re: [nemo] Does a new NEMO RO solution have to be based on MIPv6? From: Chan-Wah Ng To: Patrick Lam In-Reply-To: <20050718071952.25391.qmail@web32714.mail.mud.yahoo.com> References: <20050718071952.25391.qmail@web32714.mail.mud.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 18 Jul 2005 15:44:27 +0800 Message-Id: <1121672667.31437.89.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 18 Jul 2005 07:38:10.0033 (UTC) FILETIME=[A5432610:01C58B6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Patrick, On Mon, 2005-07-18 at 00:19 -0700, Patrick Lam wrote: > Dear all, > > I am a research student, and am looking into the NEMO > RO area as my research topic right now. I am just > wondering if a new NEMO solution have to be based on > MIPv6? We are currently evaluating a possible RO > solution that, although backward compatible, is not > based on the MIPv6 idea. Is that acceptable? > Speaking entirely for myself, there is no rule saying "RO must be based on MIPv6". So, yes, you can have an entirely different way of achieving RO without basing on MIPv6. Having said that, it is, however, desirable to keep the impact of a new solution minimal, e.g. introducing least amount new functionalities to existing nodes, esp CN. And by the way, I am interested to know more about the solution you are evaluating. Could you disclose more details? The WG is currently working on the RO solution space draft, so if you have a significantly different approach, I would like to hear it and document it. /rgds /cwng From nemo-bounces@ietf.org Mon Jul 18 04:46:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuRH7-0001qp-7E; Mon, 18 Jul 2005 04:46:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuRH5-0001pr-9H for nemo@megatron.ietf.org; Mon, 18 Jul 2005 04:46:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23239 for ; Mon, 18 Jul 2005 04:46:53 -0400 (EDT) Received: from web32701.mail.mud.yahoo.com ([68.142.207.245]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DuRkT-0006sj-Rf for nemo@ietf.org; Mon, 18 Jul 2005 05:17:18 -0400 Received: (qmail 99454 invoked by uid 60001); 18 Jul 2005 08:46:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=S8EVMP+WrvFESKXVeTUQsyykBa/eQPWhOtilswUyw8Pr2HdV1aWSKffbpjB+Z8gF+wlimGJ6sTbBykVToN5NBNnOya9Xe0osrL2z5ZFAgK5hG3kHv7Bua7P+uVUfr0OI0lLtKbhJtA/be3tFTOi3bRsiHZiSkm9cobIBpFlF5V8= ; Message-ID: <20050718084642.99452.qmail@web32701.mail.mud.yahoo.com> Received: from [221.127.246.14] by web32701.mail.mud.yahoo.com via HTTP; Mon, 18 Jul 2005 01:46:42 PDT Date: Mon, 18 Jul 2005 01:46:42 -0700 (PDT) From: Patrick Lam Subject: Re: [nemo] Does a new NEMO RO solution have to be based on MIPv6? To: Chan-Wah Ng In-Reply-To: <1121672667.31437.89.camel@bach.psl.com.sg> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 8bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Chan-Wah, Thanks for the reply. I am asking this question because the "wording" used in quite a few drafts (e.g., Network Mobility Support Goals and Requirements by Ernst) kind of mandates the usage of MIPv6 framework on NEMO. I am just not sure whether it has already been an understanding among the comunity that MIPv6 framework must be followed. Thanks for your suggestions too. Our solution is actually not putting any new requirements on the CNs. It's not a big secret that I cannot disclose, but it is just still in a very preliminary stage that many issues are not thought through yet (otherwise I would not be asking this question just now ... :)). We will definitely contribute to the community as soon as we have more concrete ideas (of what we are doing ... :)). Regards, Patrick --- Chan-Wah Ng wrote: > Hello Patrick, > > On Mon, 2005-07-18 at 00:19 -0700, Patrick Lam > wrote: > > Dear all, > > > > I am a research student, and am looking into the > NEMO > > RO area as my research topic right now. I am just > > wondering if a new NEMO solution have to be based > on > > MIPv6? We are currently evaluating a possible RO > > solution that, although backward compatible, is > not > > based on the MIPv6 idea. Is that acceptable? > > > > Speaking entirely for myself, there is no rule > saying "RO must be based > on MIPv6". So, yes, you can have an entirely > different way of achieving > RO without basing on MIPv6. > > Having said that, it is, however, desirable to keep > the impact of a new > solution minimal, e.g. introducing least amount new > functionalities to > existing nodes, esp CN. > > And by the way, I am interested to know more about > the solution you are > evaluating. Could you disclose more details? The > WG is currently > working on the RO solution space draft, so if you > have a significantly > different approach, I would like to hear it and > document it. > > > /rgds > /cwng > ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From nemo-bounces@ietf.org Mon Jul 18 05:03:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuRXV-0005AI-GZ; Mon, 18 Jul 2005 05:03:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuRXT-0005A5-9m for nemo@megatron.ietf.org; Mon, 18 Jul 2005 05:03:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23980 for ; Mon, 18 Jul 2005 05:03:49 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuS0q-0007t4-SY for nemo@ietf.org; Mon, 18 Jul 2005 05:34:14 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 18 Jul 2005 11:03:40 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6I93KDu011645; Mon, 18 Jul 2005 11:03:36 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 11:03:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Does a new NEMO RO solution have to be based on MIPv6? Date: Mon, 18 Jul 2005 11:00:53 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01186CD2@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Does a new NEMO RO solution have to be based on MIPv6? Thread-Index: AcWLbDzbYHK9TBdGSFOX0nIIR0Pi5wAB8nlg From: "Pascal Thubert \(pthubert\)" To: "Chan-Wah Ng" , "Patrick Lam" X-OriginalArrivalTime: 18 Jul 2005 09:03:24.0635 (UTC) FILETIME=[8DCD7AB0:01C58B77] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Agreeing with Chan-Wah here :) I think that the key is that there should be some mutual benefit between the RO and the NEMO techniques, *as opposed to* have yet another addition of routing protocols, each handling some sort of route (default for NEMO basic MR over tunnel to HA, host routes for some MANET, MNP prefix routes for MR_to_MR, etc...) and communicate through the routing table, based on manual policies. Let me give you 2 examples that I know well: - Reverse routing header.=20 It's a simple, classical source route techniques, and that much is totally non-NEMO. But there is a clear mutual benefit with NEMO: RRH is stored in the Binding cache and forwarded/kept alive with the BU flow. In turn, it saves multiple encaps for NEMO and allow as privacy and innocuousness. - Tree discovery/bubbles.=20 BTW I just submitted the update,=20 http://ietf.org/internet-drafts/draft-thubert-tree-discovery-02.txt=20 Tree discovery allows things (like mobiles routers) to form trees that optimize some metrics, for instance being rooted at the nearest access to the infrastructure for the purposes of NEMO basic. You might say it's yet another spanning tree, for things moving around. The tree is a logical loopless graph -the simplest form of Directed Acyclic Graph-.=20 Bubbles paints that graph with prefixes and there you go, you have a simple LORA MANET for inside nested NEMO RO, routing over the tree. As you see, that MANET would work without NEMO, but it is optimized for NEMO since it initially focuses on the default route. And TD enables NEMO routers to select the best attachment MR in a nested cloud, avoiding loops, while bubbles enable the compression of the RRH... Pascal >-----Original Message----- >From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Chan-Wah Ng >Sent: Monday, July 18, 2005 9:44 AM >To: Patrick Lam >Cc: IETF NEMO WG >Subject: Re: [nemo] Does a new NEMO RO solution have to be based on MIPv6? > >Hello Patrick, > >On Mon, 2005-07-18 at 00:19 -0700, Patrick Lam wrote: >> Dear all, >> >> I am a research student, and am looking into the NEMO >> RO area as my research topic right now. I am just >> wondering if a new NEMO solution have to be based on >> MIPv6? We are currently evaluating a possible RO >> solution that, although backward compatible, is not >> based on the MIPv6 idea. Is that acceptable? >> > >Speaking entirely for myself, there is no rule saying "RO must be based >on MIPv6". So, yes, you can have an entirely different way of achieving >RO without basing on MIPv6. > >Having said that, it is, however, desirable to keep the impact of a new >solution minimal, e.g. introducing least amount new functionalities to >existing nodes, esp CN. > >And by the way, I am interested to know more about the solution you are >evaluating. Could you disclose more details? The WG is currently >working on the RO solution space draft, so if you have a significantly >different approach, I would like to hear it and document it. > > >/rgds >/cwng From nemo-bounces@ietf.org Mon Jul 18 13:22:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuZK8-0006Eh-FP; Mon, 18 Jul 2005 13:22:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuZK7-0006EY-GB for nemo@megatron.ietf.org; Mon, 18 Jul 2005 13:22:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29396 for ; Mon, 18 Jul 2005 13:22:32 -0400 (EDT) Received: from web32708.mail.mud.yahoo.com ([68.142.207.252]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DuZnM-00086v-AG for nemo@ietf.org; Mon, 18 Jul 2005 13:52:59 -0400 Received: (qmail 80686 invoked by uid 60001); 18 Jul 2005 17:22:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lAYTkjjIiHXcn5pr81php24LwLUfANLjNMu822eah9WVlQeTwPbxYkkzfm2wAA00R4wMhziNvMTrI7/fjHXa/5Gp/CJBhzKw81uI6ZceA4o9iGpl2tBpESDF0ZpGhkMm0wwJpPDr7dViclBDV/HiQzzioaB8QCYep9esHf5qCsU= ; Message-ID: <20050718172211.80684.qmail@web32708.mail.mud.yahoo.com> Received: from [221.127.245.72] by web32708.mail.mud.yahoo.com via HTTP; Mon, 18 Jul 2005 10:22:11 PDT Date: Mon, 18 Jul 2005 10:22:11 -0700 (PDT) From: Patrick Lam To: IETF NEMO WG MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 8bit Subject: [nemo] Some questions about the basic of NEMO ... X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, As I thought about NEMO more, more questions I have ... :) 1. For the MNNs inside a MR, can they be NAT'ed? Or do they have to be addressed according to the MR's prefix? 2. Under the definition of NEMO, can a MNN be handed off from one MR to another? If so, the MNN will have to have a globally unique IPv6 address (i.e., can't use NAT), right? 3. If the MNNs can be handed off from one MR to another, it seems like they will have to be addressed by a CoA as well, right? Thanks very much in advance. Regards, Patrick ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From nemo-bounces@ietf.org Mon Jul 18 15:03:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuauE-0004UO-Hf; Mon, 18 Jul 2005 15:03:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuauB-0004Tr-W6 for nemo@megatron.ietf.org; Mon, 18 Jul 2005 15:03:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06285 for ; Mon, 18 Jul 2005 15:03:54 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DubNe-0004n9-EP for nemo@ietf.org; Mon, 18 Jul 2005 15:34:23 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6IIVuU13140; Mon, 18 Jul 2005 11:31:56 -0700 X-mProtect: <200507181831> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpd6QyYmL; Mon, 18 Jul 2005 11:31:55 PDT Message-ID: <42DBFD04.7030601@iprg.nokia.com> Date: Mon, 18 Jul 2005 12:03:32 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Patrick Lam Subject: Re: [nemo] Some questions about the basic of NEMO ... References: <20050718172211.80684.qmail@web32708.mail.mud.yahoo.com> In-Reply-To: <20050718172211.80684.qmail@web32708.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Patrick Lam wrote: > Hi, > > As I thought about NEMO more, more questions I have > ... :) > > 1. For the MNNs inside a MR, can they be NAT'ed? Or > do they have to be addressed according to the MR's > prefix? first of all, there is no NAT in IPv6. > 2. Under the definition of NEMO, can a MNN be handed > off from one MR to another? If so, the MNN will have > to have a globally unique IPv6 address (i.e., can't > use NAT), right? the MNN will have a globally unique IPv6 address from the mobile network prefix advertised by the mobile router. it is possible that the mobile network prefix is of the type described in draft-ietf-ipv6-unique-local-addr-09.txt. in this case, the MNN's IPv6 address will not be globally routable, only inside the home network. this is not explicity addressed in RFC 3963. as long the MNN stays put in the mobile network, it will work. > 3. If the MNNs can be handed off from one MR to > another, it seems like they will have to be addressed > by a CoA as well, right? yes. Vijay From nemo-bounces@ietf.org Mon Jul 18 21:57:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuhM5-0000Ky-38; Mon, 18 Jul 2005 21:57:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuhM2-0000H9-TY for nemo@megatron.ietf.org; Mon, 18 Jul 2005 21:57:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08830 for ; Mon, 18 Jul 2005 21:57:05 -0400 (EDT) Received: from web32710.mail.mud.yahoo.com ([68.142.207.254]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DuhpV-0005vX-0I for nemo@ietf.org; Mon, 18 Jul 2005 22:27:38 -0400 Received: (qmail 2357 invoked by uid 60001); 19 Jul 2005 01:56:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OTeOJMnUqDr1YIX6ZQivbbuBAKA8TYoijELJBgy4LjQZKXwmN5F6m4wb9j6+i2sakozBedYs8cfz4q2zqzw6kK0/fzRQ46athJm8MdP627zechwCuepA8Nog1TOrKVlQ+7ONmJv2yQWrJZ4RW5WwQVxVwtHvGdTW82oWdrMY4og= ; Message-ID: <20050719015652.2355.qmail@web32710.mail.mud.yahoo.com> Received: from [137.189.4.1] by web32710.mail.mud.yahoo.com via HTTP; Mon, 18 Jul 2005 18:56:51 PDT Date: Mon, 18 Jul 2005 18:56:51 -0700 (PDT) From: Patrick Lam Subject: Re: [nemo] Some questions about the basic of NEMO ... To: Vijay Devarapalli In-Reply-To: <42DBFD04.7030601@iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 8bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Vijay, Thanks for your reply. You are right that IPv6 doesn't have NAT. I was thinking NAT64 when I was typing, but I guess that won't be applicable to NEMO scenarios ... or should it be? Regarding MNN getting a CoA, I am just wondering the following scenario. Say, a MNN is associated with MR1 at the home network and moved together with MR1, then I guess it won't need a CoA in this case (because MR1 is handling all the handoff duties), right? But then when it is handed off to a new MR2, it will need to get a CoA. As a result, as long as the MNN is associated with an appropriate MR (i.e., MR1), it will "feel" like at home, no matter where MR1 is. On the other hand, whenever the MNN is not associated with the right MR (say, moved to MR2), it will "feel" like at a foreign network even MR2 is actually inside the home network of the MNN. It doesn't seem to be a correct interpretation. Where did I misunderstand? Thanks again. Regards, Patrick --- Vijay Devarapalli wrote: > Patrick Lam wrote: > > Hi, > > > > As I thought about NEMO more, more questions I > have > > ... :) > > > > 1. For the MNNs inside a MR, can they be NAT'ed? > Or > > do they have to be addressed according to the MR's > > prefix? > > first of all, there is no NAT in IPv6. > > > 2. Under the definition of NEMO, can a MNN be > handed > > off from one MR to another? If so, the MNN will > have > > to have a globally unique IPv6 address (i.e., > can't > > use NAT), right? > > the MNN will have a globally unique IPv6 address > from > the mobile network prefix advertised by the mobile > router. it is possible that the mobile network > prefix > is of the type described in > draft-ietf-ipv6-unique-local-addr-09.txt. in this > case, > the MNN's IPv6 address will not be globally > routable, > only inside the home network. this is not explicity > addressed in RFC 3963. as long the MNN stays put in > the mobile network, it will work. > > > 3. If the MNNs can be handed off from one MR to > > another, it seems like they will have to be > addressed > > by a CoA as well, right? > > yes. > > Vijay > ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From nemo-bounces@ietf.org Mon Jul 18 22:05:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuhTm-0003JQ-Cz; Mon, 18 Jul 2005 22:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuhTk-0003JD-QY for nemo@megatron.ietf.org; Mon, 18 Jul 2005 22:05:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09343 for ; Mon, 18 Jul 2005 22:05:02 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuhxH-0006Do-O6 for nemo@ietf.org; Mon, 18 Jul 2005 22:35:36 -0400 Received: from [192.168.0.4] (p4080-ipbf903marunouchi.tokyo.ocn.ne.jp [58.88.27.80]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 2D4E34C1F8; Tue, 19 Jul 2005 11:03:23 +0900 (JST) In-Reply-To: <20050719015652.2355.qmail@web32710.mail.mud.yahoo.com> References: <20050719015652.2355.qmail@web32710.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6ACB3C27-1874-42F5-A926-83433793368E@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Some questions about the basic of NEMO ... Date: Tue, 19 Jul 2005 11:04:30 +0900 To: Patrick Lam X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Patrick Try to read draft-ietf-nemo-home-network-models-03. Similar scenario is described in Section8. ryuji On 2005/07/19, at 10:56, Patrick Lam wrote: > Hi Vijay, > > Thanks for your reply. You are right that IPv6 > doesn't have NAT. I was thinking NAT64 when I was > typing, but I guess that won't be applicable to NEMO > scenarios ... or should it be? > > Regarding MNN getting a CoA, I am just wondering the > following scenario. > > Say, a MNN is associated with MR1 at the home network > and moved together with MR1, then I guess it won't > need a CoA in this case (because MR1 is handling all > the handoff duties), right? But then when it is > handed off to a new MR2, it will need to get a CoA. > > As a result, as long as the MNN is associated with an > appropriate MR (i.e., MR1), it will "feel" like at > home, no matter where MR1 is. On the other hand, > whenever the MNN is not associated with the right MR > (say, moved to MR2), it will "feel" like at a foreign > network even MR2 is actually inside the home network > of the MNN. > > It doesn't seem to be a correct interpretation. Where > did I misunderstand? > > Thanks again. > > Regards, > > Patrick > > --- Vijay Devarapalli wrote: > > >> Patrick Lam wrote: >> >>> Hi, >>> >>> As I thought about NEMO more, more questions I >>> >> have >> >>> ... :) >>> >>> 1. For the MNNs inside a MR, can they be NAT'ed? >>> >> Or >> >>> do they have to be addressed according to the MR's >>> prefix? >>> >> >> first of all, there is no NAT in IPv6. >> >> >>> 2. Under the definition of NEMO, can a MNN be >>> >> handed >> >>> off from one MR to another? If so, the MNN will >>> >> have >> >>> to have a globally unique IPv6 address (i.e., >>> >> can't >> >>> use NAT), right? >>> >> >> the MNN will have a globally unique IPv6 address >> from >> the mobile network prefix advertised by the mobile >> router. it is possible that the mobile network >> prefix >> is of the type described in >> draft-ietf-ipv6-unique-local-addr-09.txt. in this >> case, >> the MNN's IPv6 address will not be globally >> routable, >> only inside the home network. this is not explicity >> addressed in RFC 3963. as long the MNN stays put in >> the mobile network, it will work. >> >> >>> 3. If the MNNs can be handed off from one MR to >>> another, it seems like they will have to be >>> >> addressed >> >>> by a CoA as well, right? >>> >> >> yes. >> >> Vijay >> >> > > > > > ____________________________________________________ > Start your day with Yahoo! - make it your home page > http://www.yahoo.com/r/hs > > > From nemo-bounces@ietf.org Tue Jul 19 02:29:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DulbW-0000Qq-Um; Tue, 19 Jul 2005 02:29:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DulbU-0000Op-K9 for nemo@megatron.ietf.org; Tue, 19 Jul 2005 02:29:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13431 for ; Tue, 19 Jul 2005 02:29:19 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dum52-0006HV-5x for nemo@ietf.org; Tue, 19 Jul 2005 02:59:54 -0400 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 76E6C4C5F9 for ; Tue, 19 Jul 2005 15:27:28 +0900 (JST) Date: Tue, 19 Jul 2005 15:28:49 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Some questions about the basic of NEMO ... Message-Id: <20050719152849.4e0f18fa.ernst@sfc.wide.ad.jp> In-Reply-To: <20050719015652.2355.qmail@web32710.mail.mud.yahoo.com> References: <42DBFD04.7030601@iprg.nokia.com> <20050719015652.2355.qmail@web32710.mail.mud.yahoo.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear Patrick, 1st, I recommend to read draft-ietf-nemo-terminology where the terms VMN and LFNs are defined. What you are talking about may be either a VMN or a LFN or a VMN. I would like to better understand your scenario: are MR1 and MR2 moving together ? - If yes, MR1 and MR2 may form the same NEMO. Say it is the cruise ship "Norway". In such a case, you may deploy a HA inside the NEMO. A MNP is advertised within the NEMO. Your MNN is a LMN, and it operates Mobile IPv6, or another mobility protoco (e.g. a MANET protocol)l. If operating Mobile IPv6, it has a HoA configured from the MNP advertised on the link where it is attached to (i.e. where the HA is located). It can move within the NEMO, and then would configure a CoA on another link inside the NEMO. - if not, then MR1 and MR2 are 2 distincts NEMOs. Your MNN is a VMN, and it is operating Mobile IPv6 to manage mobility from NEMO-MR1 to NEMO-MR2. Thierry On Mon, 18 Jul 2005 18:56:51 -0700 (PDT) Patrick Lam wrote: > Hi Vijay, > > Thanks for your reply. You are right that IPv6 > doesn't have NAT. I was thinking NAT64 when I was > typing, but I guess that won't be applicable to NEMO > scenarios ... or should it be? > > Regarding MNN getting a CoA, I am just wondering the > following scenario. > > Say, a MNN is associated with MR1 at the home network > and moved together with MR1, then I guess it won't > need a CoA in this case (because MR1 is handling all > the handoff duties), right? But then when it is > handed off to a new MR2, it will need to get a CoA. > > As a result, as long as the MNN is associated with an > appropriate MR (i.e., MR1), it will "feel" like at > home, no matter where MR1 is. On the other hand, > whenever the MNN is not associated with the right MR > (say, moved to MR2), it will "feel" like at a foreign > network even MR2 is actually inside the home network > of the MNN. > > It doesn't seem to be a correct interpretation. Where > did I misunderstand? > > Thanks again. > > Regards, > > Patrick > > --- Vijay Devarapalli wrote: > > > Patrick Lam wrote: > > > Hi, > > > > > > As I thought about NEMO more, more questions I > > have > > > ... :) > > > > > > 1. For the MNNs inside a MR, can they be NAT'ed? > > Or > > > do they have to be addressed according to the MR's > > > prefix? > > > > first of all, there is no NAT in IPv6. > > > > > 2. Under the definition of NEMO, can a MNN be > > handed > > > off from one MR to another? If so, the MNN will > > have > > > to have a globally unique IPv6 address (i.e., > > can't > > > use NAT), right? > > > > the MNN will have a globally unique IPv6 address > > from > > the mobile network prefix advertised by the mobile > > router. it is possible that the mobile network > > prefix > > is of the type described in > > draft-ietf-ipv6-unique-local-addr-09.txt. in this > > case, > > the MNN's IPv6 address will not be globally > > routable, > > only inside the home network. this is not explicity > > addressed in RFC 3963. as long the MNN stays put in > > the mobile network, it will work. > > > > > 3. If the MNNs can be handed off from one MR to > > > another, it seems like they will have to be > > addressed > > > by a CoA as well, right? > > > > yes. > > > > Vijay > > > > > > > ____________________________________________________ > Start your day with Yahoo! - make it your home page > http://www.yahoo.com/r/hs > -- Thierry Ernst, PhD WIDE, Jun Murai Lab., Keio University, Japan Nautilus6 Chair: http://www.nautilus6.org Web: http://www.sfc.wide.ad.jp/~ernst/ T:+81-44-580-1600 F:+81-44-580-1437 -- From nemo-bounces@ietf.org Tue Jul 19 06:17:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DupAP-0002p7-Eg; Tue, 19 Jul 2005 06:17:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DupAN-0002os-I9 for nemo@megatron.ietf.org; Tue, 19 Jul 2005 06:17:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27654 for ; Tue, 19 Jul 2005 06:17:33 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dupdw-00079N-8g for nemo@ietf.org; Tue, 19 Jul 2005 06:48:11 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id j6JAOamj020766; Tue, 19 Jul 2005 03:24:36 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j6JALZvu029116; Tue, 19 Jul 2005 05:21:36 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 1547A865980; Tue, 19 Jul 2005 12:17:21 +0200 (CEST) Message-ID: <42DCD330.2050108@motorola.com> Date: Tue, 19 Jul 2005 12:17:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Patrick Lam Subject: Re: [nemo] Some questions about the basic of NEMO ... References: <20050719015652.2355.qmail@web32710.mail.mud.yahoo.com> In-Reply-To: <20050719015652.2355.qmail@web32710.mail.mud.yahoo.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Patrick Lam wrote: > You are right that IPv6 doesn't have NAT. I was thinking NAT64 when > I was typing, but I guess that won't be applicable to NEMO scenarios > ... or should it be? What is NAT64? Is it about draft-durand-ngtrans-dns-issues-00.txt of 2002? As I read the abstract I deduce NAT64 is about transitioning and DNS. The NEMO base protocol does not deal at all with names, only with addresses. > Regarding MNN getting a CoA, I am just wondering the following > scenario. > > Say, a MNN is associated with MR1 at the home network and moved > together with MR1, then I guess it won't need a CoA in this case > (because MR1 is handling all the handoff duties), right? Yes. > But then when it is handed off to a new MR2, it will need to get a > CoA. > > As a result, as long as the MNN is associated with an appropriate MR > (i.e., MR1), it will "feel" like at home, no matter where MR1 is. Yes. > On the other hand, whenever the MNN is not associated with the right > MR (say, moved to MR2), it will "feel" like at a foreign network > even MR2 is actually inside the home network of the MNN. Yes. > It doesn't seem to be a correct interpretation. Where did I > misunderstand? I don't think there's any misunderstanding above, all looks right to me. Alex > > --- Vijay Devarapalli wrote: > > >> Patrick Lam wrote: >> >>> Hi, >>> >>> As I thought about NEMO more, more questions I >> >> have >> >>> ... :) >>> >>> 1. For the MNNs inside a MR, can they be NAT'ed? >> >> Or >> >>> do they have to be addressed according to the MR's prefix? >> >> first of all, there is no NAT in IPv6. >> >> >>> 2. Under the definition of NEMO, can a MNN be >> >> handed >> >>> off from one MR to another? If so, the MNN will >> >> have >> >>> to have a globally unique IPv6 address (i.e., >> >> can't >> >>> use NAT), right? >> >> the MNN will have a globally unique IPv6 address from the mobile >> network prefix advertised by the mobile router. it is possible that >> the mobile network prefix is of the type described in >> draft-ietf-ipv6-unique-local-addr-09.txt. in this case, the MNN's >> IPv6 address will not be globally routable, only inside the home >> network. this is not explicity addressed in RFC 3963. as long the >> MNN stays put in the mobile network, it will work. >> >> >>> 3. If the MNNs can be handed off from one MR to another, it >>> seems like they will have to be >> >> addressed >> >>> by a CoA as well, right? >> >> yes. >> >> Vijay >> > > > > > ____________________________________________________ Start your day > with Yahoo! - make it your home page http://www.yahoo.com/r/hs > From nemo-bounces@ietf.org Tue Jul 19 12:39:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duv7p-0008Qn-1h; Tue, 19 Jul 2005 12:39:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duv7n-0008Qa-BK for nemo@megatron.ietf.org; Tue, 19 Jul 2005 12:39:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12120 for ; Tue, 19 Jul 2005 12:39:16 -0400 (EDT) Received: from web32712.mail.mud.yahoo.com ([68.142.206.25]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DuvbL-0002g0-Go for nemo@ietf.org; Tue, 19 Jul 2005 13:09:58 -0400 Received: (qmail 80189 invoked by uid 60001); 19 Jul 2005 16:39:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=koUMyz19gLfEyefx1dLSpLGJ/znD/+RM99Ev+/UvSnEqrRGBHDyL2G8hCUtYVm6h1HTC2zCE8+JnjiC+iz4NbYRAivVChrKdVsYTGUihITdEX5tACXUMK7l6pdMwnLoVagdU4jPQBRpLdns1AyrKjy+0dTJiPvoS2jXa3HieBLs= ; Message-ID: <20050719163900.80187.qmail@web32712.mail.mud.yahoo.com> Received: from [221.127.245.57] by web32712.mail.mud.yahoo.com via HTTP; Tue, 19 Jul 2005 09:39:00 PDT Date: Tue, 19 Jul 2005 09:39:00 -0700 (PDT) From: Patrick Lam Subject: Re: [nemo] Some questions about the basic of NEMO ... To: Thierry Ernst , nemo@ietf.org In-Reply-To: <20050719152849.4e0f18fa.ernst@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Content-Transfer-Encoding: 8bit Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Thierry, Thanks for your reply. You have actually triggered me to think a little more about my question.... :) I did not even think about whether MR1 and MR2 are moving together. To make it simpler, let's assume they are not moving together, and have different MNPs (belong to different networks). I think what I meant was, based on the terms given in draft-ietf-nemo-terminology, when a LMN (denoted by MNN1) of MR1 moves to MR2 (and the MNN1 now becomes a VMN of MR2), but then MR2 moves to the home link of MNN1 (MR2 will therefore be a VMN of the home link I guess) together with all its VMNs including MNN1. Now, MNN1 is physically inside the home link. However, it is "feeling" like "visiting" because it is currently the VMN of MR2. It seems to me that, this scenario is causing some extra tunneling overhead between the home link (represented by the HA) and MNN1. But then I guess the extra tunneling is inevitable? Regards, Patrick --- Thierry Ernst wrote: > > Dear Patrick, > > 1st, I recommend to read draft-ietf-nemo-terminology > where the terms VMN > and LFNs are defined. What you are talking about may > be either a VMN or > a LFN or a VMN. > > I would like to better understand your scenario: are > MR1 and MR2 moving > together ? > > - If yes, MR1 and MR2 may form the same NEMO. Say it > is the cruise ship > "Norway". In such a case, you may deploy a HA inside > the NEMO. A MNP is > advertised within the NEMO. Your MNN is a LMN, and > it operates Mobile > IPv6, or another mobility protoco (e.g. a MANET > protocol)l. If operating > Mobile IPv6, it has a HoA configured from the MNP > advertised on the link > where it is attached to (i.e. where the HA is > located). It can move > within the NEMO, and then would configure a CoA on > another link inside > the NEMO. > > - if not, then MR1 and MR2 are 2 distincts NEMOs. > Your MNN is a VMN, and > it is operating Mobile IPv6 to manage mobility from > NEMO-MR1 to > NEMO-MR2. > > Thierry > > On Mon, 18 Jul 2005 18:56:51 -0700 (PDT) > Patrick Lam wrote: > > > Hi Vijay, > > > > Thanks for your reply. You are right that IPv6 > > doesn't have NAT. I was thinking NAT64 when I was > > typing, but I guess that won't be applicable to > NEMO > > scenarios ... or should it be? > > > > Regarding MNN getting a CoA, I am just wondering > the > > following scenario. > > > > Say, a MNN is associated with MR1 at the home > network > > and moved together with MR1, then I guess it won't > > need a CoA in this case (because MR1 is handling > all > > the handoff duties), right? But then when it is > > handed off to a new MR2, it will need to get a > CoA. > > > > As a result, as long as the MNN is associated with > an > > appropriate MR (i.e., MR1), it will "feel" like at > > home, no matter where MR1 is. On the other hand, > > whenever the MNN is not associated with the right > MR > > (say, moved to MR2), it will "feel" like at a > foreign > > network even MR2 is actually inside the home > network > > of the MNN. > > > > It doesn't seem to be a correct interpretation. > Where > > did I misunderstand? > > > > Thanks again. > > > > Regards, > > > > Patrick > > > > --- Vijay Devarapalli > wrote: > > > > > Patrick Lam wrote: > > > > Hi, > > > > > > > > As I thought about NEMO more, more questions I > > > have > > > > ... :) > > > > > > > > 1. For the MNNs inside a MR, can they be > NAT'ed? > > > Or > > > > do they have to be addressed according to the > MR's > > > > prefix? > > > > > > first of all, there is no NAT in IPv6. > > > > > > > 2. Under the definition of NEMO, can a MNN be > > > handed > > > > off from one MR to another? If so, the MNN > will > > > have > > > > to have a globally unique IPv6 address (i.e., > > > can't > > > > use NAT), right? > > > > > > the MNN will have a globally unique IPv6 address > > > from > > > the mobile network prefix advertised by the > mobile > > > router. it is possible that the mobile network > > > prefix > > > is of the type described in > > > draft-ietf-ipv6-unique-local-addr-09.txt. in > this > > > case, > > > the MNN's IPv6 address will not be globally > > > routable, > > > only inside the home network. this is not > explicity > > > addressed in RFC 3963. as long the MNN stays put > in > > > the mobile network, it will work. > > > > > > > 3. If the MNNs can be handed off from one MR > to > > > > another, it seems like they will have to be > > > addressed > > > > by a CoA as well, right? > > > > > > yes. > > > > > > Vijay > > > > > > > > > > > > > > ____________________________________________________ > > Start your day with Yahoo! - make it your home > page > > http://www.yahoo.com/r/hs > > > > > -- > Thierry Ernst, PhD > WIDE, Jun Murai Lab., Keio University, Japan > Nautilus6 Chair: http://www.nautilus6.org > Web: http://www.sfc.wide.ad.jp/~ernst/ > T:+81-44-580-1600 F:+81-44-580-1437 > -- > > ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From nemo-bounces@ietf.org Tue Jul 19 12:59:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuvQr-0007EY-0s; Tue, 19 Jul 2005 12:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuvQq-0007E3-5o for nemo@megatron.ietf.org; Tue, 19 Jul 2005 12:59:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13837 for ; Tue, 19 Jul 2005 12:58:57 -0400 (EDT) Received: from web32710.mail.mud.yahoo.com ([68.142.207.254]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DuvuU-0003Vk-JF for nemo@ietf.org; Tue, 19 Jul 2005 13:29:39 -0400 Received: (qmail 82755 invoked by uid 60001); 19 Jul 2005 16:58:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0hVH9sUW/biC+LjluK1yJHDv6Fqto7Ot7RteiHjZHbz6Ro7A/koe5mZ840sQU87CTeW70TeNwq4w9jWe8TCRuIkKSCJrD7sIlt8Py2TjbyPh8M0J2CE1n/ZD/IAVF+z3bCK6KCw50e6uiFSPazrNilfe0vAF9WXY1lSLLG6Pj4o= ; Message-ID: <20050719165849.82753.qmail@web32710.mail.mud.yahoo.com> Received: from [221.127.245.57] by web32710.mail.mud.yahoo.com via HTTP; Tue, 19 Jul 2005 09:58:49 PDT Date: Tue, 19 Jul 2005 09:58:49 -0700 (PDT) From: Patrick Lam To: nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 8bit Subject: [nemo] Does NEMO have to be based on network layer? X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, I think this may be a stupid question that has been asked many times before (although I can't find any answer on the net). It was raised from a discussion among our group of research students trying to understand more about NEMO. Does NEMO have to be based on network layer? What I mean is that -- can the functionalities of a mobile router be replaced by an AP (e.g., 802.11 AP)? Therefore, the AP is connecting to a bunch of MNNs through an ingress link, while connecting to a fixed router wirelessly through an egress link. That is, MNNs<--link layer-->AP<--link layer-->fixed router The "link layer" here can be anything from 802.11 to satallite link. Then the mobile network will mean the, say, 802.11 network surrounding the AP. I think having the IP as the "common ground" is very advantageous. However, we are just wondering whether it has to be based on IP at all. Regards, Patrick __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From nemo-bounces@ietf.org Tue Jul 19 15:51:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duy81-00033s-IP; Tue, 19 Jul 2005 15:51:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duy6U-0002Y8-1j; Tue, 19 Jul 2005 15:50:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27973; Tue, 19 Jul 2005 15:50:07 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duya4-0001ZZ-Cd; Tue, 19 Jul 2005 16:20:48 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Duy6M-0002Ld-M2; Tue, 19 Jul 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 19 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-mib-01.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : NEMO Management Information Base Author(s) : S. Gundavelli, et al. Filename : draft-ietf-nemo-mib-01.txt Pages : 40 Date : 2005-7-19 This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a mobile ipv6 node with NEMO functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-mib-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-19122728.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-19122728.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Tue Jul 19 17:33:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duzi4-0003dG-82; Tue, 19 Jul 2005 17:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duzi2-0003cu-Ll for nemo@megatron.ietf.org; Tue, 19 Jul 2005 17:33:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10765 for ; Tue, 19 Jul 2005 17:33:00 -0400 (EDT) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv0Bj-0000lR-36 for nemo@ietf.org; Tue, 19 Jul 2005 18:03:44 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 75B8E63C7; Tue, 19 Jul 2005 14:32:25 -0700 (PDT) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08747-02; Tue, 19 Jul 2005 14:32:24 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id CBE0063C1; Tue, 19 Jul 2005 14:32:24 -0700 (PDT) Received: from [192.168.4.16] (wideload-eth.tehama.multihop.net [192.168.4.16]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 7562D6133; Tue, 19 Jul 2005 14:32:24 -0700 (PDT) In-Reply-To: <20050718084642.99452.qmail@web32701.mail.mud.yahoo.com> References: <20050718084642.99452.qmail@web32701.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "T.J. Kniveton" Subject: Re: [nemo] Does a new NEMO RO solution have to be based on MIPv6? Date: Tue, 19 Jul 2005 14:32:56 -0700 To: Patrick Lam X-Mailer: Apple Mail (2.622) X-Spam-Score: -5.2 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on deimos.multihop.net X-Spam-Status: No, score=-5.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Jul 18, 2005, at 1:46 AM, Patrick Lam wrote: > Thanks for the reply. I am asking this question > because the "wording" used in quite a few drafts > (e.g., Network Mobility Support Goals and Requirements > by Ernst) kind of mandates the usage of MIPv6 > framework on NEMO. I am just not sure whether it has > already been an understanding among the comunity that > MIPv6 framework must be followed. > Hi Patrick, The reason the wording is like this, is because when we went to solve the NEMO problem, we did an analysis and comparison of possible solutions, and decided to base the solution on MIPv6. So for the Base NEMO Support protocol, it is based on MIPv6, and the accompanying drafts/RFCs would reflect that. Currently, we are looking into the RO problem space, and deciding which, if any, of that space the NEMO WG should try and solve. If the group recharters to address RO, then we would have more tasks in that area. So there is no requirement, per se, that an RO solution would be based on MIPv6. However, it is unusual to make an optimization of a protocol by changing the underlying paradigms themselves. So we would all be interested to hear more of what you have in mind. -TJ From nemo-bounces@ietf.org Tue Jul 19 17:39:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuzoN-00087u-4Z; Tue, 19 Jul 2005 17:39:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuzoL-000868-Fj for nemo@megatron.ietf.org; Tue, 19 Jul 2005 17:39:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14038 for ; Tue, 19 Jul 2005 17:39:30 -0400 (EDT) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv0I1-0001xj-IK for nemo@ietf.org; Tue, 19 Jul 2005 18:10:15 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 076DE63F6; Tue, 19 Jul 2005 14:38:56 -0700 (PDT) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08717-08; Tue, 19 Jul 2005 14:38:55 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id 6402463E9; Tue, 19 Jul 2005 14:38:55 -0700 (PDT) Received: from [192.168.4.16] (wideload-eth.tehama.multihop.net [192.168.4.16]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 006F663E8; Tue, 19 Jul 2005 14:38:54 -0700 (PDT) In-Reply-To: <20050719165849.82753.qmail@web32710.mail.mud.yahoo.com> References: <20050719165849.82753.qmail@web32710.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <944a72e656365f2c645b287614d45a5e@kniveton.com> Content-Transfer-Encoding: 7bit From: "T.J. Kniveton" Subject: Re: [nemo] Does NEMO have to be based on network layer? Date: Tue, 19 Jul 2005 14:39:27 -0700 To: Patrick Lam X-Mailer: Apple Mail (2.622) X-Spam-Score: -5.9 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on deimos.multihop.net X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Well, NEMO stands for Network Mobility. So it wouldn't make too much sense to do it at a layer lower than the Network layer. Of course, you can take an AP and stick it to an egress interface.. but as soon as the AP physically moves, and changes egress networks, its sessions will all die. This is the essence of what NEMO solves: taking a Network and making it Mobile. Here, by "mobile", we mean that its egress attachment point can traverse the fixed Internet hierarchy. On Jul 19, 2005, at 9:58 AM, Patrick Lam wrote: > Dear all, > > I think this may be a stupid question that has been > asked many times before (although I can't find any > answer on the net). It was raised from a discussion > among our group of research students trying to > understand more about NEMO. > > Does NEMO have to be based on network layer? > > What I mean is that -- can the functionalities of a > mobile router be replaced by an AP (e.g., 802.11 AP)? > Therefore, the AP is connecting to a bunch of MNNs > through an ingress link, while connecting to a fixed > router wirelessly through an egress link. That is, > > MNNs<--link layer-->AP<--link layer-->fixed router > > The "link layer" here can be anything from 802.11 to > satallite link. Then the mobile network will mean > the, say, 802.11 network surrounding the AP. > > I think having the IP as the "common ground" is very > advantageous. However, we are just wondering whether > it has to be based on IP at all. > > Regards, > > Patrick > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > From nemo-bounces@ietf.org Tue Jul 19 23:53:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv5du-0000K5-Ui; Tue, 19 Jul 2005 23:53:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv5ds-0000Il-R2 for nemo@megatron.ietf.org; Tue, 19 Jul 2005 23:53:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14216 for ; Tue, 19 Jul 2005 23:53:04 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv67Y-0000ro-MW for nemo@ietf.org; Wed, 20 Jul 2005 00:23:52 -0400 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 4606A4CA55 for ; Wed, 20 Jul 2005 12:51:11 +0900 (JST) Date: Wed, 20 Jul 2005 12:52:32 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Does NEMO have to be based on network layer? Message-Id: <20050720125232.63440dca.ernst@sfc.wide.ad.jp> In-Reply-To: <944a72e656365f2c645b287614d45a5e@kniveton.com> References: <20050719165849.82753.qmail@web32710.mail.mud.yahoo.com> <944a72e656365f2c645b287614d45a5e@kniveton.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Futher commenting on this, this solutions may be fine, but in restricted scenarios, i.e the ones when there are no L3-layer mobility, i.e. mostly at the scale of a campus. Of course, a satellite link spans a larger area, but the sole satellite link won't alsways be used, so you will need to perform a L3 handoff, right ? If you read draft-ietf-nemo-multihoming-issues, you will notive there are scenarios in which your solution at L2 wouldn't work. So, in the end, a L3 solution is needed. Thiery On Tue, 19 Jul 2005 14:39:27 -0700 "T.J. Kniveton" wrote: > Well, NEMO stands for Network Mobility. So it wouldn't make too much > sense to do it at a layer lower than the Network layer. > > Of course, you can take an AP and stick it to an egress interface.. > but as soon as the AP physically moves, and changes egress networks, > its sessions will all die. This is the essence of what NEMO solves: > taking a Network and making it Mobile. Here, by "mobile", we mean that > its egress attachment point can traverse the fixed Internet hierarchy. > > > On Jul 19, 2005, at 9:58 AM, Patrick Lam wrote: > > > Dear all, > > > > I think this may be a stupid question that has been > > asked many times before (although I can't find any > > answer on the net). It was raised from a discussion > > among our group of research students trying to > > understand more about NEMO. > > > > Does NEMO have to be based on network layer? > > > > What I mean is that -- can the functionalities of a > > mobile router be replaced by an AP (e.g., 802.11 AP)? > > Therefore, the AP is connecting to a bunch of MNNs > > through an ingress link, while connecting to a fixed > > router wirelessly through an egress link. That is, > > > > MNNs<--link layer-->AP<--link layer-->fixed router > > > > The "link layer" here can be anything from 802.11 to > > satallite link. Then the mobile network will mean > > the, say, 802.11 network surrounding the AP. > > > > I think having the IP as the "common ground" is very > > advantageous. However, we are just wondering whether > > it has to be based on IP at all. > > > > Regards, > > > > Patrick > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > > -- Thierry Ernst, PhD WIDE, Jun Murai Lab., Keio University, Japan Nautilus6 Chair: http://www.nautilus6.org Web: http://www.sfc.wide.ad.jp/~ernst/ T:+81-44-580-1600 F:+81-44-580-1437 -- From nemo-bounces@ietf.org Wed Jul 20 01:57:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv7Zy-0001fy-Oo; Wed, 20 Jul 2005 01:57:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv7Zw-0001eB-Qr for nemo@megatron.ietf.org; Wed, 20 Jul 2005 01:57:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26688 for ; Wed, 20 Jul 2005 01:57:11 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv83h-0007Je-0z for nemo@ietf.org; Wed, 20 Jul 2005 02:27:59 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id DFA034CC0B for ; Wed, 20 Jul 2005 14:55:34 +0900 (JST) Date: Wed, 20 Jul 2005 14:56:55 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Some questions about the basic of NEMO ... Message-Id: <20050720145655.77755f4f.ernst@sfc.wide.ad.jp> In-Reply-To: <20050719163900.80187.qmail@web32712.mail.mud.yahoo.com> References: <20050719152849.4e0f18fa.ernst@sfc.wide.ad.jp> <20050719163900.80187.qmail@web32712.mail.mud.yahoo.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org hi Patrick, > Thanks for your reply. You have actually triggered me > to think a little more about my question.... :) > > I did not even think about whether MR1 and MR2 are > moving together. To make it simpler, let's assume > they are not moving together, and have different MNPs > (belong to different networks). > > I think what I meant was, based on the terms given in > draft-ietf-nemo-terminology, when a LMN (denoted by > MNN1) of MR1 moves to MR2 (and the MNN1 now becomes a > VMN of MR2), but then MR2 moves to the home link of > MNN1 (MR2 will therefore be a VMN of the home link I > guess) together with all its VMNs including MNN1. Correct, from a terminology point of view. > Now, MNN1 is physically inside the home link. > However, it is "feeling" like "visiting" because it is > currently the VMN of MR2. MNN1 is topologicaly located on a different link and is therefore using a tunnel between the HA on its home link behind MR1. MNP1 and MNP2 may be from very distant part of the Internet topology. So, it's normal to consider it is vitising, so "feeling" the mobility is the right thing to do from a topological point of view. > It seems to me that, this scenario is causing some > extra tunneling overhead between the home link > (represented by the HA) and MNN1. But then I guess > the extra tunneling is inevitable? Yes, it does cause some overhead, but no, it's not inevitable. The current standards do not avoid the tunneling overhead, but this why the NEMO WG has publised the NEMO RO Problem Statement draft: http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-statement-00.txt Thierry From nemo-bounces@ietf.org Wed Jul 20 04:58:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvAPT-0007qL-GN; Wed, 20 Jul 2005 04:58:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvAPQ-0007qB-IA for nemo@megatron.ietf.org; Wed, 20 Jul 2005 04:58:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21886 for ; Wed, 20 Jul 2005 04:58:29 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvAtB-0000iD-UI for nemo@ietf.org; Wed, 20 Jul 2005 05:29:20 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 219AF4A1FB; Wed, 20 Jul 2005 10:58:15 +0200 (CEST) Received: from [163.117.139.55] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.55]) by smtp03.uc3m.es (Postfix) with ESMTP id 154724A1EA; Wed, 20 Jul 2005 10:58:14 +0200 (CEST) In-Reply-To: <20050720.084407.29959860.hmorioka@fuk> References: <20050720.084407.29959860.hmorioka@fuk> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <87319a37d282f181fdcb40adb1c3046c@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Date: Wed, 20 Jul 2005 10:58:20 +0200 To: Hitoshi MORIOKA X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: nemo WG Subject: [nemo] Re: about draft-morioka-nemo-mrcoop-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, El 20/07/2005, a las 1:44, Hitoshi MORIOKA escribi=F3: > Hi Marcelo, > > Sorry I couldn't write to you sooner. > > As I mentioned in the ML, sorry if i missed that email and if i am repeating stuff already=20 mentioned.... > I think MRs should exchange their > link metrics and update their routings frequentry because > the link quality of the MR chages dynamically. > For exapmle, the interval of updating is 1 second in OSPF. > I suppose this interval is too long for the MRs. so, what would be the problem with defining shorter intervals in ospf=20 for nemos? i mean, this seems quite much more easier than defining a=20 new protocol imho regards, marcelo > > Best regards. > > Hitoshi MORIOKA (hmorioka@root-hq.com) > > > From: marcelo bagnulo braun > Subject: about draft-morioka-nemo-mrcoop-00.txt > Date: Sun, 17 Jul 2005 18:57:05 +0200 > >> Hi Hitoshi, >> >> been reading your draft and i have a substantial question to ask: why >> can't we use a regular routing protocol to deal with this issue? >> I mean, as i understand it, the purpose of the MR cooperation = protocol >> that you are proposing is to inform the other routers about the cost=20= >> of >> the route to the rest of the internet through each of the router. But >> as i see it, this is just a particular case of the cost of a route, >> which can be expressed by the cost of the route announcement of a >> regular routing protocol (OSPF for example) >> >> So, what is the point to build a whole new protocol for doing this? >> >> Regards, marcelo >> >> >> >> > > From nemo-bounces@ietf.org Wed Jul 20 15:50:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKak-0006HW-C9; Wed, 20 Jul 2005 15:50:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKZx-0005uH-KB; Wed, 20 Jul 2005 15:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25119; Wed, 20 Jul 2005 15:50:03 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvL3o-0004JB-Nr; Wed, 20 Jul 2005 16:20:58 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DvKZu-0007i0-6a; Wed, 20 Jul 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 20 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-03.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Analysis of Multihoming in Network Mobility Support Author(s) : T. Ernst, et al. Filename : draft-ietf-nemo-multihoming-issues-03.txt Pages : 41 Date : 2005-7-20 This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Issues are classified according to the Working Group which is the best chartered to solve them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-multihoming-issues-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-20110249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-multihoming-issues-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-20110249.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Wed Jul 20 22:40:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvQyx-0000JN-Ve; Wed, 20 Jul 2005 22:40:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvQyv-0000JI-TP for nemo@megatron.ietf.org; Wed, 20 Jul 2005 22:40:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00892 for ; Wed, 20 Jul 2005 22:40:15 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvRSs-0001KX-LT for nemo@ietf.org; Wed, 20 Jul 2005 23:11:15 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j6L2e6A3004707 for ; Thu, 21 Jul 2005 11:40:06 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j6L2e7B02200 for ; Thu, 21 Jul 2005 11:40:07 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id j6L2e6o15051 for ; Thu, 21 Jul 2005 11:40:06 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml26) id j6L2e6S08461 for nemo@ietf.org; Thu, 21 Jul 2005 11:40:06 +0900 (JST) Received: from nancy by soml26.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id j6L2e6108446 for ; Thu, 21 Jul 2005 11:40:06 +0900 (JST) Message-Id: <200507210240.j6L2e6108446@soml26.jp.panasonic.com> Date: Thu, 21 Jul 2005 11:44:11 +0900 From: Masayuki Kumazawa To: nemo@ietf.org In-Reply-To: References: X-Mailer: Datula version 1.51.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [nemo] Question about draft-ietf-nemo-multihoming-issues-03.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello authors, I have a question about the multihoming analysis draft -03. >4.10 Prefix Ownership > When a (n,*,1) network splits, (i.e. the two MRs split > themselves up), MRs on distinct links may try to register the only > available MNP. I think it may also happen in (n,*,n). In the case MR1 configured with MNP1 and MR2 with MNP2 are merged into one mobile network, MR1 and MR2 may be configured with both MNP1 and MNP2. The configuration will provide benefits of multihoming. But when the mobile network splits, or MR1 and MR2 are disconnected, each MR must be re-configured only with its own prefix. Does the situation make sense? Best regards, Masayuki From Internet-Drafts@ietf.org-san >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Network Mobility Working Group of the IETF. > > Title : Analysis of Multihoming in Network Mobility Support > Author(s) : T. Ernst, et al. > Filename : draft-ietf-nemo-multihoming-issues-03.txt > Pages : 41 > Date : 2005-7-20 > >This document is an analysis of multihoming in the context of network > mobility (NEMO) in IPv6. As there are many situations in which > mobile networks may be multihomed, a taxonomy is proposed to classify > the possible configurations. The possible deployment scenarios of > multihomed mobile networks are described together with the associated > issues when network mobility is supported by RFC 3963 (NEMO Basic > Support). Issues are classified according to the Working Group which > is the best chartered to solve them. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-03.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the >message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-nemo-multihoming-issues-03.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. ----------- M.Kumazawa From nemo-bounces@ietf.org Wed Jul 20 23:46:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvS0v-0003Mr-3z; Wed, 20 Jul 2005 23:46:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvS0t-0003LS-Ox for nemo@megatron.ietf.org; Wed, 20 Jul 2005 23:46:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04055 for ; Wed, 20 Jul 2005 23:46:21 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvSUp-00055x-5K for nemo@ietf.org; Thu, 21 Jul 2005 00:17:21 -0400 Received: from [10.0.1.196] (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 421404C5F9; Thu, 21 Jul 2005 12:44:48 +0900 (JST) Message-ID: <42DF1A92.4070900@sfc.wide.ad.jp> Date: Thu, 21 Jul 2005 12:46:26 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo , Monami6 BOF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: Subject: [nemo] [Fwd: I-D ACTION:draft-kuntz-nemo-multihoming-test-02.txt] X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, We have submitted a new version of our draft about multihoming tests in NEMO environment. This new version describes more scenario than the previous one, and different implementations were used to perform the tests. Any comments are greatly appreciated. Regards, Romain -------- Original Message -------- Subject: I-D ACTION:draft-kuntz-nemo-multihoming-test-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Evaluating Multiple Mobile Routers and Multiple NEMO-Prefixes in NEMO Basic Support Author(s) : R. Kuntz, et al. Filename : draft-kuntz-nemo-multihoming-test-02.txt Pages : 26 Date : 2005-7-20 This document describes the tests performed and results obtained with multihomed mobile networks managed by NEMO Basic Support. We have particularly analyzed mobile networks with multiple mobile routers and mobile networks with multiple NEMO-Prefixes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kuntz-nemo-multihoming-test-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kuntz-nemo-multihoming-test-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kuntz-nemo-multihoming-test-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Thu Jul 21 01:33:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvTgr-00012m-BE; Thu, 21 Jul 2005 01:33:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvTgo-00011H-2I for nemo@megatron.ietf.org; Thu, 21 Jul 2005 01:33:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09636 for ; Thu, 21 Jul 2005 01:33:45 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvUAm-0002s7-EN for nemo@ietf.org; Thu, 21 Jul 2005 02:04:45 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j6L5XYIn015066 for ; Thu, 21 Jul 2005 14:33:34 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j6L5XZ329927 for ; Thu, 21 Jul 2005 14:33:35 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with SMTP id j6L5XYO14909 for ; Thu, 21 Jul 2005 14:33:34 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 13:31:13 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 8033220C1A0; Thu, 21 Jul 2005 13:37:51 +0800 (SGT) Subject: Re: [nemo] Question about draft-ietf-nemo-multihoming-issues-03.txt From: Chan-Wah Ng To: Masayuki Kumazawa In-Reply-To: <200507210240.j6L2e6108446@soml26.jp.panasonic.com> References: <200507210240.j6L2e6108446@soml26.jp.panasonic.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 21 Jul 2005 13:37:51 +0800 Message-Id: <1121924271.17286.36.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 21 Jul 2005 05:31:14.0001 (UTC) FILETIME=[68FE2410:01C58DB5] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Thu, 2005-07-21 at 11:44 +0900, Masayuki Kumazawa wrote: > Hello authors, > > I have a question about the multihoming analysis draft -03. > > >4.10 Prefix Ownership > > > When a (n,*,1) network splits, (i.e. the two MRs split > > themselves up), MRs on distinct links may try to register the only > > available MNP. > > I think it may also happen in (n,*,n). > > In the case MR1 configured with MNP1 and MR2 with MNP2 are merged > into one mobile network, MR1 and MR2 may be configured with both MNP1 > and MNP2. > The configuration will provide benefits of multihoming. > But when the mobile network splits, or MR1 and MR2 are > disconnected, each MR must be re-configured only with its own > prefix. > > Does the situation make sense? Possibly. But the question is now what possible benefits can {MR1 and MR2 both be configured with MNP1 and MNP2} brings. From the point of view of a MNN, it sees two different prefixes: MNP1 and MNP2, with two default routers. There is no significant differences for the MNN whether both the default routers announced the same prefixes. We are not talking about fault recovery here (where MR1 or MR2 fails). If a router (say MR1) fail, then a router re-numbering would almost certainly be necessary so that MNP1 can still be used. This means that HA must have a way of monitoring whether MR1 has failed, and re-delegate MNP1+MNP2 to MR2. But all these issues have nothing to do with the specific problem of "split network", they are covered elsewhere. /rgds /cwng From nemo-bounces@ietf.org Thu Jul 21 01:45:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvTsD-0006uk-VX; Thu, 21 Jul 2005 01:45:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvTs1-0006sv-SX for nemo@megatron.ietf.org; Thu, 21 Jul 2005 01:45:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10113 for ; Thu, 21 Jul 2005 01:45:21 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvUM0-0003Um-2e for nemo@ietf.org; Thu, 21 Jul 2005 02:16:21 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j6L5iwIn024015 for ; Thu, 21 Jul 2005 14:44:58 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j6L5j1B14219 for ; Thu, 21 Jul 2005 14:45:01 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id j6L5ixn00996 for ; Thu, 21 Jul 2005 14:44:59 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 13:42:39 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 321A920C1A0; Thu, 21 Jul 2005 13:49:17 +0800 (SGT) Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-03.txt From: Chan-Wah Ng To: IETF NEMO WG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 21 Jul 2005 13:49:16 +0800 Message-Id: <1121924957.17286.49.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 21 Jul 2005 05:42:39.0639 (UTC) FILETIME=[01AA3270:01C58DB7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello all, Just wish to give some updates on the draft. We enlisted Marcelo Bagnulo, who have been giving us valuable comments, as a co-author for the draft. With his help, we re-structured Section 4 quite a bit. So those who'd read previous version of the draft would definitely want to re-read Sect 4 to catch up to date. Other minor changes include: - the addition of Section 5, where we tabularize the multihoming issues presented in Sect 4 against each of the 8 configurations. - breaking the references into normative and informative - minor changes throughout the draft in an attempt to close some of the ML issues. For an update to the ML issues, please see: http://www.mobilenetworks.org/nemo/draft-ietf-nemo-multihoming-issues/ To date, we have a total of 22 ML issues, 4 open, 18 closed. /rgds /cwng On Wed, 2005-07-20 at 15:50 -0400, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Mobility Working Group of the IETF. > > Title : Analysis of Multihoming in Network Mobility Support > Author(s) : T. Ernst, et al. > Filename : draft-ietf-nemo-multihoming-issues-03.txt > Pages : 41 > Date : 2005-7-20 > > This document is an analysis of multihoming in the context of network > mobility (NEMO) in IPv6. As there are many situations in which > mobile networks may be multihomed, a taxonomy is proposed to classify > the possible configurations. The possible deployment scenarios of > multihomed mobile networks are described together with the associated > issues when network mobility is supported by RFC 3963 (NEMO Basic > Support). Issues are classified according to the Working Group which > is the best chartered to solve them. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-nemo-multihoming-issues-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > reference to remote file attachment > Content-Type: Message/External-body; access-type="mail-server"; > server="mailserv@ietf.org" > > Content-Type: text/plain > Content-ID: <2005-7-20110249.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-03.txt From nemo-bounces@ietf.org Thu Jul 21 03:40:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvVfc-0003vV-HX; Thu, 21 Jul 2005 03:40:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvVfa-0003tf-AT for nemo@megatron.ietf.org; Thu, 21 Jul 2005 03:40:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08803 for ; Thu, 21 Jul 2005 03:40:37 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvW9X-0002YG-L8 for nemo@ietf.org; Thu, 21 Jul 2005 04:11:38 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j6L7eOPF027143 for ; Thu, 21 Jul 2005 16:40:24 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j6L7ePB01282 for ; Thu, 21 Jul 2005 16:40:25 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id j6L7ePo08626 for ; Thu, 21 Jul 2005 16:40:26 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml26) id j6L7eOo13301 for nemo@ietf.org; Thu, 21 Jul 2005 16:40:24 +0900 (JST) Received: from nancy by soml26.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id j6L7eH112872; Thu, 21 Jul 2005 16:40:17 +0900 (JST) Message-Id: <200507210740.j6L7eH112872@soml26.jp.panasonic.com> Date: Thu, 21 Jul 2005 16:44:22 +0900 From: Masayuki Kumazawa Subject: Re: [nemo] Question about draft-ietf-nemo-multihoming-issues-03.txt To: In-Reply-To: <1121924271.17286.36.camel@bach.psl.com.sg> References: <200507210240.j6L2e6108446@soml26.jp.panasonic.com> <1121924271.17286.36.camel@bach.psl.com.sg> X-Mailer: Datula version 1.51.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Chan-Wah, <1121924271.17286.36.camel@bach.psl.com.sg> From Chan-Wah Ng-san >On Thu, 2005-07-21 at 11:44 +0900, Masayuki Kumazawa wrote: >> >4.10 Prefix Ownership >> >> > When a (n,*,1) network splits, (i.e. the two MRs split >> > themselves up), MRs on distinct links may try to register the only >> > available MNP. >> >> I think it may also happen in (n,*,n). >> >> In the case MR1 configured with MNP1 and MR2 with MNP2 are merged >> into one mobile network, MR1 and MR2 may be configured with both MNP1 >> and MNP2. >> The configuration will provide benefits of multihoming. > >> But when the mobile network splits, or MR1 and MR2 are >> disconnected, each MR must be re-configured only with its own >> prefix. >> >> Does the situation make sense? > >Possibly. But the question is now what possible benefits can {MR1 and >MR2 both be configured with MNP1 and MNP2} brings. From the point of >view of a MNN, it sees two different prefixes: MNP1 and MNP2, with two >default routers. There is no significant differences for the MNN >whether both the default routers announced the same prefixes. I don't think it meaningful to configure each MR with a different MNP in a mobile network with multiple fixed MRs either. However, "split network" assumes portable MRs. So "merged network" will happen as well as "split network". At first MR1 and MR2 forms different networks with different MNPs, or MNP1 and MNP2. MNN1 is currently connected to MR1 and configured with an address of MNP1. After MR1 and MR2 are merged, MNN1 can use MR2 as an alternative default router. When they split, MNN1 can't use MR2 but can keep using MR1 with the address with MNP1. 3. Usage scenarios of the following draft explains possible scenarios. http://www.ietf.org/internet-drafts/draft-kumazawa-nemo-tbdnd-02.txt >We are not talking about fault recovery here (where MR1 or MR2 fails). >If a router (say MR1) fail, then a router re-numbering would almost >certainly be necessary so that MNP1 can still be used. This means that >HA must have a way of monitoring whether MR1 has failed, and re-delegate >MNP1+MNP2 to MR2. But all these issues have nothing to do with the >specific problem of "split network", they are covered elsewhere. I'm sorry but I can't understand why you refer to fault recovery. Do you mean that multiple MNPs in a mobile network enables fault recovery? Best regards, Masayuki <1121924271.17286.36.camel@bach.psl.com.sg> From Chan-Wah Ng-san >On Thu, 2005-07-21 at 11:44 +0900, Masayuki Kumazawa wrote: >> Hello authors, >> >> I have a question about the multihoming analysis draft -03. >> >> >4.10 Prefix Ownership >> >> > When a (n,*,1) network splits, (i.e. the two MRs split >> > themselves up), MRs on distinct links may try to register the only >> > available MNP. >> >> I think it may also happen in (n,*,n). >> >> In the case MR1 configured with MNP1 and MR2 with MNP2 are merged >> into one mobile network, MR1 and MR2 may be configured with both MNP1 >> and MNP2. >> The configuration will provide benefits of multihoming. > >> But when the mobile network splits, or MR1 and MR2 are >> disconnected, each MR must be re-configured only with its own >> prefix. >> >> Does the situation make sense? > >Possibly. But the question is now what possible benefits can {MR1 and >MR2 both be configured with MNP1 and MNP2} brings. From the point of >view of a MNN, it sees two different prefixes: MNP1 and MNP2, with two >default routers. There is no significant differences for the MNN >whether both the default routers announced the same prefixes. > >We are not talking about fault recovery here (where MR1 or MR2 fails). >If a router (say MR1) fail, then a router re-numbering would almost >certainly be necessary so that MNP1 can still be used. This means that >HA must have a way of monitoring whether MR1 has failed, and re-delegate >MNP1+MNP2 to MR2. But all these issues have nothing to do with the >specific problem of "split network", they are covered elsewhere. > >/rgds >/cwng ----------- M.Kumazawa From nemo-bounces@ietf.org Thu Jul 21 04:14:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvWCJ-00006C-Cc; Thu, 21 Jul 2005 04:14:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvWCH-00005u-Ij for nemo@megatron.ietf.org; Thu, 21 Jul 2005 04:14:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10848 for ; Thu, 21 Jul 2005 04:14:24 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvWgH-0004h7-16 for nemo@ietf.org; Thu, 21 Jul 2005 04:45:25 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j6L8EEPF027791 for ; Thu, 21 Jul 2005 17:14:14 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j6L8EEB15548 for ; Thu, 21 Jul 2005 17:14:14 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with SMTP id j6L8EFs04040 for ; Thu, 21 Jul 2005 17:14:15 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 16:11:45 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id EBE2D20C1A0; Thu, 21 Jul 2005 16:18:23 +0800 (SGT) Subject: Re: [nemo] Question about draft-ietf-nemo-multihoming-issues-03.txt From: Chan-Wah Ng To: Masayuki Kumazawa In-Reply-To: <200507210740.j6L7eH112872@soml26.jp.panasonic.com> References: <200507210240.j6L2e6108446@soml26.jp.panasonic.com> <1121924271.17286.36.camel@bach.psl.com.sg> <200507210740.j6L7eH112872@soml26.jp.panasonic.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 21 Jul 2005 16:18:23 +0800 Message-Id: <1121933903.17286.85.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 21 Jul 2005 08:11:45.0645 (UTC) FILETIME=[D5E661D0:01C58DCB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Kumazawa-san, On Thu, 2005-07-21 at 16:44 +0900, Masayuki Kumazawa wrote: > Hello Chan-Wah, > > <1121924271.17286.36.camel@bach.psl.com.sg> From Chan-Wah Ng-san > >On Thu, 2005-07-21 at 11:44 +0900, Masayuki Kumazawa wrote: > > >> >4.10 Prefix Ownership > >> > >> > When a (n,*,1) network splits, (i.e. the two MRs split > >> > themselves up), MRs on distinct links may try to register the only > >> > available MNP. > >> > >> I think it may also happen in (n,*,n). > >> > >> In the case MR1 configured with MNP1 and MR2 with MNP2 are merged > >> into one mobile network, MR1 and MR2 may be configured with both MNP1 > >> and MNP2. > >> The configuration will provide benefits of multihoming. > > > >> But when the mobile network splits, or MR1 and MR2 are > >> disconnected, each MR must be re-configured only with its own > >> prefix. > >> > >> Does the situation make sense? > > > >Possibly. But the question is now what possible benefits can {MR1 and > >MR2 both be configured with MNP1 and MNP2} brings. From the point of > >view of a MNN, it sees two different prefixes: MNP1 and MNP2, with two > >default routers. There is no significant differences for the MNN > >whether both the default routers announced the same prefixes. > > I don't think it meaningful to configure each MR with a different MNP > in a mobile network with multiple fixed MRs either. > Good, we are in agreement (so far) then. > However, "split network" assumes portable MRs. > So "merged network" will happen as well as "split network". > > At first MR1 and MR2 forms different networks with different MNPs, > or MNP1 and MNP2. > MNN1 is currently connected to MR1 and configured with an address > of MNP1. > > After MR1 and MR2 are merged, MNN1 can use MR2 as an alternative > default router. > Now, this is the problem. If MR2 did not register MNP1, how can it be the default router? HA will discard the packet forwarded by MR2. So, you are proposing that they use tbdnd to allow MR2 to register for that MNP too. As far as I see, there are a few possible solutions: (a) Use tbdnd, thus allowing MR2 to tunnel src=MNP1.MNN1 (b) MR2 to simply ICMP redirect packets with src=MNP1::MNN1 back to MR1 (c) MNN1 to be Shim6-enabled: use src=MNP2:MNN1 when it want to use MR2 as the exit router, use src=MNP1:MNN1 when it want to use MR1 as exit router. > When they split, MNN1 can't use MR2 but can keep using MR1 with > the address with MNP1. Now I understand what your original mail is trying to say. Sorry, my mistake, I mis-interpreted your mail. I initially thought you were trying to say that "there is a problem when they split". But, now, I think you are trying to say "there is a problem when they merge". :) Right? > 3. Usage scenarios of the following draft explains possible > scenarios. > http://www.ietf.org/internet-drafts/draft-kumazawa-nemo-tbdnd-02.txt > > >We are not talking about fault recovery here (where MR1 or MR2 fails). > >If a router (say MR1) fail, then a router re-numbering would almost > >certainly be necessary so that MNP1 can still be used. This means that > >HA must have a way of monitoring whether MR1 has failed, and re-delegate > >MNP1+MNP2 to MR2. But all these issues have nothing to do with the > >specific problem of "split network", they are covered elsewhere. > > I'm sorry but I can't understand why you refer to fault recovery. > Do you mean that multiple MNPs in a mobile network enables fault > recovery? > Ah, nevermind. I was thinking of why would anyone want to re-configure MR1, MR2 to advertise both MNP1 and MNP2, so the only reason I could think of is fault tolerance, or for fault recovery. /rgds /cwng From nemo-bounces@ietf.org Thu Jul 21 04:23:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvWKn-0002yn-HN; Thu, 21 Jul 2005 04:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvWKl-0002yZ-JH for nemo@megatron.ietf.org; Thu, 21 Jul 2005 04:23:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11264 for ; Thu, 21 Jul 2005 04:23:10 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvWoi-0005Gj-9C for nemo@ietf.org; Thu, 21 Jul 2005 04:54:12 -0400 Received: from [10.0.1.196] (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id CA7654CC2F for ; Thu, 21 Jul 2005 17:21:09 +0900 (JST) Message-ID: <42DF5B58.3080302@sfc.wide.ad.jp> Date: Thu, 21 Jul 2005 17:22:48 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-03.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello, I have few comments about this draft on section 4.2 (Ingress Filtering). You say: > If a packet with a source address configured from a > specific MNP is tunnelled to a home agent that does not handle that > specific MNP the packet may be discarded either by the home agent or > by a border gateway in the home network. If the implementation is complying with RFC3963, IMHO it's even sure that such packet will be discarded by the HA. cf section 9 of RFC3963: The Home Agent has to verify that packets received through the bi- directional tunnel belong to the Mobile Network [...] The source address of the inner IPv6 header MUST be topologically correct with respect to the IPv6 prefixes used in the Mobile Network. > o For the (*,1,n) cases, there is not such a problem since there is > a single HA, accepting all the MNPs. The problem will not occur on HA, but what about on the MR in case you have multiple MRs ? Maybe one MR is configured to drop packets whose source addresses are built from a prefix that is not advertised by the MR. You suggest it for the (n,n,n) case few lines after: > o If the two tunnels are available, MNN cannot forward packet with > source address equals P1.MNN to MR2. This would cause ingress > filtering at HA2 to occur (or even at MR2). Regards, -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Thu Jul 21 04:59:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvWti-0001TS-JI; Thu, 21 Jul 2005 04:59:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvWth-0001TJ-QK for nemo@megatron.ietf.org; Thu, 21 Jul 2005 04:59:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13273 for ; Thu, 21 Jul 2005 04:59:16 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvXNg-0007hp-S6 for nemo@ietf.org; Thu, 21 Jul 2005 05:30:18 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j6L8x5PF010023; Thu, 21 Jul 2005 17:59:05 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j6L8x5329235; Thu, 21 Jul 2005 17:59:05 +0900 (JST) Received: from pslexc01.psl.local ([127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id j6L8x5s16941; Thu, 21 Jul 2005 17:59:05 +0900 (JST) Received: from mozart.psl.com.sg ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 16:56:45 +0800 Received: by mozart.psl.com.sg (Postfix, from userid 1000) id 3C7DC20C1A0; Thu, 21 Jul 2005 17:03:24 +0800 (SGT) Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-03.txt From: Chan-Wah Ng To: Romain KUNTZ In-Reply-To: <42DF5B58.3080302@sfc.wide.ad.jp> References: <42DF5B58.3080302@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 21 Jul 2005 17:03:23 +0800 Message-Id: <1121936604.17286.106.camel@bach.psl.com.sg> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 X-OriginalArrivalTime: 21 Jul 2005 08:56:45.0706 (UTC) FILETIME=[1F42FEA0:01C58DD2] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Romain, On Thu, 2005-07-21 at 17:22 +0900, Romain KUNTZ wrote: > Hello, > > I have few comments about this draft on section 4.2 (Ingress > Filtering). You say: > > If a packet with a source address configured from a > > specific MNP is tunnelled to a home agent that does not handle that > > specific MNP the packet may be discarded either by the home agent or > > by a border gateway in the home network. > > If the implementation is complying with RFC3963, IMHO it's even sure > that such packet will be discarded by the HA. cf section 9 of RFC3963: > > The Home Agent has to verify that packets received through the bi- > directional tunnel belong to the Mobile Network [...] The source address > of the inner IPv6 header MUST be topologically correct with respect > to the IPv6 prefixes used in the Mobile Network. Correct. The sentence "... the packet may be discarded ... ", the word "may" should be "will". > > > o For the (*,1,n) cases, there is not such a problem since there is > > a single HA, accepting all the MNPs. > > The problem will not occur on HA, but what about on the MR in case you > have multiple MRs ? Maybe one MR is configured to drop packets whose > source addresses are built from a prefix that is not advertised by the > MR. You suggest it for the (n,n,n) case few lines after: > > > o If the two tunnels are available, MNN cannot forward packet with > > source address equals P1.MNN to MR2. This would cause ingress > > filtering at HA2 to occur (or even at MR2). > True. I would propose rewriting the original bullet: o For the (*,1,n) cases, there is not such a problem since there is a single HA, accepting all the MNPs. o (*,n,n) are the cases where the ingress filtering presents some difficulties. In the (1,n,n) case the problem is simplified because all the traffic from and to the NEMO is routed through a single MR. Such configuration allows the MR to properly route packets respecting the constraints imposed by ingress filtering. The more complex case is the (n,n,n) case. A simplified case occurs when all the prefixes are accepted by all the HAs, so that no problems occur with the ingress filtering. However, this cannot be always assumed, resulting in the problem described below. to o For the (1,1,n) cases, there is not such a problem since there is a single MR and a single HA, accepting all the MNPs. o For the (n,*,n) cases, if all the MRs registers all the MNPs, there is not such a problem, since there is all the HAs are accepting all the MNPs. o The remaining cases is where ingress filtering presents some difficulties. In the (1,n,n) case the problem is simplified because all the traffic from and to the NEMO is routed through a single MR. Such configuration allows the MR to properly route packets respecting the constraints imposed by ingress filtering. The more complex case is the (n,*,n) case where not all the MRs registers all the MNPs, which results in the problem described below. What do you think? /rgds /cwng From nemo-bounces@ietf.org Thu Jul 21 06:16:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvY6C-0006RF-5m; Thu, 21 Jul 2005 06:16:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvY6A-0006RA-VF for nemo@megatron.ietf.org; Thu, 21 Jul 2005 06:16:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16929 for ; Thu, 21 Jul 2005 06:16:12 -0400 (EDT) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvYaA-00047B-Jc for nemo@ietf.org; Thu, 21 Jul 2005 06:47:16 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 694ED4A72B; Thu, 21 Jul 2005 12:16:03 +0200 (CEST) Received: from [163.117.139.55] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.55]) by smtp02.uc3m.es (Postfix) with ESMTP id BB9314A71F; Thu, 21 Jul 2005 12:16:02 +0200 (CEST) In-Reply-To: <42DF5B58.3080302@sfc.wide.ad.jp> References: <42DF5B58.3080302@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-03.txt Date: Thu, 21 Jul 2005 12:16:09 +0200 To: Romain KUNTZ X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Romain, thanks for the comments, see my reply below... El 21/07/2005, a las 10:22, Romain KUNTZ escribi=F3: > >> o For the (*,1,n) cases, there is not such a problem since there = is >> a single HA, accepting all the MNPs. > > The problem will not occur on HA, but what about on the MR in case you=20= > have multiple MRs ? Maybe one MR is configured to drop packets whose=20= > source addresses are built from a prefix that is not advertised by the=20= > MR. You suggest it for the (n,n,n) case few lines after: > Why would you wanted to do this? I mean, if there only one HA, then the HA will be accepting all the=20 MNP, so why would you configure the MR to discard some of the MNPs? Regards, marcelo >> o If the two tunnels are available, MNN cannot forward packet with >> source address equals P1.MNN to MR2. This would cause ingress >> filtering at HA2 to occur (or even at MR2). > > Regards, > > --=20 > Romain KUNTZ > kuntz@sfc.wide.ad.jp > From nemo-bounces@ietf.org Thu Jul 21 06:21:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvYAw-0007dG-1I; Thu, 21 Jul 2005 06:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvYAu-0007dB-71 for nemo@megatron.ietf.org; Thu, 21 Jul 2005 06:21:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17159 for ; Thu, 21 Jul 2005 06:21:05 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvYeu-0004Nk-5L for nemo@ietf.org; Thu, 21 Jul 2005 06:52:09 -0400 Received: from [10.0.1.196] (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 42D264CD8F for ; Thu, 21 Jul 2005 19:19:27 +0900 (JST) Message-ID: <42DF7710.8070201@sfc.wide.ad.jp> Date: Thu, 21 Jul 2005 19:21:04 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-03.txt References: <42DF5B58.3080302@sfc.wide.ad.jp> <1121936604.17286.106.camel@bach.psl.com.sg> In-Reply-To: <1121936604.17286.106.camel@bach.psl.com.sg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Chan-Wah Chan-Wah Ng wrote: > True. I would propose rewriting the original bullet: > > o For the (*,1,n) cases, there is not such a problem since there is > a single HA, accepting all the MNPs. > > o (*,n,n) are the cases where the ingress filtering presents some > difficulties. In the (1,n,n) case the problem is simplified > because all the traffic from and to the NEMO is routed through a > single MR. Such configuration allows the MR to properly route > packets respecting the constraints imposed by ingress filtering. > The more complex case is the (n,n,n) case. A simplified case > occurs when all the prefixes are accepted by all the HAs, so that > no problems occur with the ingress filtering. However, this > cannot be always assumed, resulting in the problem described > below. > > to > > o For the (1,1,n) cases, there is not such a problem since there > is a single MR and a single HA, accepting all the MNPs. Ok > o For the (n,*,n) cases, if all the MRs registers all the MNPs, > there is not such a problem, since there > is all the HAs are accepting all the MNPs. My concern here is how all HA can register all MNPs? As you say in the original text, this cannot be always assumed. We can end up with the same issues as described in 4.4 (HA Synchronization) and 4.10 (Prefix Ownership). > o The remaining cases is where ingress filtering presents some > difficulties. In the (1,n,n) case the problem is simplified > because all the traffic from and to the NEMO is routed through a > single MR. Such configuration allows the MR to properly route > packets respecting the constraints imposed by ingress filtering. > The more complex case is the (n,*,n) case where not all the MRs > registers all the MNPs, which results in the problem described > below. I would rather classify like this: o For the (1,1,n) case, there is not such a problem since there is a single MR and a single HA, accepting all the MNPs. o For the (1,n,n) cases, there is not such a problem because all the traffic from and to the NEMO is routed through a single MR. Such configuration allows the MR to properly route packets respecting the constraints imposed by ingress filtering. o (n,*,n) are the cases where the ingress filtering can occur on MRs and HAs. If all the prefixes were accepted by all the HAs, no problems would occur with the ingress filtering. However, this cannot be always assumed, resulting in the problem described below. What do you think? Romain From nemo-bounces@ietf.org Thu Jul 21 06:30:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvYK9-0003k8-QD; Thu, 21 Jul 2005 06:30:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvYK7-0003k3-Gr for nemo@megatron.ietf.org; Thu, 21 Jul 2005 06:30:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17775 for ; Thu, 21 Jul 2005 06:30:36 -0400 (EDT) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvYo7-00053y-59 for nemo@ietf.org; Thu, 21 Jul 2005 07:01:40 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 53DB74A776; Thu, 21 Jul 2005 12:30:28 +0200 (CEST) Received: from [163.117.139.55] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.55]) by smtp02.uc3m.es (Postfix) with ESMTP id 355BF4A797; Thu, 21 Jul 2005 12:30:28 +0200 (CEST) In-Reply-To: <42DF7710.8070201@sfc.wide.ad.jp> References: <42DF5B58.3080302@sfc.wide.ad.jp> <1121936604.17286.106.camel@bach.psl.com.sg> <42DF7710.8070201@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <494391e5d458f34d64ca1dca8f928f1a@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-03.txt Date: Thu, 21 Jul 2005 12:30:35 +0200 To: Romain KUNTZ X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org El 21/07/2005, a las 12:21, Romain KUNTZ escribi=F3: > Hello Chan-Wah > > Chan-Wah Ng wrote: >> True. I would propose rewriting the original bullet: o For the=20= >> (*,1,n) cases, there is not such a problem since there is >> a single HA, accepting all the MNPs. >> o (*,n,n) are the cases where the ingress filtering presents some >> difficulties. In the (1,n,n) case the problem is simplified >> because all the traffic from and to the NEMO is routed through = a >> single MR. Such configuration allows the MR to properly route >> packets respecting the constraints imposed by ingress = filtering. >> The more complex case is the (n,n,n) case. A simplified case >> occurs when all the prefixes are accepted by all the HAs, so=20 >> that >> no problems occur with the ingress filtering. However, this >> cannot be always assumed, resulting in the problem described >> below. >> to o For the (1,1,n) cases, there is not such a problem since=20 >> there is a single MR and a single HA, accepting all the MNPs. > > Ok > >> o For the (n,*,n) cases, if all the MRs registers all the MNPs, >> there is not such a problem, since there is all the HAs=20= >> are accepting all the MNPs. > > My concern here is how all HA can register all MNPs? As you say > in the original text, this cannot be always assumed. > We can end up with the same issues as described in 4.4 > (HA Synchronization) and 4.10 (Prefix Ownership). > >> o The remaining cases is where ingress filtering presents some >> difficulties. In the (1,n,n) case the problem is simplified >> because all the traffic from and to the NEMO is routed through = a >> single MR. Such configuration allows the MR to properly route >> packets respecting the constraints imposed by ingress = filtering. >> The more complex case is the (n,*,n) case where not all the MRs >> registers all the MNPs, which results in the problem described >> below. > > I would rather classify like this: > > o For the (1,1,n) case, there is not such a problem since there > is a single MR and a single HA, accepting all the MNPs. > > o For the (1,n,n) cases, there is not such a problem because all=20= > the > traffic from and to the NEMO is routed through a single MR. > Such configuration allows the MR to properly route packets > respecting the constraints imposed by ingress filtering. > > o (n,*,n) are the cases where the ingress filtering can occur on=20= > MRs > and HAs. If all the prefixes were accepted by all the HAs, no=20= > problems > would occur with the ingress filtering. However, this cannot = be > always assumed, resulting in the problem described below. > > What do you think? > As i mentioned, i fail to see why in the case where there is only one=20 HA, the MR would filter any MNP, could you explain the rationale for=20 this configuration? Regards, marcelo > Romain > From nemo-bounces@ietf.org Thu Jul 21 06:37:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvYRC-00063p-Vx; Thu, 21 Jul 2005 06:37:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvYRA-00060Y-M9 for nemo@megatron.ietf.org; Thu, 21 Jul 2005 06:37:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18293 for ; Thu, 21 Jul 2005 06:37:54 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvYvA-0005TT-S1 for nemo@ietf.org; Thu, 21 Jul 2005 07:08:58 -0400 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 2A1CD4CA80 for ; Thu, 21 Jul 2005 19:36:23 +0900 (JST) Date: Thu, 21 Jul 2005 19:37:45 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-03.txt Message-Id: <20050721193745.19ea5531.ernst@sfc.wide.ad.jp> In-Reply-To: References: <42DF5B58.3080302@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > >> o For the (*,1,n) cases, there is not such a problem since there > >is> a single HA, accepting all the MNPs. > > > > The problem will not occur on HA, but what about on the MR in case > > you have multiple MRs ? Maybe one MR is configured to drop packets > > whose source addresses are built from a prefix that is not > > advertised by the MR. You suggest it for the (n,n,n) case few lines > > after: > > > > Why would you wanted to do this? > I mean, if there only one HA, then the HA will be accepting all the > MNP, so why would you configure the MR to discard some of the MNPs? I would see things the other way round: wouldn't the MR need some sort of way to synchronize so that MNPs are not discarded ? Thierry From nemo-bounces@ietf.org Thu Jul 21 06:43:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvYWG-0008WT-8P; Thu, 21 Jul 2005 06:43:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvYWD-0008T3-IH for nemo@megatron.ietf.org; Thu, 21 Jul 2005 06:43:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18554 for ; Thu, 21 Jul 2005 06:43:07 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvZ0D-0005rL-7G for nemo@ietf.org; Thu, 21 Jul 2005 07:14:11 -0400 Received: from [10.0.1.196] (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id C2C564CD43; Thu, 21 Jul 2005 19:41:34 +0900 (JST) Message-ID: <42DF7C40.4090804@sfc.wide.ad.jp> Date: Thu, 21 Jul 2005 19:43:12 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-03.txt References: <42DF5B58.3080302@sfc.wide.ad.jp> <1121936604.17286.106.camel@bach.psl.com.sg> <42DF7710.8070201@sfc.wide.ad.jp> <494391e5d458f34d64ca1dca8f928f1a@it.uc3m.es> In-Reply-To: <494391e5d458f34d64ca1dca8f928f1a@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Marcelo, marcelo bagnulo braun wrote: > As i mentioned, i fail to see why in the case where there is only one > HA, the MR would filter any MNP, could you explain the rationale for > this configuration? For example, imagine that two (1,1,1) mobile networks (whose MR have the same HA, but advertise different prefixes) merge in one mobile network, forming a (2,1,2) NEMO. Before merging, each MR might have some filtering policies on its interface. Once merged, the policy would still apply if the MR do not synchronize. Do you think this scenario is not rational? Regards, Romain From nemo-bounces@ietf.org Thu Jul 21 07:15:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvZ19-0005Lg-Hh; Thu, 21 Jul 2005 07:15:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvZ17-0005LX-Oj for nemo@megatron.ietf.org; Thu, 21 Jul 2005 07:15:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20136 for ; Thu, 21 Jul 2005 07:15:02 -0400 (EDT) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvZV7-0007mU-Dx for nemo@ietf.org; Thu, 21 Jul 2005 07:46:06 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F0DF24A70D; Thu, 21 Jul 2005 13:14:53 +0200 (CEST) Received: from [163.117.139.55] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.55]) by smtp02.uc3m.es (Postfix) with ESMTP id D97E84A6FB; Thu, 21 Jul 2005 13:14:53 +0200 (CEST) In-Reply-To: <42DF7C40.4090804@sfc.wide.ad.jp> References: <42DF5B58.3080302@sfc.wide.ad.jp> <1121936604.17286.106.camel@bach.psl.com.sg> <42DF7710.8070201@sfc.wide.ad.jp> <494391e5d458f34d64ca1dca8f928f1a@it.uc3m.es> <42DF7C40.4090804@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <2e2e11822e430471c1c2ec29f57b42fd@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-03.txt Date: Thu, 21 Jul 2005 13:15:00 +0200 To: Romain KUNTZ X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org El 21/07/2005, a las 12:43, Romain KUNTZ escribi=F3: > Hello Marcelo, > > marcelo bagnulo braun wrote: >> As i mentioned, i fail to see why in the case where there is only one=20= >> HA, the MR would filter any MNP, could you explain the rationale for=20= >> this configuration? > > For example, imagine that two (1,1,1) mobile networks (whose MR have=20= > the same HA, but advertise different prefixes) merge in one mobile=20 > network, forming a (2,1,2) NEMO. Before merging, each MR might have=20 > some filtering policies on its interface. Once merged, the policy=20 > would still apply if the MR do not synchronize. > Do you think this scenario is not rational? > yep, good enough for me my question now is if we are considering the merging scenario like this=20= in the analysis... I mean, i guess that there is quite a difference in terms of complexity=20= if we are cosnidering some form of static nemos than when considering=20 this form of dynamic nemos that merge and split... regards, marcelo > Regards, > > Romain > From nemo-bounces@ietf.org Thu Jul 21 07:18:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvZ3w-0005yo-1B; Thu, 21 Jul 2005 07:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvZ3u-0005yj-BF for nemo@megatron.ietf.org; Thu, 21 Jul 2005 07:17:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20316 for ; Thu, 21 Jul 2005 07:17:55 -0400 (EDT) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvZXu-0007ya-L4 for nemo@ietf.org; Thu, 21 Jul 2005 07:49:00 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id EB2164A782; Thu, 21 Jul 2005 13:17:46 +0200 (CEST) Received: from [163.117.139.55] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.55]) by smtp02.uc3m.es (Postfix) with ESMTP id D96604A79D; Thu, 21 Jul 2005 13:17:45 +0200 (CEST) In-Reply-To: <20050721193745.19ea5531.ernst@sfc.wide.ad.jp> References: <42DF5B58.3080302@sfc.wide.ad.jp> <20050721193745.19ea5531.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <54b65afb66af2c3abaaa147f443b4b79@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-03.txt Date: Thu, 21 Jul 2005 13:17:53 +0200 To: Thierry Ernst X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org El 21/07/2005, a las 12:37, Thierry Ernst escribi=F3: > >>>> o For the (*,1,n) cases, there is not such a problem since there >>> is> a single HA, accepting all the MNPs. >>> >>> The problem will not occur on HA, but what about on the MR in case >>> you have multiple MRs ? Maybe one MR is configured to drop packets >>> whose source addresses are built from a prefix that is not >>> advertised by the MR. You suggest it for the (n,n,n) case few lines >>> after: >>> >> >> Why would you wanted to do this? >> I mean, if there only one HA, then the HA will be accepting all the >> MNP, so why would you configure the MR to discard some of the MNPs? > > I would see things the other way round: wouldn't the MR need some sort > of way to synchronize so that MNPs are not discarded ? > well, i guess it depends on the scenario being considered. I mean, if=20 you are considering some static scenario, like a nemo in a train or=20 plane, then, i guess that MNP are manually configured or through dhcp=20 and the situation is pretty stable, so i would say that we don't need=20 that. OTOH, if we are dealing with the scenario the Romain mentions of=20 merging and spliting with a relatively high frequency, then we may need=20= this. But i guess that in this environment we may need a more in depth=20= analysis in order to see if there are additional stuff needed, since=20 the constraints may greatly differ regards, marcelo > Thierry > From nemo-bounces@ietf.org Thu Jul 21 07:25:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvZB4-0000ym-2H; Thu, 21 Jul 2005 07:25:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvZB2-0000yd-6k for nemo@megatron.ietf.org; Thu, 21 Jul 2005 07:25:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20833 for ; Thu, 21 Jul 2005 07:25:19 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvZf1-0008Va-Pt for nemo@ietf.org; Thu, 21 Jul 2005 07:56:22 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 69ED94C5F9 for ; Thu, 21 Jul 2005 20:23:25 +0900 (JST) Date: Thu, 21 Jul 2005 20:24:48 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-03.txt Message-Id: <20050721202448.34760846.ernst@sfc.wide.ad.jp> In-Reply-To: <54b65afb66af2c3abaaa147f443b4b79@it.uc3m.es> References: <42DF5B58.3080302@sfc.wide.ad.jp> <20050721193745.19ea5531.ernst@sfc.wide.ad.jp> <54b65afb66af2c3abaaa147f443b4b79@it.uc3m.es> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > >> Why would you wanted to do this? > >> I mean, if there only one HA, then the HA will be accepting all the > >> MNP, so why would you configure the MR to discard some of the MNPs? > > > > I would see things the other way round: wouldn't the MR need some > > sort of way to synchronize so that MNPs are not discarded ? > > > > well, i guess it depends on the scenario being considered. I mean, if > you are considering some static scenario, like a nemo in a train or > plane, then, i guess that MNP are manually configured or through dhcp > and the situation is pretty stable, so i would say that we don't need > that. > > OTOH, if we are dealing with the scenario the Romain mentions of > merging and spliting with a relatively high frequency, then we may > need this. But i guess that in this environment we may need a more in > depth analysis in order to see if there are additional stuff needed, > since the constraints may greatly differ Actually, the NEMO WG is still supposed to decide which of the scenarios are reasonable to support vs optional. Deciding on this would drive the issues on which we need to work on. So far, the analysis document is just here to list the issues, not to solve them. Thierry From nemo-bounces@ietf.org Thu Jul 21 11:18:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvcp8-0001wK-66; Thu, 21 Jul 2005 11:18:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvcp6-0001wE-Ee for nemo@megatron.ietf.org; Thu, 21 Jul 2005 11:18:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09082 for ; Thu, 21 Jul 2005 11:18:53 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvdJ7-0006rt-Pl for nemo@ietf.org; Thu, 21 Jul 2005 11:50:00 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j6LFS9aj019306; Thu, 21 Jul 2005 08:28:09 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j6LFNfd8029600; Thu, 21 Jul 2005 10:23:42 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 0E659865980; Thu, 21 Jul 2005 17:18:45 +0200 (CEST) Message-ID: <42DFBCD4.9050408@motorola.com> Date: Thu, 21 Jul 2005 17:18:44 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Patrick Lam Subject: Re: [nemo] Does NEMO have to be based on network layer? References: <20050719165849.82753.qmail@web32710.mail.mud.yahoo.com> In-Reply-To: <20050719165849.82753.qmail@web32710.mail.mud.yahoo.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Patrick Lam wrote: > Dear all, > > I think this may be a stupid question that has been > asked many times before (although I can't find any > answer on the net). It was raised from a discussion > among our group of research students trying to > understand more about NEMO. > > Does NEMO have to be based on network layer? > > What I mean is that -- can the functionalities of a > mobile router be replaced by an AP (e.g., 802.11 AP)? > Therefore, the AP is connecting to a bunch of MNNs > through an ingress link, while connecting to a fixed > router wirelessly through an egress link. That is, > > MNNs<--link layer-->AP<--link layer-->fixed router Along the lines of the above topology is a Mobile Router that is actually a bridge, and I think there is some discussion about Home Network models considering that, search "bridge" in http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-models-03.txt Alex From nemo-bounces@ietf.org Thu Jul 21 15:51:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvh55-00025r-BI; Thu, 21 Jul 2005 15:51:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvh3c-0001PL-U1; Thu, 21 Jul 2005 15:50:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03768; Thu, 21 Jul 2005 15:50:10 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvhXa-0000V6-Cy; Thu, 21 Jul 2005 16:21:12 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dvh3T-0003a0-4p; Thu, 21 Jul 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 21 Jul 2005 15:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-03.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Analysis of Multihoming in Network Mobility Support Author(s) : C. Ng, et al. Filename : draft-ietf-nemo-multihoming-issues-03.txt Pages : 41 Date : 2005-7-20 This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Issues are classified according to the Working Group which is the best chartered to solve them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-multihoming-issues-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-21134552.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-multihoming-issues-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-21134552.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Mon Jul 25 01:24:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwvRf-0005ld-Uj; Mon, 25 Jul 2005 01:24:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwvRe-0005lY-PL for nemo@megatron.ietf.org; Mon, 25 Jul 2005 01:24:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25315 for ; Mon, 25 Jul 2005 01:24:06 -0400 (EDT) Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwvwQ-0002nr-V9 for nemo@ietf.org; Mon, 25 Jul 2005 01:55:56 -0400 Received: from mmlabsmbaek ([147.46.216.64]) by mmlab.snu.ac.kr (8.12.10/8.12.10) with ESMTP id j6P5O3e0033070 for ; Mon, 25 Jul 2005 14:24:03 +0900 (KST) (envelope-from smbaek@mmlab.snu.ac.kr) Message-Id: <200507250524.j6P5O3e0033070@mmlab.snu.ac.kr> From: "sungmin baek" To: Date: Mon, 25 Jul 2005 14:24:07 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C59124.875EBBF0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWQ2RRKrr4iZt4ARYiUJ0JSyGKpEQ== X-Spam-Score: 0.3 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Subject: [nemo] New Internet Draft - AAA for NEMO X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C59124.875EBBF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, My name is Sungmin Baek, a master student at Seoul National University. I co-worked a new Internet draft with professor Kwon and other people. It is about Authentication, Authorization, and Accounting Protocol for NEMO. The mobility transparency is the key advantage of the NEMO basic support protocol. Also, from the point of view of ISPs, how to charge a VMN for its network usage is a critical issue. Proposed AAA protocol allows to authenticate VMNs and to account its network usage while keeping the mobility transparency. http://www.ietf.org/internet-drafts/draft-kwon-aaa-nemo-00.txt Any questions and comments welcome. Here is the abstract The purpose of this paper is to describe an AAA protocol designed for NEMO services. The proposed AAA protocol retains the NEMO mobility transparency in the NEMO basic support protocol, while providing all the required AAA functionalities for mobile network nodes. In addition, the proposed AAA protocol reduces authentication latency by localizing AAA process. Thanks, Baek. ------=_NextPart_000_001C_01C59124.875EBBF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = all,

 

My name is Sungmin Baek, a = master student at Seoul National University.

I co-worked a new Internet = draft with professor Kwon and other people.

It is about Authentication, Authorization, and Accounting Protocol for = NEMO.

 

The mobility transparency = is the key advantage of the NEMO basic support = protocol.

Also, from the point of = view of ISPs, how to charge a VMN for its network usage is a critical = issue.

Proposed AAA protocol = allows to authenticate VMNs and to account its network usage while keeping the = mobility transparency.

 

http://www.ietf.org/internet= -drafts/draft-kwon-aaa-nemo-00.txt

 

Any questions and comments = welcome.

 

Here is the = abstract

The purpose of = this paper is to describe an AAA protocol designed for

   NEMO = services.  The proposed AAA protocol retains the NEMO = mobility

   transparency = in the NEMO basic support protocol, while providing = all

   the required = AAA functionalities for mobile network nodes.  = In

   addition, the = proposed AAA protocol reduces authentication latency = by

   localizing AAA = process.

 

Thanks,

Baek.

------=_NextPart_000_001C_01C59124.875EBBF0-- From nemo-bounces@ietf.org Mon Jul 25 06:58:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx0fA-0000Je-Pp; Mon, 25 Jul 2005 06:58:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx0f9-0000JZ-AS for nemo@megatron.ietf.org; Mon, 25 Jul 2005 06:58:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06032 for ; Mon, 25 Jul 2005 06:58:21 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx19s-0004tq-Qg for nemo@ietf.org; Mon, 25 Jul 2005 07:30:15 -0400 Received: from [10.0.1.196] (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 16F294CE58 for ; Mon, 25 Jul 2005 19:57:54 +0900 (JST) Message-ID: <42E4C5C5.3000501@sfc.wide.ad.jp> Date: Mon, 25 Jul 2005 19:58:13 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Subject: [nemo] Questions about draft-kniveton-nemo-prefix-delegation-01 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello, I have read draft-kniveton-nemo-prefix-delegation-01 and have some questions about it. - In section 5.2, it is said: When setting the Prefix Status bit, the HA also lists all the prefixes associated to that Mobile Router using Mobile Network Prefix Confirmation options. But in section 8, it is said: If the Binding Update contains an S bit, the Home Agent includes a Mobile Network Prefix Option for each prefix the Home Agent believes is assigned to the Mobile Route So which one of the MNP Option or the MNP Confirmation Option should be used to list all the MNPs ? - Also, I don't understand well the utility of the I flag in the Mobile Network Prefix Option: Implicit (I): The (I) bit is set if the prefix is assigned to and routed via the MR even if the prefix is not listed in explicit mode BU. No MNP options are used when the MR uses Implicit mode. So this bit is never used. Or does the HA has to use the MNP option and set this bit when listing all the prefixes owned by the MR ? - Once the prefix delegation is finished, does the MR and HA have to set the bit relative to prefix delegation in the MNP Option? Or should they just operate NEMO BS (unless they send/receive MNP request or confirmation option)? Regards, -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Mon Jul 25 21:54:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxEei-0001jh-FQ; Mon, 25 Jul 2005 21:54:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxEeg-0001jc-T1 for nemo@megatron.ietf.org; Mon, 25 Jul 2005 21:54:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13734 for ; Mon, 25 Jul 2005 21:54:49 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxF9d-0000eE-6T for nemo@ietf.org; Mon, 25 Jul 2005 22:26:50 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j6Q1sZJV020110; Tue, 26 Jul 2005 10:54:35 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j6Q1sb514616; Tue, 26 Jul 2005 10:54:37 +0900 (JST) Received: from epochmail.jp.panasonic.com ([127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id j6Q1sbs00762; Tue, 26 Jul 2005 10:54:37 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.11.6p2/3.7W/soml22) id j6Q1sar27670; Tue, 26 Jul 2005 10:54:36 +0900 (JST) Received: from nancy by soml22.jp.panasonic.com (8.11.6p2/3.7W) with ESMTP id j6Q1sZ927616; Tue, 26 Jul 2005 10:54:35 +0900 (JST) Message-Id: <200507260154.j6Q1sZ927616@soml22.jp.panasonic.com> Date: Tue, 26 Jul 2005 10:58:52 +0900 From: Masayuki Kumazawa To: , tj@kniveton.com, X-Mailer: Datula version 1.51.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: nemo@ietf.org Subject: [nemo] Prefix Delegation and Duplicated Network Detection X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear TJ, Pascal, Ralph, and all, I'm now proposing Duplicate Network Detection (DND). http://www.ietf.org/internet-drafts/draft-kumazawa-nemo-tbdnd-02.txt DND trys to address the issue listed in the multihoming draft (Section 4.10). The issue is 'Prefix Ownership'. As the name indicates, the issue is related to the Prefix Delegation (PD). Our motivation for proposing DNS is very similar to that of PD. So, I hope we will also discuss DND as one of the issues related to PD. I'd like to describe the followings. 1) The motivation of DND. 2) The benefits enabled by including DND in the PD. As for 1), DND's purpose is to re-delegate MNPs from one MR to another MR. In the case MRs are portable such as Wireless PAN devices, synchronization of MNP among MRs within a Mobile Network should be done dynamically. Otherwise, the users who are owners of the MRs need to configure them without mistakes. If the users make a mistake, for instance, MRs on different links are configured with the same prefixes, some packets won't reach correct recipients. As for 2): Multiple MRs configured with the same prefix in a Mobile Network will provide benefits like load balance or redundancy even if we don't assume a wireless PAN. If we include DND in PD, MRs can share the same prefix when they are in the same mobile network dynamically without requiring configuration by the adminstrators. Otherwise, administrators will need to confirm whether MRs configured with the same prefix are in the same network before operation. As explained above, I think DND is related to PD. Please let me know your thoughts on discussing DND as an issue under PD. Best regards, Masayuki ----------- M.Kumazawa From nemo-bounces@ietf.org Tue Jul 26 05:01:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxLJy-0002Io-Ae; Tue, 26 Jul 2005 05:01:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxLJw-0002Ij-Th for nemo@megatron.ietf.org; Tue, 26 Jul 2005 05:01:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29684 for ; Tue, 26 Jul 2005 05:01:50 -0400 (EDT) Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxLow-0003qE-TX for nemo@ietf.org; Tue, 26 Jul 2005 05:33:56 -0400 Received: from [147.46.216.57] ([147.46.216.57]) by mmlab.snu.ac.kr (8.12.10/8.12.10) with ESMTP id j6Q91he0063272; Tue, 26 Jul 2005 18:01:43 +0900 (KST) (envelope-from jhryu@mmlab.snu.ac.kr) Message-ID: <42E5FBF2.3040708@mmlab.snu.ac.kr> Date: Tue, 26 Jul 2005 18:01:38 +0900 From: Jiho Ryu User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ko-kr, ko, en-us, en MIME-Version: 1.0 To: Romain KUNTZ Subject: Re: [nemo] New draft: Failover for multiple mobile routers References: <42D21AC7.9040708@mmlab.snu.ac.kr> <42D6029A.1040901@sfc.wide.ad.jp> In-Reply-To: <42D6029A.1040901@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, I forget to answer one thing in my previous mail. :-) Romain KUNTZ wrote: >Hi, > >I have several questions and comments about your draft >draft-ryu-nemo-mr-failover-00. > >First, it could be a good idea to follow the spirit of >draft-ietf-nemo-multihoming-issues to describe on which topology you are >working on, and which issue you try to solve. > > > Our draft is focussing on the scenario (n,*,n) . We are assuming that a mobile router can hear RA messages from other mobile routers in the same NEMO. Here is an example. +-----+ +-----+ | HA1 | | HA2 | +--+--+ +--+--+ | | | | +---+----------+----+ MR1 +-----+ | Internet |------| MR1 | +---+----------+----+ CoA1+--+--+ | |MNP1 MR2|CoA2 | +-----+ | | MR2 | | +--+--+ | |MNP2 | | | +--+-------------+--+ | NEMO | +-------------------+ Figure 1. Multi-homed NEMO We try to solve the failure and recovery issues of multiple mobile router in NEMO. For more information, please refer the appendices section of our draft. http://www.ietf.org/internet-drafts/draft-ryu-nemo-mr-failover-00.txt Regards, Jiho. -- Ryu, Jiho Master Course Multimedia and Mobile Communications Lab., School of Computer Science and Engineering Seoul National University From nemo-bounces@ietf.org Tue Jul 26 05:16:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxLY9-0006Hb-Kk; Tue, 26 Jul 2005 05:16:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxLY8-0006HW-MX for nemo@megatron.ietf.org; Tue, 26 Jul 2005 05:16:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00685 for ; Tue, 26 Jul 2005 05:16:30 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxM39-0004H7-By for nemo@ietf.org; Tue, 26 Jul 2005 05:48:36 -0400 Received: from iseran.local (p2145-ipad41hodogaya.kanagawa.ocn.ne.jp [221.189.142.145]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 276EA4C615 for ; Tue, 26 Jul 2005 18:16:14 +0900 (JST) Date: Tue, 26 Jul 2005 18:16:12 +0900 From: Thierry Ernst To: ml-nemo Message-Id: <20050726181612.67fb5547.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: [nemo] Draft NEMO Agenda X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, The draft NEMO WG agenda (as of 25th) is posted on the usual NEMO additional web page: http://www.mobilenetworks.org/nemo/ietf63/nemo-ietf63-agenda.txt We have received some requests that we have decided not to list on the current draft agenda because we either think that not enough discussion has been generated, or that the relation with the current NEMO activities has not been established. For those people falling in the former case, we may still consider the requests based on actual discussion and interest on the mailing list from now until the meeting, to the condition that there is adequate time left during our session (which seems to be the case as of today). Let me remind everyone that IETF meetings are not for "presenting drafts", but to discuss the issues related to these drafts and to make some decisions like e.g. adopting a draft as a WG document, etc. On a general basis, prior discussion is assumed on the ML. Exceptions to this are topics that fall very well into the priorities of the WG. Thierry. From nemo-bounces@ietf.org Tue Jul 26 05:58:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxMCw-0006VQ-GG; Tue, 26 Jul 2005 05:58:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxMCv-0006VL-AB for nemo@megatron.ietf.org; Tue, 26 Jul 2005 05:58:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02784 for ; Tue, 26 Jul 2005 05:58:36 -0400 (EDT) Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxMhu-0005WG-Ag for nemo@ietf.org; Tue, 26 Jul 2005 06:30:43 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A49DF4A27C; Tue, 26 Jul 2005 11:58:21 +0200 (CEST) Received: from [163.117.139.55] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.55]) by smtp03.uc3m.es (Postfix) with ESMTP id F12044A284; Tue, 26 Jul 2005 11:58:18 +0200 (CEST) In-Reply-To: <20050726181612.67fb5547.ernst@sfc.wide.ad.jp> References: <20050726181612.67fb5547.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <007dcdb52b2da22bb18e7e1d21100fa3@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Draft NEMO Agenda Date: Tue, 26 Jul 2005 11:58:32 +0200 To: Thierry Ernst X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: ml-nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Thierry, thanks for the agenda, just one question: w.r.t. 5v Status of the forthcoming analysis draft .........................=20 15mins Masufumi Watari "Network Mobility Route Optimization Solution Space Analysis" (draft-ietf-nemo-ro-space-analysis-00.txt not published yet) do you think we will have the chance to have=20 draft-ietf-nemo-ro-space-analysis-00.txt available before the meeting? regards, marcelo El 26/07/2005, a las 11:16, Thierry Ernst escribi=F3: > > Dear all, > > The draft NEMO WG agenda (as of 25th) is posted on the usual NEMO > additional web page: > http://www.mobilenetworks.org/nemo/ietf63/nemo-ietf63-agenda.txt > > We have received some requests that we have decided not to list on the > current draft agenda because we either think that not enough = discussion > has been generated, or that the relation with the current NEMO > activities has not been established. For those people falling in the > former case, we may still consider the requests based on actual > discussion and interest on the mailing list from now until the = meeting, > to the condition that there is adequate time left during our session > (which seems to be the case as of today). > > Let me remind everyone that IETF meetings are not for "presenting > drafts", but to discuss the issues related to these drafts and to make > some decisions like e.g. adopting a draft as a WG document, etc. On a > general basis, prior discussion is assumed on the ML. Exceptions to=20 > this > are topics that fall very well into the priorities of the WG. > > Thierry. > > From nemo-bounces@ietf.org Tue Jul 26 06:13:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxMRK-0001SS-FN; Tue, 26 Jul 2005 06:13:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxMRI-0001SN-OC for nemo@megatron.ietf.org; Tue, 26 Jul 2005 06:13:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03452 for ; Tue, 26 Jul 2005 06:13:30 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxMwJ-0005xD-SA for nemo@ietf.org; Tue, 26 Jul 2005 06:45:37 -0400 Received: from iseran.local (p2145-ipad41hodogaya.kanagawa.ocn.ne.jp [221.189.142.145]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 529374CA55 for ; Tue, 26 Jul 2005 19:13:05 +0900 (JST) Date: Tue, 26 Jul 2005 19:13:04 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Draft NEMO Agenda Message-Id: <20050726191304.6d520181.ernst@sfc.wide.ad.jp> In-Reply-To: <007dcdb52b2da22bb18e7e1d21100fa3@it.uc3m.es> References: <20050726181612.67fb5547.ernst@sfc.wide.ad.jp> <007dcdb52b2da22bb18e7e1d21100fa3@it.uc3m.es> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > thanks for the agenda, just one question: > > w.r.t. > > 5v Status of the forthcoming analysis draft ......................... > 15mins > Masufumi Watari > > "Network Mobility Route Optimization Solution Space Analysis" > (draft-ietf-nemo-ro-space-analysis-00.txt not published yet) > > do you think we will have the chance to have > draft-ietf-nemo-ro-space-analysis-00.txt available before the meeting? No. The team will report the current status, that's all. The draft should be published sometimes after mid-august if everything is going alright. Thierry From nemo-bounces@ietf.org Tue Jul 26 13:57:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTgZ-000666-KE; Tue, 26 Jul 2005 13:57:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTgY-000661-Gv for nemo@megatron.ietf.org; Tue, 26 Jul 2005 13:57:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10472 for ; Tue, 26 Jul 2005 13:57:45 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxUBd-00050J-KM for nemo@ietf.org; Tue, 26 Jul 2005 14:29:55 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6QHQNZ24988; Tue, 26 Jul 2005 10:26:23 -0700 X-mProtect: <200507261726> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14177.americas.nokia.com (172.18.141.77, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdaqt5qc; Tue, 26 Jul 2005 10:26:22 PDT Message-ID: <42E6797E.7090200@iprg.nokia.com> Date: Tue, 26 Jul 2005 10:57:18 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Draft NEMO Agenda References: <20050726181612.67fb5547.ernst@sfc.wide.ad.jp> In-Reply-To: <20050726181612.67fb5547.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: ml-nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org hi Thierry, can we have a small slot to discuss on how to proceed with Global HAHA? The draft is at http://www.mobilenetworks.org/nemo/drafts/draft-thubert-nemo-global-haha-00.txt I still think this belongs in NEMO rather than in MONAMI6. Vijay Thierry Ernst wrote: > Dear all, > > The draft NEMO WG agenda (as of 25th) is posted on the usual NEMO > additional web page: > http://www.mobilenetworks.org/nemo/ietf63/nemo-ietf63-agenda.txt > > We have received some requests that we have decided not to list on the > current draft agenda because we either think that not enough discussion > has been generated, or that the relation with the current NEMO > activities has not been established. For those people falling in the > former case, we may still consider the requests based on actual > discussion and interest on the mailing list from now until the meeting, > to the condition that there is adequate time left during our session > (which seems to be the case as of today). > > Let me remind everyone that IETF meetings are not for "presenting > drafts", but to discuss the issues related to these drafts and to make > some decisions like e.g. adopting a draft as a WG document, etc. On a > general basis, prior discussion is assumed on the ML. Exceptions to this > are topics that fall very well into the priorities of the WG. > > Thierry. > > From nemo-bounces@ietf.org Tue Jul 26 20:14:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxZZX-0002ar-TC; Tue, 26 Jul 2005 20:14:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxZZW-0002af-8c for nemo@megatron.ietf.org; Tue, 26 Jul 2005 20:14:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06278 for ; Tue, 26 Jul 2005 20:14:52 -0400 (EDT) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxa4f-0007B3-Fd for nemo@ietf.org; Tue, 26 Jul 2005 20:47:05 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 9E5AE60F3; Tue, 26 Jul 2005 17:14:34 -0700 (PDT) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11533-10; Tue, 26 Jul 2005 17:14:27 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id 07A1F619A; Tue, 26 Jul 2005 17:14:27 -0700 (PDT) Received: from [192.168.5.2] (apexpress.tehama.multihop.net [192.168.4.21]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 9D29D60F3; Tue, 26 Jul 2005 17:14:26 -0700 (PDT) In-Reply-To: <42E4C5C5.3000501@sfc.wide.ad.jp> References: <42E4C5C5.3000501@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9d173ec44e3a58dc22c1563a6803b155@kniveton.com> Content-Transfer-Encoding: 7bit From: "T.J. Kniveton" Subject: Re: [nemo] Questions about draft-kniveton-nemo-prefix-delegation-01 Date: Tue, 26 Jul 2005 17:14:28 -0700 To: Romain KUNTZ X-Mailer: Apple Mail (2.622) X-Spam-Score: -5.2 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on deimos.multihop.net X-Spam-Status: No, score=-5.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Jul 25, 2005, at 3:58 AM, Romain KUNTZ wrote: > Hello, > > I have read draft-kniveton-nemo-prefix-delegation-01 and have some > questions about it. Should I take it that you're implementing the draft? :-D > - In section 5.2, it is said: > When setting the Prefix Status bit, the HA also > lists all the prefixes associated to that Mobile Router using Mobile > Network Prefix Confirmation options. > > But in section 8, it is said: > If the Binding Update contains an S bit, the Home Agent includes a > Mobile Network Prefix Option for each prefix the Home Agent believes > is assigned to the Mobile Route > > So which one of the MNP Option or the MNP Confirmation Option should be > used to list all the MNPs ? This is something we need to think about further -- I believe that they should be MNPOs, and MNPCOs are reserved for a request-response of a delegation event. But I would also like to hear others' opinions on this. > - Also, I don't understand well the utility of the I flag in the Mobile > Network Prefix Option: > Implicit (I): The (I) bit is set if the prefix is assigned to and > routed via the MR even if the prefix is not listed in explicit > mode BU. > > No MNP options are used when the MR uses Implicit mode. So this bit is > never used. Or does the HA has to use the MNP option and set this bit > when listing all the prefixes owned by the MR ? That's correct. The idea is to be able to explicitly list *all* prefixes assigned, including ones that are bound using implicit BUs. > - Once the prefix delegation is finished, does the MR and HA have to > set the > bit relative to prefix delegation in the MNP Option? Or should they > just operate NEMO BS (unless they send/receive MNP request or > confirmation option)? Should be orthagonal, so that you can just use regular NEMO BS. TJ From nemo-bounces@ietf.org Tue Jul 26 20:30:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxZoO-0006Mr-RF; Tue, 26 Jul 2005 20:30:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxZoN-0006Mc-Gm for nemo@megatron.ietf.org; Tue, 26 Jul 2005 20:30:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07220 for ; Tue, 26 Jul 2005 20:30:14 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxaJW-0007d7-Ue for nemo@ietf.org; Tue, 26 Jul 2005 21:02:27 -0400 Received: from [192.168.0.5] (p626761.ykhmac00.ap.so-net.ne.jp [219.98.103.97]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id A59814C0AB; Wed, 27 Jul 2005 09:29:49 +0900 (JST) Message-ID: <42E6D592.90600@sfc.wide.ad.jp> Date: Wed, 27 Jul 2005 09:30:10 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J. Kniveton" Subject: Re: [nemo] Questions about draft-kniveton-nemo-prefix-delegation-01 References: <42E4C5C5.3000501@sfc.wide.ad.jp> <9d173ec44e3a58dc22c1563a6803b155@kniveton.com> In-Reply-To: <9d173ec44e3a58dc22c1563a6803b155@kniveton.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello, Thank you for your reply. More comments below: T.J. Kniveton wrote: > Should I take it that you're implementing the draft? :-D Let's say I am interested in :) >> - In section 5.2, it is said: >> When setting the Prefix Status bit, the HA also >> lists all the prefixes associated to that Mobile Router using Mobile >> Network Prefix Confirmation options. >> >> But in section 8, it is said: >> If the Binding Update contains an S bit, the Home Agent includes a >> Mobile Network Prefix Option for each prefix the Home Agent believes >> is assigned to the Mobile Route >> >> So which one of the MNP Option or the MNP Confirmation Option should be >> used to list all the MNPs ? > > > This is something we need to think about further -- I believe that they > should be MNPOs, and MNPCOs are reserved for a request-response of a > delegation event. But I would also like to hear others' opinions on this. The problem is that if you use MNPOs, then in the case where the MR sends a registration BU with MNP Request Options + the S bit set, then the HA will have to reply with MNPCO and MNPO for the same prefixes, right ? It might be a big overhead. >> - Also, I don't understand well the utility of the I flag in the Mobile >> Network Prefix Option: >> Implicit (I): The (I) bit is set if the prefix is assigned to and >> routed via the MR even if the prefix is not listed in explicit >> mode BU. >> >> No MNP options are used when the MR uses Implicit mode. So this bit is >> never used. Or does the HA has to use the MNP option and set this bit >> when listing all the prefixes owned by the MR ? > > > That's correct. The idea is to be able to explicitly list *all* prefixes > assigned, including ones that are bound using implicit BUs. Ok, but if the HA uses MNPO to list all the prefixes, see my comment above. >> - Once the prefix delegation is finished, does the MR and HA have to >> set the >> bit relative to prefix delegation in the MNP Option? Or should they >> just operate NEMO BS (unless they send/receive MNP request or >> confirmation option)? > > > Should be orthagonal, so that you can just use regular NEMO BS. Ok, it seems coherent. Thanks, Romain From nemo-bounces@ietf.org Wed Jul 27 01:01:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxe2W-0002BI-VR; Wed, 27 Jul 2005 01:01:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxe2P-0002Ar-UD for nemo@megatron.ietf.org; Wed, 27 Jul 2005 01:01:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21034 for ; Wed, 27 Jul 2005 01:01:00 -0400 (EDT) Received: from omgo.iij.ad.jp ([202.232.30.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxeXa-00069N-Sn for nemo@ietf.org; Wed, 27 Jul 2005 01:33:16 -0400 Received: OTM-MO id j6R50wV5018275; Wed, 27 Jul 2005 14:00:58 +0900 (JST) Received: OTM-MIX0 id j6R50v1M026212; Wed, 27 Jul 2005 14:00:58 +0900 (JST) Received: from localhost (jc-ssh.iij.ad.jp [192.168.174.22]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id j6R50vDf000721 for ; Wed, 27 Jul 2005 14:00:57 +0900 (JST) Date: Wed, 27 Jul 2005 14:00:56 +0900 (JST) Message-Id: <20050727.140056.133689140.keiichi@iijlab.net> To: nemo@ietf.org From: Keiichi SHIMA X-Mailer: Mew version 4.2.53 on Emacs 22.0.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Subject: [nemo] IPv4 prefix option for NEMO BS X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello, I have submitted an Internet-Draft which specifies the mechanism to enable IPv4 mobile network using IPv6 infrastructure. Unfortunately, the draft will not appear in the I-D directory, since I couldn't submit it before the deadline. If you are interested in the idea, you can get a copy of the draft from the following URL. http://www.kame.net/~keiichi/internet-drafts/draft-shima-nemo-v4prefix-00.txt I quote the Introduction section so that you can overview the intent of the draft bellow. Any comments are welcome. Regards, ---- 1. Introduction NEMO (RFC3963) [1] specifies the mechanism to provide mobility functions to IPv6 networks. All IPv6 networks behind a NEMO capable router can move around all over the Internet with the NEMO router, without breaking existing connections between nodes inside the moving network and nodes of the Internet. The NEMO specification mentions only IPv6 networks. In this document, we propose an extension which adds the IPv4 network support to the NEMO specification. With the option we introduce in this document, we can operate IPv4 mobile networks over the IPv6 network infrastructure. Considering the situation that we need to live with both IPv4 and IPv6 networks during the transition period before we have completely shifted to IPv6, many IPv4 devices/networks will be used for a long time. NEMO provides a simple mechanism to enable IPv6 networks move around the Internet. The technology is expected to be used for various scenes, such as implementing car/train networks, a personal area networks, or even providing redundancy to networks of an entire site of an organization(draft-nagami-mip6-nemo-multihome-fixed-network [2]). Supporting only IPv6 devices and dropping IPv4 devices are not good idea especially in the forthcoming long transition period. However defining a new mobile network protocol for IPv4 is not expected, since IPv4 is going to disappear finally. This document defines a mechanism to provide IPv4 mobile network using IPv6 connections. We can use with both protocols with this proposed technology and we also can move to IPv6 only network seamlessly when the IPv4 network completes its role. --- Keiichi SHIMA IIJ Research Laboratory KAME Project From nemo-bounces@ietf.org Wed Jul 27 02:23:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxfJs-0004zn-2V; Wed, 27 Jul 2005 02:23:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxfJo-0004zi-FV for nemo@megatron.ietf.org; Wed, 27 Jul 2005 02:23:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19185 for ; Wed, 27 Jul 2005 02:23:02 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxfp0-00087V-6c for nemo@ietf.org; Wed, 27 Jul 2005 02:55:19 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6R5pi108961; Tue, 26 Jul 2005 22:51:44 -0700 X-mProtect: <200507270551> Nokia Silicon Valley Messaging Protection Received: from danira-pool053149.americas.nokia.com (10.241.53.149, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpd5Z3znJ; Tue, 26 Jul 2005 22:51:42 PDT Message-ID: <42E7282E.8010207@iprg.nokia.com> Date: Tue, 26 Jul 2005 23:22:38 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keiichi SHIMA Subject: Re: [nemo] IPv4 prefix option for NEMO BS References: <20050727.140056.133689140.keiichi@iijlab.net> In-Reply-To: <20050727.140056.133689140.keiichi@iijlab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org hi Keiichi, thanks for writing up a draft on this. I think something like this is needed and I support working on this in the NEMO WG. this scenario had in fact come up in the mip6trans (v4 traversal) design team. we concluded that this does not directly impact the v4 traversal solution and can be done separately. Vijay Keiichi SHIMA wrote: > Hello, > > I have submitted an Internet-Draft which specifies the mechanism to > enable IPv4 mobile network using IPv6 infrastructure. Unfortunately, > the draft will not appear in the I-D directory, since I couldn't > submit it before the deadline. If you are interested in the > idea, you can get a copy of the draft from the following URL. > > http://www.kame.net/~keiichi/internet-drafts/draft-shima-nemo-v4prefix-00.txt > > I quote the Introduction section so that you can overview the intent > of the draft bellow. Any comments are welcome. > > Regards, > > ---- > 1. Introduction > > NEMO (RFC3963) [1] specifies the mechanism to provide mobility > functions to IPv6 networks. All IPv6 networks behind a NEMO capable > router can move around all over the Internet with the NEMO router, > without breaking existing connections between nodes inside the moving > network and nodes of the Internet. > > The NEMO specification mentions only IPv6 networks. In this > document, we propose an extension which adds the IPv4 network support > to the NEMO specification. With the option we introduce in this > document, we can operate IPv4 mobile networks over the IPv6 network > infrastructure. > > Considering the situation that we need to live with both IPv4 and > IPv6 networks during the transition period before we have completely > shifted to IPv6, many IPv4 devices/networks will be used for a long > time. NEMO provides a simple mechanism to enable IPv6 networks move > around the Internet. The technology is expected to be used for > various scenes, such as implementing car/train networks, a personal > area networks, or even providing redundancy to networks of an entire > site of an > organization(draft-nagami-mip6-nemo-multihome-fixed-network [2]). > Supporting only IPv6 devices and dropping IPv4 devices are not good > idea especially in the forthcoming long transition period. > > However defining a new mobile network protocol for IPv4 is not > expected, since IPv4 is going to disappear finally. This document > defines a mechanism to provide IPv4 mobile network using IPv6 > connections. We can use with both protocols with this proposed > technology and we also can move to IPv6 only network seamlessly when > the IPv4 network completes its role. > > > --- > Keiichi SHIMA > IIJ Research Laboratory > KAME Project > From nemo-bounces@ietf.org Wed Jul 27 09:11:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxlhI-0002bX-Gx; Wed, 27 Jul 2005 09:11:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxlhH-0002bS-5V for nemo@megatron.ietf.org; Wed, 27 Jul 2005 09:11:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26009 for ; Wed, 27 Jul 2005 09:11:41 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxmCX-0004ZT-L7 for nemo@ietf.org; Wed, 27 Jul 2005 09:44:01 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j6RDL6bk020565; Wed, 27 Jul 2005 06:21:06 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j6RDGfJJ000946; Wed, 27 Jul 2005 08:16:42 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 27938865980; Wed, 27 Jul 2005 15:11:33 +0200 (CEST) Message-ID: <42E78804.5000700@motorola.com> Date: Wed, 27 Jul 2005 15:11:32 +0200 From: Alexandru Petrescu Organization: Motorola Labs, Paris, France User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Keiichi SHIMA Subject: Re: [nemo] IPv4 prefix option for NEMO BS References: <20050727.140056.133689140.keiichi@iijlab.net> In-Reply-To: <20050727.140056.133689140.keiichi@iijlab.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Keiichi, thanks for writing this draft, it is an interesting approach in a v4-v6 coexistence mobility model. It takes a particular perspective at seeing IP deployment, where a wide-area network is completely IPv6 enabled and has no IPv4, so IPv4 traffic needs to be tunneled through IPv6. What is the tunneling method planned for putting application-level IPv4 packets in IPv6 packets? Thank you, Alex Keiichi SHIMA wrote: > Hello, > > I have submitted an Internet-Draft which specifies the mechanism to > enable IPv4 mobile network using IPv6 infrastructure. Unfortunately, > the draft will not appear in the I-D directory, since I couldn't > submit it before the deadline. If you are interested in the > idea, you can get a copy of the draft from the following URL. > > http://www.kame.net/~keiichi/internet-drafts/draft-shima-nemo-v4prefix-00.txt > > I quote the Introduction section so that you can overview the intent > of the draft bellow. Any comments are welcome. > > Regards, > > ---- > 1. Introduction > > NEMO (RFC3963) [1] specifies the mechanism to provide mobility > functions to IPv6 networks. All IPv6 networks behind a NEMO capable > router can move around all over the Internet with the NEMO router, > without breaking existing connections between nodes inside the moving > network and nodes of the Internet. > > The NEMO specification mentions only IPv6 networks. In this > document, we propose an extension which adds the IPv4 network support > to the NEMO specification. With the option we introduce in this > document, we can operate IPv4 mobile networks over the IPv6 network > infrastructure. > > Considering the situation that we need to live with both IPv4 and > IPv6 networks during the transition period before we have completely > shifted to IPv6, many IPv4 devices/networks will be used for a long > time. NEMO provides a simple mechanism to enable IPv6 networks move > around the Internet. The technology is expected to be used for > various scenes, such as implementing car/train networks, a personal > area networks, or even providing redundancy to networks of an entire > site of an > organization(draft-nagami-mip6-nemo-multihome-fixed-network [2]). > Supporting only IPv6 devices and dropping IPv4 devices are not good > idea especially in the forthcoming long transition period. > > However defining a new mobile network protocol for IPv4 is not > expected, since IPv4 is going to disappear finally. This document > defines a mechanism to provide IPv4 mobile network using IPv6 > connections. We can use with both protocols with this proposed > technology and we also can move to IPv6 only network seamlessly when > the IPv4 network completes its role. > > > --- > Keiichi SHIMA > IIJ Research Laboratory > KAME Project From nemo-bounces@ietf.org Wed Jul 27 23:43:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxzIj-0003rl-HJ; Wed, 27 Jul 2005 23:43:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxzIi-0003re-AT for nemo@megatron.ietf.org; Wed, 27 Jul 2005 23:43:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00708 for ; Wed, 27 Jul 2005 23:43:13 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxzo5-0005TL-Ly for nemo@ietf.org; Thu, 28 Jul 2005 00:15:42 -0400 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 670CC4C07A for ; Thu, 28 Jul 2005 12:42:53 +0900 (JST) Date: Thu, 28 Jul 2005 12:42:53 +0900 From: Thierry Ernst To: ml-nemo Message-Id: <20050728124253.416c15e8.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [nemo] Preparing slides X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all presenters, Please send TJ and mysefl your PDF slides ahead of time, preferably by Monday evening Paris time so that we can have an eye on it and discuss with the presenters if necessary. I would personaly appreciate if you could name your file with prefix nemo-ietf63: nemo-ietf63-[key_word]-[author].pdf e.g nemo-ietf63-Terminology-TErnst.pdf Unless you ask not to, we would put the slides as usual on the NEMO additional web page http://www.mobilenetworks.org/nemo/ietf63 before the meeting starts. Thierry. From nemo-bounces@ietf.org Thu Jul 28 13:40:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCNO-0004YN-3R; Thu, 28 Jul 2005 13:40:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCNM-0004WI-7U; Thu, 28 Jul 2005 13:40:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15251; Thu, 28 Jul 2005 13:40:52 -0400 (EDT) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyCsq-0004gb-HG; Thu, 28 Jul 2005 14:13:30 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6SHYu4N020578; Thu, 28 Jul 2005 20:34:58 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jul 2005 20:40:31 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jul 2005 12:40:28 -0500 Received: from 205.226.2.40 ([205.226.2.40]) by mvebe101.NOE.Nokia.com ([172.19.64.23]) with Microsoft Exchange Server HTTP-DAV ; Thu, 28 Jul 2005 17:40:27 +0000 Received: from vijayd2 by mvebe101.americas.nokia.com; 28 Jul 2005 10:40:27 -0700 From: Vijay Devarapalli To: mip6@ietf.org, nemo@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 28 Jul 2005 10:40:27 -0700 Message-Id: <1122572427.30127.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-16) X-OriginalArrivalTime: 28 Jul 2005 17:40:28.0697 (UTC) FILETIME=[71B72890:01C5939B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Subject: [nemo] v4 traversal slides X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org [I am resending. apologize if you get multiple copies.] hi all, here are the slides that will be presented as a status update from the mip6trans design team next week at the MIP6 and NEMO WG meetings. http://people.nokia.net/vijayd/mip6trans/ietf63_mip6_mip6trans.pdf unfortunately, we didn't have enough time to submit an internet draft. the above slideset talks about the scenarios the design team is going to solve. it also lists the solution requirements. Vijay From nemo-bounces@ietf.org Thu Jul 28 20:15:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyIWp-0006eI-TW; Thu, 28 Jul 2005 20:15:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyIWp-0006e5-22; Thu, 28 Jul 2005 20:15:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08642; Thu, 28 Jul 2005 20:15:05 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyJ2M-0006Cf-Su; Thu, 28 Jul 2005 20:47:44 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6SNhlC13293; Thu, 28 Jul 2005 16:43:47 -0700 X-mProtect: <200507282343> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp162227.americas.nokia.com (10.241.162.227, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdlFPWLl; Wed, 27 Jul 2005 22:23:36 PDT Message-ID: <42E8731A.6000308@iprg.nokia.com> Date: Wed, 27 Jul 2005 22:54:34 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org, nemo@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: Subject: [nemo] v4 traversal slides X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org hi all, here are the slides that will be presented as a status update from the mip6trans design team next week at the MIP6 and NEMO WG meetings. http://people.nokia.net/vijayd/mip6trans/ietf63_mip6_mip6trans.pdf unfortunately, we didnt have enough time to submit an internet draft. the above slideset talks about the scenarios the design team is going to solve. it also lists the solution requirements. Vijay From nemo-bounces@ietf.org Thu Jul 28 21:02:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyJH8-0003RS-QD; Thu, 28 Jul 2005 21:02:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyJH7-0003Q8-7h for nemo@megatron.ietf.org; Thu, 28 Jul 2005 21:02:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11016 for ; Thu, 28 Jul 2005 21:02:55 -0400 (EDT) Received: from omgo.iij.ad.jp ([202.232.30.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyJmf-0007Le-BZ for nemo@ietf.org; Thu, 28 Jul 2005 21:35:34 -0400 Received: OTM-MO id j6T12hFq029863; Fri, 29 Jul 2005 10:02:43 +0900 (JST) Received: OTM-MIX0 id j6T12gZk009018; Fri, 29 Jul 2005 10:02:43 +0900 (JST) Received: from localhost (keiichi00.osaka.iij.ad.jp [192.168.64.45]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id j6T12g8w020315 for ; Fri, 29 Jul 2005 10:02:42 +0900 (JST) Date: Fri, 29 Jul 2005 10:03:03 +0900 (JST) Message-Id: <20050729.100303.25321946.keiichi@iijlab.net> To: nemo@ietf.org Subject: Re: [nemo] IPv4 prefix option for NEMO BS From: Keiichi SHIMA In-Reply-To: <42E7282E.8010207@iprg.nokia.com> References: <20050727.140056.133689140.keiichi@iijlab.net> <42E7282E.8010207@iprg.nokia.com> X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Vijay, From: Vijay Devarapalli Date: Tue, 26 Jul 2005 23:22:38 -0700 > I think something like this is needed and I support working > on this in the NEMO WG. > > this scenario had in fact come up in the mip6trans (v4 > traversal) design team. we concluded that this does not > directly impact the v4 traversal solution and can be done > separately. Yes, I also think it can be done separately. I think the goals of the v4 traversal and my draft are different. The former tries to invent a method to enable IPv6 mobility over the IPv4 infrastructure, and the latter tries to enable IPv4 mobility over the IPv6 infrastructure. These two mechanisms are both required during the transition period. And, if we carefully design them, we can use both technology even at the same time, which makes IPv4 NEMO over the IPv4 infrastructure with NEMO signaling messages. I hope many people support the idea. Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From nemo-bounces@ietf.org Thu Jul 28 21:14:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyJSL-0006UM-UR; Thu, 28 Jul 2005 21:14:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyJSK-0006UC-BZ for nemo@megatron.ietf.org; Thu, 28 Jul 2005 21:14:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11429 for ; Thu, 28 Jul 2005 21:14:30 -0400 (EDT) Received: from omgo.iij.ad.jp ([202.232.30.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyJxs-0007aG-Hu for nemo@ietf.org; Thu, 28 Jul 2005 21:47:10 -0400 Received: OTM-MO id j6T1ETNK000698; Fri, 29 Jul 2005 10:14:29 +0900 (JST) Received: OTM-MIX0 id j6T1ESTQ012955; Fri, 29 Jul 2005 10:14:28 +0900 (JST) Received: from localhost (keiichi00.osaka.iij.ad.jp [192.168.64.45]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id j6T1ESad020946 for ; Fri, 29 Jul 2005 10:14:28 +0900 (JST) Date: Fri, 29 Jul 2005 10:14:48 +0900 (JST) Message-Id: <20050729.101448.65782879.keiichi@iijlab.net> To: nemo@ietf.org Subject: Re: [nemo] IPv4 prefix option for NEMO BS From: Keiichi SHIMA In-Reply-To: <42E78804.5000700@motorola.com> References: <20050727.140056.133689140.keiichi@iijlab.net> <42E78804.5000700@motorola.com> X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Alex, From: Alexandru Petrescu Date: Wed, 27 Jul 2005 15:11:32 +0200 > Keiichi, thanks for writing this draft, it is an interesting approach in > a v4-v6 coexistence mobility model. Yes, moreover, we definitely need IPv4 at least during the transition period, I think. Many people request IPv4 connectivity in fact, even if they know NEMO and they are interested in IPv6 mobility technologies. > It takes a particular perspective at seeing IP deployment, where a > wide-area network is completely IPv6 enabled and has no IPv4, so IPv4 > traffic needs to be tunneled through IPv6. Yes, and such a situation has been already occurred partially. Some ISP already can provide IPv6 connectivity to all customers of its service area, at least with fixed lines. When the idea raised in my head, I was thinking to provide multihoming service to the ISP customers using draft-nagami-mip6-nemo-multihome-fixed-network. In the current situation, all customer needs IPv4 also. If NEMO can also provide IPv4 network mobility capability, maybe I can provide NEMO based multihoming service right now. > What is the tunneling method planned for putting application-level IPv4 > packets in IPv6 packets? I'm sorry but I'm afraid I didn't get your question... I was just thinking that all IPv4 packets are tunneled through the IPv6 tunnel between a mobile router and its home agent. What do you mean by 'application-level'? Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From nemo-bounces@ietf.org Fri Jul 29 09:44:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyV9p-0004cL-0Q; Fri, 29 Jul 2005 09:44:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyV9n-0004cG-50 for nemo@megatron.ietf.org; Fri, 29 Jul 2005 09:44:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09095 for ; Fri, 29 Jul 2005 09:44:08 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyVfS-0001lC-2W for nemo@ietf.org; Fri, 29 Jul 2005 10:16:55 -0400 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j6TDrhrj010700; Fri, 29 Jul 2005 06:53:43 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j6TDmdpL009763; Fri, 29 Jul 2005 08:48:40 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 22D54865980; Fri, 29 Jul 2005 15:44:06 +0200 (CEST) Message-ID: <42EA32A6.1020700@motorola.com> Date: Fri, 29 Jul 2005 15:44:06 +0200 From: Alexandru Petrescu Organization: Motorola Labs, Paris, France User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Keiichi SHIMA Subject: Re: [nemo] IPv4 prefix option for NEMO BS References: <20050727.140056.133689140.keiichi@iijlab.net> <42E78804.5000700@motorola.com> <20050729.101448.65782879.keiichi@iijlab.net> In-Reply-To: <20050729.101448.65782879.keiichi@iijlab.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Keiichi SHIMA wrote: > Hi Alex, > > From: Alexandru Petrescu > Date: Wed, 27 Jul 2005 15:11:32 +0200 > > >>Keiichi, thanks for writing this draft, it is an interesting approach in >>a v4-v6 coexistence mobility model. > > > Yes, moreover, we definitely need IPv4 at least during the transition > period, I think. Many people request IPv4 connectivity in fact, even > if they know NEMO and they are interested in IPv6 mobility > technologies. > > >>It takes a particular perspective at seeing IP deployment, where a >>wide-area network is completely IPv6 enabled and has no IPv4, so IPv4 >>traffic needs to be tunneled through IPv6. > > > Yes, and such a situation has been already occurred partially. Some > ISP already can provide IPv6 connectivity to all customers of its > service area, at least with fixed lines. When the idea raised in my > head, I was thinking to provide multihoming service to the ISP > customers using draft-nagami-mip6-nemo-multihome-fixed-network. In > the current situation, all customer needs IPv4 also. If NEMO can > also provide IPv4 network mobility capability, maybe I can provide > NEMO based multihoming service right now. > > >>What is the tunneling method planned for putting application-level IPv4 >>packets in IPv6 packets? > > > I'm sorry but I'm afraid I didn't get your question... I was just > thinking that all IPv4 packets are tunneled through the IPv6 tunnel > between a mobile router and its home agent. What do you mean by > 'application-level'? Sorry, that is right, I was missing the fact that RFC2473 "Generic Packet Tunnelling IPv6" can actually encapsulate IPv4 in IPv6 too, not only IPv6 in IPv6. Alex From nemo-bounces@ietf.org Fri Jul 29 19:25:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyeDw-0007nX-JF; Fri, 29 Jul 2005 19:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyeDu-0007k9-CP for nemo@megatron.ietf.org; Fri, 29 Jul 2005 19:25:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16471 for ; Fri, 29 Jul 2005 19:24:58 -0400 (EDT) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyejY-0001Wd-VU for nemo@ietf.org; Fri, 29 Jul 2005 19:57:51 -0400 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 436E96420; Fri, 29 Jul 2005 16:24:26 -0700 (PDT) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57284-17; Fri, 29 Jul 2005 16:24:18 -0700 (PDT) Received: by deimos.multihop.net (Postfix, from userid 1013) id 9F683641E; Fri, 29 Jul 2005 16:24:18 -0700 (PDT) Received: from [192.103.16.119] (unknown [192.103.16.119]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id DCED46170; Fri, 29 Jul 2005 16:24:17 -0700 (PDT) In-Reply-To: <42E6D592.90600@sfc.wide.ad.jp> References: <42E4C5C5.3000501@sfc.wide.ad.jp> <9d173ec44e3a58dc22c1563a6803b155@kniveton.com> <42E6D592.90600@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <39AD4325-268A-4EC0-98F7-0AFB4879AB79@kniveton.com> Content-Transfer-Encoding: 7bit From: "T.J. Kniveton" Subject: Re: [nemo] Questions about draft-kniveton-nemo-prefix-delegation-01 Date: Fri, 29 Jul 2005 16:24:31 -0700 To: Romain KUNTZ X-Mailer: Apple Mail (2.733) X-Spam-Score: -3.2 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on deimos.multihop.net X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Jul 26, 2005, at 5:30 PM, Romain KUNTZ wrote: > Hello, > > Thank you for your reply. More comments below: > > T.J. Kniveton wrote: > >> Should I take it that you're implementing the draft? :-D >> > > Let's say I am interested in :) Good > > >>> - In section 5.2, it is said: >>> When setting the Prefix Status bit, the HA also >>> lists all the prefixes associated to that Mobile Router using >>> Mobile >>> Network Prefix Confirmation options. >>> >>> But in section 8, it is said: >>> If the Binding Update contains an S bit, the Home Agent >>> includes a >>> Mobile Network Prefix Option for each prefix the Home Agent >>> believes >>> is assigned to the Mobile Route >>> >>> So which one of the MNP Option or the MNP Confirmation Option >>> should be >>> used to list all the MNPs ? >>> >> This is something we need to think about further -- I believe that >> they should be MNPOs, and MNPCOs are reserved for a request- >> response of a delegation event. But I would also like to hear >> others' opinions on this. >> > > The problem is that if you use MNPOs, then in the case where the MR > sends a registration BU with MNP Request Options + the S bit set, > then the HA will have to reply with MNPCO and MNPO for the same > prefixes, right ? It might be a big overhead. I would imagine that you would process the request, put an MNPCO at the end of the BAck, then process the S bit and put MNPO for all prefixes (including the one assigned). I suppose we should discuss this more in person, next week. > > >>> - Also, I don't understand well the utility of the I flag in the >>> Mobile >>> Network Prefix Option: >>> Implicit (I): The (I) bit is set if the prefix is assigned >>> to and >>> routed via the MR even if the prefix is not listed in explicit >>> mode BU. >>> >>> No MNP options are used when the MR uses Implicit mode. So this >>> bit is >>> never used. Or does the HA has to use the MNP option and set this >>> bit >>> when listing all the prefixes owned by the MR ? >>> >> That's correct. The idea is to be able to explicitly list *all* >> prefixes assigned, including ones that are bound using implicit BUs. >> > > Ok, but if the HA uses MNPO to list all the prefixes, see my > comment above. How does it relate to implicit prefixes? > > >>> - Once the prefix delegation is finished, does the MR and HA have >>> to set the >>> bit relative to prefix delegation in the MNP Option? Or should they >>> just operate NEMO BS (unless they send/receive MNP request or >>> confirmation option)? >>> >> Should be orthagonal, so that you can just use regular NEMO BS. >> > > Ok, it seems coherent. > > Thanks, > > Romain > > From nemo-bounces@ietf.org Sun Jul 31 06:22:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzAxW-0001ee-On; Sun, 31 Jul 2005 06:22:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzAxU-0001e7-78; Sun, 31 Jul 2005 06:22:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15275; Sun, 31 Jul 2005 06:22:13 -0400 (EDT) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzBTV-0004V6-Hq; Sun, 31 Jul 2005 06:55:23 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 54AA7100; Sun, 31 Jul 2005 06:21:55 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 06:21:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [nemo] v4 traversal slides Date: Sun, 31 Jul 2005 06:21:53 -0400 Message-ID: <936A4045C332714F975800409DE09240B31546@tayexc14.americas.cpqcorp.net> Thread-Topic: Re: [nemo] v4 traversal slides Thread-Index: AcWTnAPnTDagx3irQk+ryYNjYIGNjAAxdmagAFWy4mA= From: "Bound, Jim" To: , X-OriginalArrivalTime: 31 Jul 2005 10:21:55.0108 (UTC) FILETIME=[ACD55E40:01C595B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Folks, I think we need to at least address and discuss the scenario where the HA is on IPv6-Dominant network, meaning IPv4 routing has been shut off per policy of the user on that network. The MN shows up on IPv4-Only access network. Bi-directional commo is required between MN and HA, but MN has entered IPv4 net. We need to consider this in our scenarios. I have communicated this to some and talking with Pascal T. This is a real scenario that is being planned today by several large enterpises. Thanks /jim -----Original Message----- From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Vijay Devarapalli Sent: Thursday, July 28, 2005 7:40 PM To: mip6@ietf.org;=20 Subject: [nemo] v4 traversal slides [I am resending. apologize if you get multiple copies.] hi all,=20 here are the slides that will be presented as a status=20 update from the mip6trans design team next week at the=20 MIP6 and NEMO WG meetings.=20 http://people.nokia.net/vijayd/mip6trans/ietf63_mip6_mip6trans.pdf=20 unfortunately, we didn't have enough time to submit an=20 internet draft.=20 the above slideset talks about the scenarios the design=20 team is going to solve. it also lists the solution=20 requirements.=20 Vijay=20