From nemo-admin@nal.motlabs.com Tue Apr 1 00:59:26 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14257 for ; Tue, 1 Apr 2003 00:59:13 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h315pKRC008871; Tue, 1 Apr 2003 07:51:20 +0200 Received: from melanieb.vtt.fi (melanieb.vtt.fi [130.188.1.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h315nfRC008857 for ; Tue, 1 Apr 2003 07:49:54 +0200 Received: from elemail.ele.vtt.fi ([127.0.0.1]) by melanieb.vtt.fi (8.12.9/8.12.9) with ESMTP id h315nOOt015004; Tue, 1 Apr 2003 08:49:24 +0300 (EEST) Received: from ele4114.vtt.fi (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with ESMTP id IAA06383; Tue, 1 Apr 2003 08:49:13 +0300 (EET DST) Message-Id: <4.3.2.7.2.20030401082643.00bdd8a0@elemail.ele.vtt.fi> X-Sender: eleppa@elemail.ele.vtt.fi X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Erik Nordmark From: Pekka =?iso-8859-1?Q?Pääkkönen?= Subject: [nemo] new draft on MNP delegation for NEMO networks Cc: nemo@nal.motlabs.com In-Reply-To: References: <"Your message with ID" <4.3.2.7.2.20030326083724.00bcc6f0@elemail.ele.vtt.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 01 Apr 2003 08:49:10 +0200 I think you're right about the requirements for prefix delegation. I wasn't sure that DHCPv6 could be used in a mobile environment without problems. This was due to my misinterpreting the MIPv6 draft about link-local addressing. I guess DHCPv6 can be used through a tunnel to the HA with link-local addresses, if the HA has locally a DHCPv6 server/relay and no forwarding at the HA takes place. Pekka At 20:08 31.3.2003 +0200, Erik Nordmark wrote: > > I have submitted a new draft on Mobile Network Prefix (MNP) delegation > > related to > > mobile networks. The draft proposes that MNP delegation should occur > between > > a MR and its HA, and defines a MIPv6 extension for it. With this extension > > it is possible for the MR to dynamically delegate MNPs when at home or away > > from home. I hope that the draft causes discussion on MNP delegation > related > > to NEMO networks. > >I'm trying to understand how mobility makes the requirements on prefix >delegation different than in the non-mobile case? >It seems like the lifetime of the delegations are independent of the movements >thus wouldn't whatever works for IPv6 in general work in the Nemo case? >(Such as draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt) > > Erik From nemo-admin@nal.motlabs.com Tue Apr 1 06:10:38 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03889 for ; Tue, 1 Apr 2003 06:10:23 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h31B42RC011389; Tue, 1 Apr 2003 13:04:04 +0200 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h31B1lRC011375; Tue, 1 Apr 2003 13:01:52 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h317cdvM007182; Tue, 1 Apr 2003 09:39:09 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 1 Apr 2003 09:40:42 +0200 Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-lon-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 1 Apr 2003 08:40:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] multihoming: potential threat? (was: about draft-ietf-nemo-requirements-00.txt) Message-ID: Thread-Topic: [nemo] multihoming: potential threat? (was: about draft-ietf-nemo-requirements-00.txt) Thread-Index: AcL38WREIb6k8K8wT9CIq4I7wriDOQAL3g0Q From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" Cc: "Alexandru Petrescu" , "Hesham Soliman (EAB)" , "Takeshi TANAKA" , "marcelo bagnulo" , "IETF NEMO" X-OriginalArrivalTime: 01 Apr 2003 07:40:41.0952 (UTC) FILETIME=[FF3BE600:01C2F821] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h31B1lRC011375 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 1 Apr 2003 08:40:41 +0100 Content-Transfer-Encoding: 8bit > Note that RFC 2461 doesn't say that routers autoconfigure > addresses based on RAs they receive - it merely states that > routers should do some sanity checks to make sure different > RAs don't have conflicting information (where different > prefixes isn't a conflict). > Whether your router autoconfigures addresses or not is an admin decision should the router have support for this at all; cisco routers certainly do... Does it make sense for mobile routers to use that feature in the multihoming case? I'm still not to clear about the use cases. Pascal From nemo-admin@nal.motlabs.com Tue Apr 1 08:32:24 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09753 for ; Tue, 1 Apr 2003 08:32:11 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h31DLORC012188; Tue, 1 Apr 2003 15:21:24 +0200 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h31DKORC012176 for ; Tue, 1 Apr 2003 15:20:31 +0200 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h31DJufI011028; Tue, 1 Apr 2003 06:20:00 -0700 (MST) Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id GAA16543; Tue, 1 Apr 2003 06:20:04 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h31DJxj13248; Tue, 1 Apr 2003 07:19:59 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 4181A2EC86; Tue, 1 Apr 2003 15:19:57 +0200 (CEST) Message-ID: <3E8991FD.6070400@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: =?ISO-8859-1?Q?Pekka_=3D=3Fiso-8859-1=3FQ=3FP=E4=E4kk=F6nen=3F=3D?=, Ole Troan, , Subject: Re: [nemo] Link local addresses References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 01 Apr 2003 15:19:57 +0200 Content-Transfer-Encoding: 7bit I'm trying to understand this... Erik Nordmark wrote: >> I would suppose that this is an issue of the link-local >> addressing of MR in general. The use of DHCPv6 is but one >> "link-local addressing" issue for MR. The other link-local >> addressing issues for MR come from the use of routing protocols >> between MR and HA; another link-local address issue is also the >> HA sending RA's to MR (or MH for that matter); yet another is >> from multicast MLD between MR and HA, that also uses link-local >> addressing. > > What exists in MIPv6 is a prohbition from _forwarding_ packets with > link-local addresses out over the tunnel to the MN. > > But I think all the cases above are about operating a protocol > which uses link-local addresses on the link which is the tunnel; > the link-local addresses used on the tunnel can be used in that > case since there isn't any forwarding taking place. Perhaps this > isn't clear enough in the specs. Aha. There's a particular phrase in the Mobile IPv6 that I would like to better understand. When describing the HA behaviour when intercepting packets, it says: "However, packets addressed to the mobile node's link-local address MUST NOT be tunneled to the mobile node." With the previous interpretation, that would become: "However, packets addressed to the mobile node's link-local address MUST NOT be forwarded to the mobile node, but they SHOULD (if L=1) be tunneled over the virtual tunnel interface MN-HA." Is this the intended meaning? > Thus in the particular case of DHCPv6, the HA would operate a > DHCPv6 agent (either a server or a relay) on the tunnel interface. I think HA could operate a DHCPv6 agent over the tunnel interface, but only when MN is not at home, right? Also, I wonder whether it would be benefic that the entire scheme works with three separated entities: DHCPv6 agent, the HA and the BR in the home domain, on the same home link (as opposed to having all three entities co-located in the BR). Alex From nemo-admin@nal.motlabs.com Tue Apr 1 10:11:32 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17949 for ; Tue, 1 Apr 2003 10:11:23 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h31F6iRC012688; Tue, 1 Apr 2003 17:06:46 +0200 Received: from ds20.nudt.edu.cn ([61.187.56.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h31F4sRC012674 for ; Tue, 1 Apr 2003 17:05:08 +0200 Received: from fish (unknown [172.26.20.21]) by ds20.nudt.edu.cn (Postfix) with SMTP id 9C3145A3EE; Tue, 1 Apr 2003 23:07:33 +0800 (HKT) Message-ID: <005901c2f85f$e7befbf0$7119190d@fish> From: "wlyu" To: "T.J. Kniveton" Cc: References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by jessica.nal.motlabs.com id h31F4sRC012674 Subject: [nemo] Comments on MRTP Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 1 Apr 2003 23:03:50 +0800 Content-Transfer-Encoding: 8bit Hi T.j, >When the HA_MR receives the routing information from the mobile router >through the bidirectional tunnel, it adds the corresponding routes to >its routing table with the next hop set to the mobile router's address, >in case of IPv6 MR's link local address. This next hop address is >obtained from the source address of the inner packet. The HA_MR in >turn propagates this information when it sends routing updates to other >routers on the mobile router's home link. when HA_MR to do so, the bidirectional tunnel must have been setup between MR and HA_MR, yes or no? So when the MR moves to foreign link, it first acts as an normal MN to interchange binding information with HA_MR, before the establishment of tunnel, HA_MR can't receive routing information from MR. So, before the process is finished, MR can't serve the nodes behinds it ? Maybe it's about implementation,but I still to ask the question:-) Thanks a lot. Wanrong Yu . From nemo-admin@nal.motlabs.com Tue Apr 1 10:37:22 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20993 for ; Tue, 1 Apr 2003 10:37:13 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h31FZARC012798; Tue, 1 Apr 2003 17:35:10 +0200 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h31FXqRC012786; Tue, 1 Apr 2003 17:33:59 +0200 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08908; Tue, 1 Apr 2003 08:33:44 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h31FXTS19979; Tue, 1 Apr 2003 17:33:29 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Link local addresses To: Alexandru Petrescu Cc: Erik Nordmark , =?iso-8859-1?Q?Pekka_=3D=3Fiso-8859-1=3FQ=3FP=E4=E4kk=F6nen=3F=3D?= , Ole Troan , nemo@nal.motlabs.com, rdroms@cisco.com In-Reply-To: "Your message with ID" <3E8991FD.6070400@nal.motlabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 1 Apr 2003 17:31:57 +0200 (CEST) > Aha. There's a particular phrase in the Mobile IPv6 that I would like > to better understand. When describing the HA behaviour when > intercepting packets, it says: > > "However, packets addressed to the mobile node's link-local address > MUST NOT be tunneled to the mobile node." > > With the previous interpretation, that would become: > > "However, packets addressed to the mobile node's link-local address > MUST NOT be forwarded to the mobile node, but they SHOULD (if L=1) > be tunneled over the virtual tunnel interface MN-HA." > > Is this the intended meaning? No, since this is in the context of intercepting packets destined to the mobile node. The need for DHCPv6 etc is to be able to _originate_ (not forward) packets on the tunnel link which uses link-local addresses. The formation of link-local addresses for tunnels is described in RFC 2473. Note that the MNs link-local address on the tunnel interface might be different than the link-local address the MN has on its non-tunnel interface when it is at home, but they might also be the same. In any case it doesn't matter since the link-local addresses only need to be unique per link and the tunnel is a different link than the non-tunnel. > I think HA could operate a DHCPv6 agent over the tunnel interface, but > only when MN is not at home, right? *If* there was a tunnel when the MN was at home it could oerate DHCPv6 while at home. MIPv6 doesn't have a tunnel while at home. Point is this is not an issue for DHCPv6 - it is an issue whether the tunnel exists or not. If Nemo doesn't use a tunnel at home, presumably DHCPv6 for prefix delegation could be used over the home link. > Also, I wonder whether it would be benefic that the entire scheme > works with three separated entities: DHCPv6 agent, the HA and the BR > in the home domain, on the same home link (as opposed to having all > three entities co-located in the BR). What's a BR? MR? Border Router? And DHCP can already have two levels - a relay agent and a server. Erik From nemo-admin@nal.motlabs.com Tue Apr 1 12:18:44 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01054 for ; Tue, 1 Apr 2003 12:18:30 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h31HEORC013183; Tue, 1 Apr 2003 19:14:32 +0200 Received: from multihop.net ([192.103.16.205]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h31HCqRC013170 for ; Tue, 1 Apr 2003 19:12:57 +0200 Received: from diego (ppp3-5.interar.com.ar [200.47.14.5] (may be forged)) by multihop.net (8.12.8/8.12.8) with SMTP id h31HCqNE021803; Tue, 1 Apr 2003 09:12:53 -0800 (PST) (envelope-from tj@kniveton.com) Message-ID: <001701c2f872$c2b817c0$260fa8c0@mdht.com.ar> From: "TJ" To: "wlyu" Cc: References: <005901c2f85f$e7befbf0$7119190d@fish> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [nemo] RE: Comments on MRTP Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 1 Apr 2003 14:12:47 -0300 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: wlyu To: T.J. Kniveton Cc: Sent: Tuesday, April 01, 2003 12:03 PM Subject: Comments on MRTP > Hi T.j, > > >When the HA_MR receives the routing information from the mobile router > >through the bidirectional tunnel, it adds the corresponding routes to > >its routing table with the next hop set to the mobile router's address, > >in case of IPv6 MR's link local address. This next hop address is > >obtained from the source address of the inner packet. The HA_MR in > >turn propagates this information when it sends routing updates to other > >routers on the mobile router's home link. > > when HA_MR to do so, the bidirectional tunnel must have been setup > between MR and HA_MR, yes or no? I^m not sure I understand your question -- when the HA_MR does -what-, the tunnel must have been set up? > So when the MR moves to foreign link, it first acts as an normal MN to > interchange binding information with HA_MR, before the establishment of > tunnel, HA_MR can't receive routing information from MR. Yes, I agree with you. For the most part, the MR looks like a MN to the HA_MR (with some exceptions). So, when the MR moves, it does what any MN does on its uplink: first, establishes connectivity, then sends a binding update. Along with the BU, it will also change the routing for the mobile network, either explicitly or implicitly. > So, before the process is finished, MR can't serve the nodes behinds it ? Well it depends on what you mean by serve. In the same way a MN will have to buffer packets for its own applications during a handover (until connection is re-established), the MR will do the same for other nodes. But it should still have a connection on the mobile network link, and I would say that it is still serving those MNNs. > Maybe it's about implementation,but I still to ask the question:-) Yes, it{s about implementation - but in theory, it is very similar to other cases when a network link goes down and up again due to changing physical topology. > > Thanks a lot. > > Wanrong Yu Sure. -TJ From nemo-admin@nal.motlabs.com Tue Apr 1 12:41:12 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03142 for ; Tue, 1 Apr 2003 12:41:05 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h31Hd8RC013282; Tue, 1 Apr 2003 19:39:08 +0200 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h31HbqRC013270 for ; Tue, 1 Apr 2003 19:37:58 +0200 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h31Hbd4Z008549; Tue, 1 Apr 2003 10:37:39 -0700 (MST) Received: [from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id KAA24057; Tue, 1 Apr 2003 10:37:13 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h31HbYi03954; Tue, 1 Apr 2003 11:37:34 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 49AA32EC95; Tue, 1 Apr 2003 19:37:32 +0200 (CEST) Message-ID: <3E89CE5C.6010409@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: =?ISO-8859-1?Q?Pekka_=3D=3Fiso-8859-1=3FQ=3FP=E4=E4kk=F6nen=3F=3D?=, Ole Troan, , Subject: Re: [nemo] Link local addresses References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 01 Apr 2003 19:37:32 +0200 Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >> I would suppose that this is an issue of the link-local >> addressing of MR in general. The use of DHCPv6 is but one >> "link-local addressing" issue for MR. The other link-local >> addressing issues for MR come from the use of routing protocols >> between MR and HA; another link-local address issue is also the >> HA sending RA's to MR (or MH for that matter); yet another is >> from multicast MLD between MR and HA, that also uses link-local >> addressing. > > > What exists in MIPv6 is a prohbition from _forwarding_ packets with > link-local addresses out over the tunnel to the MN. I see, so it must be something related to the below rfc2460 text: "Routers must not forward any packets with link-local source or destination addresses to other links." I could better grasp it that way. Alex From nemo-admin@nal.motlabs.com Tue Apr 1 13:35:31 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07146 for ; Tue, 1 Apr 2003 13:35:26 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h31IWLRC013489; Tue, 1 Apr 2003 20:32:24 +0200 Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h31IVGRC013481 for ; Tue, 1 Apr 2003 20:31:19 +0200 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h31IUbUl003027; Tue, 1 Apr 2003 11:30:39 -0700 (MST) Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA11870; Tue, 1 Apr 2003 11:31:06 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h31IRqm18099; Tue, 1 Apr 2003 12:27:52 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 29AB32EC86; Tue, 1 Apr 2003 20:27:51 +0200 (CEST) Message-ID: <3E89DA26.4020202@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: =?ISO-8859-1?Q?Pekka_=3D=3Fiso-8859-1=3FQ=3FP=E4=E4kk=F6nen=3F=3D?=, Ole Troan, , Subject: Re: [nemo] Link local addresses References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 01 Apr 2003 20:27:50 +0200 Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > No, since this is in the context of intercepting packets destined > to the mobile node. The need for DHCPv6 etc is to be able to > _originate_ (not forward) packets on the tunnel link which uses > link-local addresses. When one considers that the HA and DHCP agent are co-located in one entity, then yes. If DHCP Agent is a relay, and HA is a one-interface machine (both connected on the home link) then the HA would need to "forward" link-local addressed packets, if the virtual link between HA and MR is torn down when MR at home, if I understand it correctly. > The formation of link-local addresses for tunnels is described in > RFC 2473. That sounds familiar, but I'm trying to find the formation of link-local addresses in rfc2473 and I can't? I know non-ether link-locals defined in rfc2529 (v6 over v4) and rfc2491 (v6 over NBMA). > Note that the MNs link-local address on the tunnel interface might > be different than the link-local address the MN has on its > non-tunnel interface when it is at home, but they might also be the > same. In any case it doesn't matter since the link-local addresses > only need to be unique per link and the tunnel is a different link > than the non-tunnel. A-ha, I see... >> I think HA could operate a DHCPv6 agent over the tunnel >> interface, but only when MN is not at home, right? > > > *If* there was a tunnel when the MN was at home it could oerate > DHCPv6 while at home. MIPv6 doesn't have a tunnel while at home. > Point is this is not an issue for DHCPv6 - it is an issue whether > the tunnel exists or not. If Nemo doesn't use a tunnel at home, > presumably DHCPv6 for prefix delegation could be used over the home > link. Ok, agreed here. > What's a BR? MR? Border Router? And DHCP can already have two > levels - a relay agent and a server. (or a chain of relays?) I was referring to BR as Border Router. Wondered if a configuration like this is supposed to be made to work ok (I draw real physical links only). ------ ---- / | Relay| | HA | / ------ ---- ----------/ | | ---- | | -------------------| BR |---| Internet | | ---- | | ---- ----- ----------\ | MR | | LFN | \ ---- ----- \ | | --------- Alex From nemo-admin@nal.motlabs.com Tue Apr 1 13:44:14 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07619 for ; Tue, 1 Apr 2003 13:44:13 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h31Ii3RC013548; Tue, 1 Apr 2003 20:44:03 +0200 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h31Ia3RC013505 for ; Tue, 1 Apr 2003 20:36:06 +0200 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h31IZf4c027384; Tue, 1 Apr 2003 10:35:41 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACU93978; Tue, 1 Apr 2003 10:35:39 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA16359; Tue, 1 Apr 2003 10:35:39 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16009.56315.651456.581279@thomasm-u1.cisco.com> To: William D Ivancic Cc: "Hesham Soliman (EAB)" , "'Erik Nordmark'" , "'Takeshi TANAKA'" , "'marcelo bagnulo'" , "'IETF NEMO'" Subject: RE: [nemo] about draft-ietf-nemo-requirements-00.txt In-Reply-To: <5.1.1.5.2.20030326153725.023edd08@popserve.grc.nasa.gov> References: <4DA6EA82906FD511BE2F00508BCF053807FEF774@Esealnt861.al.sw. ericsson.se> <5.1.1.5.2.20030326153725.023edd08@popserve.grc.nasa.gov> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 1 Apr 2003 10:35:39 -0800 (PST) Content-Transfer-Encoding: 7bit William D Ivancic writes: > At 05:38 PM 3/26/2003 +0100, Hesham Soliman (EAB) wrote: > > >My main concern was to accomodate the case where the two > >MRs belong to different HAs/ISPs/domains ...etc so that > >ingress filtering in the home network cannot be coordinated. > >In this case the benefit of multihoming is not redundancy, > >but potentially because the two MRs can provide different > >access characteristics (cellular, WLAN ...etc). They may also > >provide the same access but more than one happened to be available. > >I.e. load sharing on the MRs' egress interfaces. .... > > > >Hesham > > > Beware. For corporate networks, this appears to be a BIG BIG security issue. > > For instance, are you allowed to have you PC tied to the corporate network > while utilized a phone modem to an outside ISP? I am not asking if you CAN > do this. I am asking are you ALLOWED to do this. While this is a valid concern, it seems to me that this is mainly based off of an assumption that PC's, etc, on the "inside" are "trustworthy." Of course, this wasn't ever a very good assumption, but things are in motion to check it by way of VPN's at all the corporate edges and -- probably with more mindshare, unfortunately -- things like 802.1x. So, I suspect that we should trudge on here on the expectatation that wireless is going to turn those incorrect assumption upsidedown in time for this wg's relevancy... Mike From nemo-admin@nal.motlabs.com Wed Apr 2 09:42:20 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10821 for ; Wed, 2 Apr 2003 09:42:18 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h32EgIkF008417; Wed, 2 Apr 2003 16:42:21 +0200 Received: from ds20.nudt.edu.cn ([61.187.56.12]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h32Ef9kF008409 for ; Wed, 2 Apr 2003 16:41:16 +0200 Received: from fish (unknown [172.26.20.21]) by ds20.nudt.edu.cn (Postfix) with SMTP id 22EB25A1BE; Wed, 2 Apr 2003 22:43:53 +0800 (HKT) Message-ID: <001501c2f925$c4196520$7119190d@fish> From: "Wanrong Yu" To: "TJ" Cc: References: <005901c2f85f$e7befbf0$7119190d@fish> <001701c2f872$c2b817c0$260fa8c0@mdht.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by jessica.nal.motlabs.com id h32Ef9kF008409 Subject: [nemo] Re: Comments on MRTP Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 2 Apr 2003 22:40:11 +0800 Content-Transfer-Encoding: 8bit Hi T.j, > > > > >When the HA_MR receives the routing information from the mobile router > > >through the bidirectional tunnel, it adds the corresponding routes to > > >its routing table with the next hop set to the mobile router's address, > > >in case of IPv6 MR's link local address. This next hop address is > > >obtained from the source address of the inner packet. The HA_MR in > > >turn propagates this information when it sends routing updates to other > > >routers on the mobile router's home link. > > > > when HA_MR to do so, the bidirectional tunnel must have been setup > > between MR and HA_MR, yes or no? > > I^m not sure I understand your question -- when the HA_MR does -what-, the > tunnel must have been set up? Sorry for my vague expression. I jsut mean when HA_MR receives the routing information from the mobile router. Wanrong Yu From nemo-admin@nal.motlabs.com Fri Apr 4 04:24:08 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11932 for ; Fri, 4 Apr 2003 04:24:07 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h349MTT6023945; Fri, 4 Apr 2003 11:22:32 +0200 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h349L9T6023937; Fri, 4 Apr 2003 11:21:10 +0200 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id CAA00888; Fri, 4 Apr 2003 02:21:04 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h349L3S27409; Fri, 4 Apr 2003 11:21:03 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Link local addresses To: Alexandru Petrescu Cc: Erik Nordmark , =?iso-8859-1?Q?Pekka_=3D=3Fiso-8859-1=3FQ=3FP=E4=E4kk=F6nen=3F=3D?= , Ole Troan , nemo@nal.motlabs.com, rdroms@cisco.com In-Reply-To: "Your message with ID" <3E89DA26.4020202@nal.motlabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 4 Apr 2003 11:20:59 +0200 (CEST) > When one considers that the HA and DHCP agent are co-located in one > entity, then yes. If DHCP Agent is a relay, and HA is a one-interface > machine (both connected on the home link) then the HA would need to > "forward" link-local addressed packets, if the virtual link between HA > and MR is torn down when MR at home, if I understand it correctly. Why is that? If there is no tunnel when the MR is at home then the system needs to be designed so that the MR can perform DHCPv6 etc without necessarily going through the HA. For instance, it might go through some other DHCP relay. Example with one MR at home and another away: DHCP server | --------------- | | R1 R2 with DHCP relay | | home link -------------------------- | | HA with DHCP relay MR1 ! ! (tunnel to MR2) ! MR2 In this case the HA might be a DHCP relay on just the tunnels, or it might also be a DHCP relay on the home link. It wouldn't matter since in either case an MR would have DHCP service whether at home or away from home and the DUID would identify the MR so that it will get the same information (same prefixes) whether at home or not. No forwarding of IPv6 link-locals are needed for this. > That sounds familiar, but I'm trying to find the formation of > link-local addresses in rfc2473 and I can't? I know non-ether > link-locals defined in rfc2529 (v6 over v4) and rfc2491 (v6 over NBMA). Oops - I though RFC 2473 had the same type of language as IPv6 over PPP (use an IEEE MAC if you have one otherwise pick a random interface ID type stuff). Needs missing info to be fixed by IPv6 WG IMHO. > I was referring to BR as Border Router. Wondered if a configuration > like this is supposed to be made to work ok (I draw real physical > links only). > > > ------ ---- / > | Relay| | HA | / > ------ ---- ----------/ > | | ---- | | > -------------------| BR |---| Internet | > | ---- | | > ---- ----- ----------\ > | MR | | LFN | \ > ---- ----- \ > | | > --------- The way folks seem to be deploying IPv6 with prefix delegation is that the border router runs both a DHCP server (for the local domain) and a DHCP client (to request a prefix from the ISP). Thus the DHCP clients in the local domain communicate with the BR=DHCPv6 server and DHCP relays are only needed when there are routers inside the local domain. Erik From nemo-admin@nal.motlabs.com Fri Apr 4 12:46:32 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00861 for ; Fri, 4 Apr 2003 12:46:31 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h34HlBT6026065; Fri, 4 Apr 2003 19:47:13 +0200 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h34HkIT6026057 for ; Fri, 4 Apr 2003 19:46:19 +0200 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h34HkDaX011804; Fri, 4 Apr 2003 10:46:14 -0700 (MST) Received: [from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA08319; Fri, 4 Apr 2003 10:46:13 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h34GfP918597; Fri, 4 Apr 2003 10:41:25 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 5A4852EC8B; Fri, 4 Apr 2003 19:46:06 +0200 (CEST) Message-ID: <3E8DC4DE.3040301@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: =?ISO-8859-1?Q?Pekka_=3D=3Fiso-8859-1=3FQ=3FP=E4=E4kk=F6nen=3F=3D?=, Ole Troan, , Subject: Re: [nemo] Link local addresses References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 04 Apr 2003 19:46:06 +0200 Content-Transfer-Encoding: 7bit Erik, thank you for the clarifications... Erik Nordmark wrote: > It wouldn't matter since in either case an MR would have DHCP > service whether at home or away from home and the DUID would > identify the MR so that it will get the same information (same > prefixes) whether at home or not. No forwarding of IPv6 link-locals > are needed for this. Aha, DUID, so the discovery phase has already happened, so probably no need for ll's. > Oops - I though RFC 2473 had the same type of language as IPv6 over > PPP (use an IEEE MAC if you have one otherwise pick a random > interface ID type stuff). Ok, I must check that. > The way folks seem to be deploying IPv6 with prefix delegation is > that the border router runs both a DHCP server (for the local > domain) and a DHCP client (to request a prefix from the ISP). Thus > the DHCP clients in the local domain communicate with the BR=DHCPv > server and DHCP relays are only needed when there are router > inside the local domain. Aha, that's correct. The prefix delegation deployment types are indeed like that (or rather). If I have a network deployed at home and suddenly ISP says it gives me prefix delegation, I would prefer not to upgrade the existing CPE(?) but rather plug a new machine next to it. but that's debatable, sure. Alex GBU From nemo-admin@nal.motlabs.com Fri Apr 4 12:51:19 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01015 for ; Fri, 4 Apr 2003 12:51:18 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h34Hr2T6026097; Fri, 4 Apr 2003 19:53:02 +0200 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h34HldT6026066 for ; Fri, 4 Apr 2003 19:47:39 +0200 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h34HkgdQ011966; Fri, 4 Apr 2003 10:46:43 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h34HlYOq013115; Fri, 4 Apr 2003 11:47:35 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 3F9442EC8B; Fri, 4 Apr 2003 19:47:34 +0200 (CEST) Message-ID: <3E8DC536.2080907@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: nemo@nal.motlabs.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Mobile IPv6 and Link local addresses Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 04 Apr 2003 19:47:34 +0200 Content-Transfer-Encoding: 7bit Erik, regarding the previous mails on link-local addresses... Overall, it is not clear to me how Mobile IPv6 treats ll-addressed packets for a MH. First, it allows for packets inside the tunnel to have ll addresses, at least for DHCPv6 purposes (see citation [*] below)(rfc 2473 allows that too). Second, HA is allowed to intercept ll-addressed packets for an MH (L==1). Third, paradoxically to me, those intercepted ll-addressed packets are not allowed to be tunneled to the MH (see [**]). I suggest to allow those ll-addressed packets to be tunneled by HA towards MH. Pros: HA could be separated from DHCPv6 Agent (now Agent and HA must be co-located [***]) HA could be separated from the routers running OSPF (if NEMO looks later at an MR with OSPF, this would be useful). Cons: link-locals are no longer local, but that's ok, they're tunneled. I don't know whether this facilitates or not MLD. This might have already been discussed by the Mobile IP WG, I don't know. Maybe there is already a strong argument behind HA being forbidden to forward ll-addressed packets, I can live with it if it exists. What do you think? PS: How would DHCPv6 work if ll's were allowed to be tunneled, HA separated from DHCP Agent --------------------------------------------------------- The DHCPv6 discovery phase is made of 4 messages between host and Server, and might include 1+ intermediary Relays. The concern is about messages between host and first Relay (Solicit and Advertise). Those two messages use link-local addresses (src of Solicit is always ll, dst of Solicit is mc, src of Advertise relayed by Relay is presumably ll, dst of it is ll). Assume host is at home and talks to Relay in order to obtain a global address. Everything happens fine. Assume there is a HA next to Relay (but not in the same machine). Now assume host (MH) moves away from home, and reappears 10 days later under a new AR. In this case, the Solicit and Advertise messages will beencapsulated in the tunnel MH-HA. After receiving the Solicit, the Relay will send the corresponding Advertise to MH's ll address (MH home ll address). Then HA would intercept it and tunnel it to the CoA. draft 21 Mobile IPv6 citations ------------------------------ [*] "DHCPv6 messages sent to the mobile node with a link-local destination must be tunneled within the same tunnel header used for other packet flows." [**] when talking about HA intercepting packets: "However, packets addressed to the mobile node's link-local address MUST NOT be tunneled to the mobile node. Instead, such a packet MUST be discarded, and [...]" [***] "Mobile nodes desiring to locate a DHCPv6 service may reverse tunnel standard DHCPv6 packets to the home agent. Since these link-scope packets can not be forwarded onto the home network it is necessary for the home agent to either implement a DHCPv6 relay agent or a DHCPv6 server function itself." Alex GBU From nemo-admin@nal.motlabs.com Mon Apr 7 05:57:55 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13463 for ; Mon, 7 Apr 2003 05:57:53 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h379uQT6020304; Mon, 7 Apr 2003 11:56:27 +0200 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:3ffe:501:100c:d120::53]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h379teT6020296 for ; Mon, 7 Apr 2003 11:55:42 +0200 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id AB5935D00D for ; Mon, 7 Apr 2003 18:55:31 +0900 (JST) Message-Id: <20030407.185531.78816801.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com From: Thierry Ernst X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Apr__7_18:55:31_2003_321)--" Content-Transfer-Encoding: 7bit Subject: [nemo] Fw: [Seamoby] I-D ACTION:draft-ietf-seamoby-mobility-terminology-03.txt Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 07 Apr 2003 18:55:31 +0900 (JST) ----Next_Part(Mon_Apr__7_18:55:31_2003_321)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, The sections on mobile netwoks has been updated in the Seamoby terminology document (p 8). I will remove/update the NEMO terminology document respectively. Thierry ----Next_Part(Mon_Apr__7_18:55:31_2003_321)-- Content-Type: Message/Rfc822 Content-Disposition: inline Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id C8E115D0F0 for ; Fri, 4 Apr 2003 23:14:08 +0900 (JST) Received: from imap-serv.inrialpes.fr (imap-serv.inrialpes.fr [194.199.18.72]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id h34EE5x07373 for ; Fri, 4 Apr 2003 16:14:05 +0200 (MEST) Received: (from cyrus@localhost) by imap-serv.inrialpes.fr (8.11.6/8.11.3/ImagV2) id h34EE6c00650 for ernst@sfc.wide.ad.jp; Fri, 4 Apr 2003 16:14:06 +0200 (MEST) X-Authentication-Warning: imap-serv.inrialpes.fr: cyrus set sender to seamoby-admin@ietf.org using -f Received: from imap-serv ([unix socket]) by imap-serv (Cyrus v2.1.12) with LMTP; Fri, 04 Apr 2003 16:14:05 +0200 X-Sieve: CMU Sieve 2.2 Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by imap-serv.inrialpes.fr (8.11.6/8.11.3/ImagV2) with ESMTP id h34EE5F00638; Fri, 4 Apr 2003 16:14:05 +0200 (MEST) Received: from www1.ietf.org (ietf.org [132.151.1.19]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id h34EE3x07369; Fri, 4 Apr 2003 16:14:03 +0200 (MEST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34EE3K18770; Fri, 4 Apr 2003 09:14:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34BbbK04521 for ; Fri, 4 Apr 2003 06:37:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14622; Fri, 4 Apr 2003 06:34:22 -0500 (EST) Message-Id: <200304041134.GAA14622@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Fri, 04 Apr 2003 06:34:22 -0500 Subject: [Seamoby] I-D ACTION:draft-ietf-seamoby-mobility-terminology-03.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Mobility Related Terminology Author(s) : J. Manner, M. Kojo Filename : draft-ietf-seamoby-mobility-terminology-03.txt Pages : 32 Date : 2003-4-3 There is a need for common definitions of terminology in the work to be done around IP mobility. This memo defines terms for mobility related terminology. It is intended as a living document for use by the Seamoby Working Group in Seamoby drafts and in WG discussions, but not limited in scope to the terms needed by the Seamoby Working Group. Other working groups dealing with mobility may take advantage of this terminology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-mobility-terminology-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-seamoby-mobility-terminology-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-seamoby-mobility-terminology-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: <2003-4-4064909.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-mobility-terminology-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-mobility-terminology-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-4064909.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby ----Next_Part(Mon_Apr__7_18:55:31_2003_321)---- From nemo-admin@nal.motlabs.com Tue Apr 8 13:37:38 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23390 for ; Tue, 8 Apr 2003 13:37:35 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h38HWJlV003242; Tue, 8 Apr 2003 19:32:19 +0200 Received: from soleil.uvsq.fr (soleil.ipv6.uvsq.fr [IPv6:3ffe:304:119:24::1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h38HDslV003163 for ; Tue, 8 Apr 2003 19:13:56 +0200 Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by soleil.uvsq.fr (8.12.6/jtpda-5.4) with ESMTP id h38GvbI6062076 ; Tue, 8 Apr 2003 18:57:37 +0200 (CEST) Received: from BRUNE (brune.prism.uvsq.fr [193.51.25.132]) by guillotin.prism.uvsq.fr (8.11.4/jtpda-5.3.2) with SMTP id h38GuX128152 ; Tue, 8 Apr 2003 18:56:33 +0200 (MET DST) Message-ID: <06d001c2fdf1$e17daa10$841933c1@BRUNE> From: "Ahmed Mehaoua" To: Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , "\"Georg Carle\"" , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06CD_01C2FE02.914ABFE0" 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-Antivirus: scanned by sophie at soleil.uvsq.fr Subject: [nemo] CFP IEEE/IFIP Intern. Conference on Management of Multimedia Networks & Services 2003 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 8 Apr 2003 19:10:50 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_06CD_01C2FE02.914ABFE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Colleagues,=20 Apologize for any duplicates; ------------------------------------------------------------------- Please distribute to interested people to encourage contributions ans = submissions to the 6th IFIP/IEEE International Conference on Management = of Multimedia Networks and Services : 7th - 10th September 2003, Queen's University of Belfast, = Northern Ireland=20 http://www.ee.qub.ac.uk/mmns2003 . ------------------------------------------------------------------- Please note the extension to the deadline for submission of papers to = MMNS2003 is 18th April 2003. Please circulate to your colleagues to = ensure a good turnout. For further information about the conference please see the web site at = http://ee-server.ee.qub.ac.uk/dsp/mmns2003/ Best Regards, Ahmed Mehaoua (Publicity chair) = -------------------------------------------------------------------------= -------------------------------- MMNS 2003 6th IFIP/IEEE International Conference on Management of Multimedia = Networks and Services 7th - 10th September 2003, Queen's University of Belfast, = Northern Ireland=20 http://www.ee.qub.ac.uk/mmns2003=20 Second Call For Papers Multimedia services over IP networks are proliferating at an enormous = speed. There=20 is also increasing demand for solutions which provide assured levels of = service quality.=20 All of these require novel paradigms, models and architectures for = realising integrated=20 end-to-end service management rather than managing network elements in = isolation.=20 Providing scalable Quality of Service (QoS) while maintaining fairness, = along with=20 secure and optimal network resource management are key challenges for = the future=20 Internet. These challenges apply to both fixed and wireless networks.=20 The IFIP/IEEE International Conference on Management of Multimedia = Networks and Services=20 will hold its sixth annual meeting from September 7th to September 10th, = 2003 in Belfast, Northern Ireland. MMNS provides an intimate setting for discussion and = debate. In just 6 years,=20 MMNS has established itself as one of the premier conferences with a = focus on the management=20 of multimedia networks and services. The conference objective is to = bring together researchers=20 working in all facets of network and service management as applied to = broadband networks and=20 multimedia services. MMNS deals with all aspects of designing, = developing and deploying=20 networked multimedia systems and it serves as a forum for the = dissemination of state-of-the-art=20 research and development results.=20 MMNS 2003 will also include panel sessions in which experts=20 offer their observations and opinions about current hot topics. The = keynote speaker will be=20 Professor Ian Akyildiz, Georgia Institute of Technology who will present = a vision of future=20 interplanetary network architectures. Professor Derek McAuley, head of = Intel's recently formed=20 laboratory at Cambridge, UK, will describe some of the new research = being undertaken on global=20 overlay networks and applications. The program committee is soliciting original papers describing research = in the area of=20 management of multimedia networks and services. Topics of interest = include, but are not=20 limited to, the following: * Active multimedia network management=20 * Ad-hoc and Sensor Networks=20 * Augmented and Virtual Reality Networks=20 * Billing and Accounting=20 * Cable multimedia network management=20 * Content distribution internetworking=20 * Deployment of multimedia services=20 * Distributed multimedia service management=20 * End-to-end IP multimedia network and service management=20 * IP Video, streaming, interactive video service management=20 * Middleware support for management=20 * Multimedia network traffic engineering and optimization=20 * Multimedia traffic management=20 * Multimedia content protection=20 * Multimedia session management=20 * Multi-point, multicast services management=20 * Network management models and architectures=20 * Network programmability for multimedia services=20 * Optical multimedia network management=20 * Policy-based management for multi-media services=20 * Provisioning of multimedia networks and services=20 * QoS in WLANs=20 * QoS management=20 * Resource, performance and fault management=20 * Security and Authentication=20 * VoIP service management=20 * Web Services=20 * Wireless and mobile multimedia network management=20 Papers must be submitted electronically in postscript or PDF format. = Detailed=20 instructions are provided on the conference web site, = http://www.ee.qub.ac.uk/mmns2003.=20 Submission date: 18th April 2003 Notification of acceptance: 6th June 2003 Final version: 4th July 2003 Conference Chairs: Professor Alan Marshall, a.marshall@ee.qub.ac.uk, Queen's University = of Belfast, UK Professor Nazim Agoulmine, nazim@rp.lip6.fr, University of Evry, = France Qiang Gu Advanced Telecommunication Systems Laboratory School of Electrical & Electronic Engineering The Queen's University of Belfast Belfast Northern Ireland. BT9 5AH Email: qiang.gu@ee.qub.ac.uk Telephone: +44 -2890-274142 Fax: +44 -2890-274417 --------------------------------------------------------- Ahmed Mehaoua University of Versailles - CNRS PRISM Lab. 45 av. des etats unis 78000 Versailles - France Email : mea@prism.uvsq.fr Tel : +33 1 39 25 40 45 ------=_NextPart_000_06CD_01C2FE02.914ABFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Colleagues,
Apologize for any=20 duplicates;
 
----------------------------------------------------------------= ---

 Please=20 distribute to interested people to encourage contributions ans = submissions to=20 the 6th IFIP/IEEE International = Conference on=20 Management of Multimedia Networks and Services=20 :
        7th - 10th September = 2003,=20 Queen's University of Belfast, Northern Ireland=20
           &nb= sp;           &nbs= p;   =20 http://www.ee.qub.ac.uk/mmns200= 3=20 .
----------------------------------------------------------------= ---
Please note the extension to the = deadline for=20 submission of papers to MMNS2003 is 18th=20 April 2003. Please circulate to your colleagues to ensure a good=20 turnout.
 
For further information about the = conference please=20 see the web site at http://ee-server.ee.= qub.ac.uk/dsp/mmns2003/
 
Best Regards,
 
Ahmed Mehaoua
(Publicity chair)
 
 
 ----------------------------------------------------------= -----------------------------------------------
 
MMNS 2003
6th = IFIP/IEEE=20 International Conference on Management of Multimedia Networks and=20 Services
        7th - 10th = September=20 2003, Queen's University of Belfast, Northern Ireland=20
           &nb= sp;           &nbs= p;   =20 http://www.ee.qub.ac.uk/mmns200= 3=20
 

          &nbs= p;            = ;          =20 Second Call For Papers
 
Multimedia services over IP networks are proliferating at an = enormous=20 speed. There
is also increasing demand for solutions which provide = assured=20 levels of service quality.
All of these require novel paradigms, = models and=20 architectures for realising integrated
end-to-end service management = rather=20 than managing network elements in isolation.
Providing scalable = Quality of=20 Service (QoS) while maintaining fairness, along with
secure and = optimal=20 network resource management are key challenges for the future =
Internet.=20 These challenges apply to both fixed and wireless networks.
 
The IFIP/IEEE International Conference on Management of Multimedia = Networks=20 and Services
will hold its sixth annual meeting from September 7th = to=20 September 10th, 2003 in Belfast,
Northern Ireland. MMNS provides an = intimate=20 setting for discussion and debate. In just 6 years,
MMNS has = established=20 itself as one of the premier conferences with a focus on the management =
of=20 multimedia networks and services. The conference objective is to bring = together=20 researchers
working in all facets of network and service management = as=20 applied to broadband networks and
multimedia services. MMNS deals = with all=20 aspects of designing, developing and deploying
networked multimedia = systems=20 and it serves as a forum for the dissemination of state-of-the-art =
research=20 and development results.
 
MMNS 2003 will also include panel sessions in which experts =
offer their=20 observations and opinions about current hot topics. The keynote speaker = will be=20
Professor Ian Akyildiz, Georgia Institute of Technology who will = present a=20 vision of future
interplanetary network architectures. Professor = Derek=20 McAuley, head of Intel's recently formed
laboratory at Cambridge, = UK, will=20 describe some of the new research being undertaken on global
overlay = networks and applications.
 

The program committee is soliciting original papers describing = research=20 in the area of
management of multimedia networks and services. = Topics of=20 interest include, but are not
limited to, the following:
 
        * Active multimedia = network=20 management
        * Ad-hoc and = Sensor=20 Networks
        * Augmented and = Virtual=20 Reality Networks
        * = Billing and=20 Accounting
        * Cable = multimedia=20 network management
        * = Content=20 distribution internetworking =
        *=20 Deployment of multimedia services =
       =20 * Distributed multimedia service management=20
        * End-to-end IP = multimedia=20 network and service management =
        *=20 IP Video, streaming, interactive video service management=20
        * Middleware support for=20 management
        * Multimedia = network=20 traffic engineering and optimization=20
        * Multimedia traffic = management=20
        * Multimedia content = protection=20
        * Multimedia session = management=20
        * Multi-point, multicast = services=20 management
        * Network = management=20 models and architectures
        = *=20 Network programmability for multimedia services=20
        * Optical multimedia = network=20 management
        * Policy-based = management for multi-media services=20
        * Provisioning of = multimedia=20 networks and services
        * = QoS in=20 WLANs
        * QoS management=20
        * Resource, performance = and fault=20 management
        * Security and = Authentication
        * VoIP = service=20 management
        * Web Services =
        * Wireless and mobile = multimedia=20 network management
 

Papers must be submitted electronically in postscript or PDF = format.=20 Detailed
instructions are provided on the conference web site, http://www.ee.qub.ac.uk/mmns200= 3.=20
 
Submission=20 date:            = 18th=20 April 2003
Notification of acceptance: 6th June 2003
Final=20 version:           = ;  =20 4th July 2003
 
Conference Chairs:
   Professor Alan Marshall, a.marshall@ee.qub.ac.uk, = Queen=92s=20 University of Belfast, UK
   Professor Nazim Agoulmine, nazim@rp.lip6.fr, University of = Evry,=20 France
 
Qiang Gu
Advanced Telecommunication = Systems=20 Laboratory
School of Electrical & Electronic Engineering
The = Queen's=20 University of Belfast
Belfast
Northern Ireland.
BT9 = 5AH
Email: qiang.gu@ee.qub.ac.uk
Teleph= one: +44=20 -2890-274142
Fax: +44 -2890-274417
---------------------------------------------------------
Ahm= ed=20 Mehaoua
University of Versailles - CNRS PRISM Lab.
45 av. des = etats unis=20 78000 Versailles - France
Email : mea@prism.uvsq.fr
Tel : +33 1 = 39 25 40=20 45
 
 
------=_NextPart_000_06CD_01C2FE02.914ABFE0-- From nemo-admin@nal.motlabs.com Sat Apr 12 10:24:14 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28824 for ; Sat, 12 Apr 2003 10:24:12 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3CEPGFM030326; Sat, 12 Apr 2003 16:25:16 +0200 Received: from ds20.nudt.edu.cn ([61.187.56.12]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3CEOMFM030316 for ; Sat, 12 Apr 2003 16:24:27 +0200 Received: from fish (unknown [172.26.20.21]) by ds20.nudt.edu.cn (Postfix) with SMTP id 091155A8F4; Sat, 12 Apr 2003 22:27:19 +0800 (HKT) Message-ID: <002801c300ff$11864ae0$7119190d@x20809.sbjr.com> From: "Wanrong Yu" To: "TJ" Cc: References: <005901c2f85f$e7befbf0$7119190d@fish> <001701c2f872$c2b817c0$260fa8c0@mdht.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by jessica.nal.motlabs.com id h3CEOMFM030316 Subject: [nemo] Comments on Implicit Signaling in MRTP Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sat, 12 Apr 2003 22:23:20 +0800 Content-Transfer-Encoding: 8bit Hi T.j, Some comments again. >4.2. Implicit Signaling > In general, implicit signaling means that signaling is not necessary > because of the implication of other factors. When a mobile router sends > a binding update to its home agent, the home agent knows which prefixes > are assigned to the router, and it sets up the static route and begins > forwarding traffic to the mobile network. What will happen if the mobile router sends a binding update to its home agent -only- want itself to be regarded as a normal mobile node, not a mobile router? According to the draft, after receiving a binding update from a mobile router, the HA sets up the static routes belong to the mobile route automatically, so in the upper scenario, the HA does unnecessary work, wastes resources and may introduce new security problem. Does it a problem or i am just worry unnecessarily:-) Thanks a lot! Wanrong Yu From nemo-admin@nal.motlabs.com Tue Apr 15 09:07:30 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26364 for ; Tue, 15 Apr 2003 09:07:28 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3FD8CFM025578; Tue, 15 Apr 2003 15:08:13 +0200 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3FD7pFM025569 for ; Tue, 15 Apr 2003 15:07:52 +0200 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id C4CA36BA6E for ; Tue, 15 Apr 2003 09:07:44 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3FD7euW008053 for ; Tue, 15 Apr 2003 09:07:42 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (tb2-78.grc.nasa.gov [139.88.2.78]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h3FD7aYM013072 for ; Tue, 15 Apr 2003 09:07:39 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030415085911.0242eff8@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: nemo@nal.motlabs.com From: William D Ivancic Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] Multiple Home Networks Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 15 Apr 2003 09:07:39 -0400 While preparing for a talk I'm giving to the Aeronautical Internet Collaboration working group, I've been considering the various entities that may use a mobile network onboard an aircraft including: Air Traffic Control, the Airline maintenance, Airline Entertainment Services, etcetera. I believe each of these may desire to have their own Home Agent. I have not yet figured out how one secures such a system, however, I certainly see a potential to operate in this manner. The alternative it to have one Home Agent with various networks distributed from that point (does not exclude geographically distributed Home Agents provide by one ISP). I know how to secure this using IPv4, but it does restrict the architecture. Will From nemo-admin@nal.motlabs.com Tue Apr 15 15:19:44 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08791 for ; Tue, 15 Apr 2003 15:19:43 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3FJLBFM027241; Tue, 15 Apr 2003 21:21:11 +0200 Received: from mx7.thebiz.net (mx7.thebiz.net [216.238.0.27]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with SMTP id h3FJK1FM027227 for ; Tue, 15 Apr 2003 21:20:02 +0200 Received: (qmail 54454 invoked from network); 15 Apr 2003 15:19:41 -0400 Received: from unknown (172.16.0.80) by mx7.backend.thebiz.net with QMQP; 15 Apr 2003 15:19:41 -0400 Received: from unknown (HELO stu.critical.com) (216.230.224.199) by mail.borg.com with SMTP; 15 Apr 2003 15:19:40 -0400 Message-Id: <5.1.1.6.0.20030415145913.00a76de8@pop3.norton.antivirus> X-Sender: stu/mail.borg.com@pop3.norton.antivirus X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: nemo@nal.motlabs.com From: "Stuart W. Card" Subject: Re: [nemo] Multiple Home Networks Cc: William D Ivancic , dave.schroeder@critical.com, doug.owen@critical.com, Stephen Zabele In-Reply-To: <5.1.1.5.2.20030415085911.0242eff8@popserve.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 15 Apr 2003 15:19:03 -0400 At 09:07 AM 4/15/2003 -0400, William D Ivancic wrote: >While preparing for a talk I'm giving to the Aeronautical Internet >Collaboration working group, I've been considering the various entities >that may use a mobile network onboard an aircraft including: Air Traffic >Control, the Airline maintenance, Airline Entertainment >Services, etcetera. I believe each of these may desire to have their >own Home Agent... Interesting: the MR essentially becomes a mobile ISP POP, providing connectivity for multiple user groups, each of which has its own home network etc. The 'obvious' approach would be for the router directly attached to the egress links to be controlled not by any of the various user groups but rather by an ISP (I'm using strictly the denotation of the term here, not necessarily any of its usual connotations), and to have another tier of routers behind it, each acting as the MR for one particular user group. This approach would be costly (in several types of coin), complex and inflexible. So the next obvious possibility would be to consolidate the multiple MRs as 'virtual' MRs in a single box, which of course reduces (from a pure routing perspective) to a single router handling traffic not for a single prefix but rather a list of prefixes, which is commonplace in wireline networks. Issues appear limited to management and security, surprise. :-/ The case where this can be simplified by forcing all the user groups to share a common HA is a special one; I believe it would be worthwhile to seek a more general solution. Can partial trust relationships be defined, so that LFNs and HAs can decide whether or not to trust a 3rd party controlled MR to behave properly as such, without requiring any prior association and without implying any other form of trust? Can simple and cheap mechanisms be devised to detect (with few missed detections and few false alarms) whether the MR is living up to this trust? Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 www.critical.com From nemo-admin@nal.motlabs.com Tue Apr 15 16:13:40 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10117 for ; Tue, 15 Apr 2003 16:13:39 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3FKC2FM027452; Tue, 15 Apr 2003 22:12:02 +0200 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3FKBeFM027442 for ; Tue, 15 Apr 2003 22:11:41 +0200 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 1A17C689F3 for ; Tue, 15 Apr 2003 16:11:34 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3FKBVuW007495; Tue, 15 Apr 2003 16:11:31 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (tb2-78.grc.nasa.gov [139.88.2.78]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h3FKBPYM015159; Tue, 15 Apr 2003 16:11:25 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030415160654.02408948@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: "Stuart W. Card" From: William D Ivancic Subject: Re: [nemo] Multiple Home Networks Cc: nemo@nal.motlabs.com, dave.schroeder@critical.com, doug.owen@critical.com, Stephen Zabele In-Reply-To: <5.1.1.6.0.20030415145913.00a76de8@pop3.norton.antivirus> References: <5.1.1.5.2.20030415085911.0242eff8@popserve.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 15 Apr 2003 16:11:25 -0400 At 03:19 PM 4/15/2003 -0400, Stuart W. Card wrote: >At 09:07 AM 4/15/2003 -0400, William D Ivancic wrote: > >>While preparing for a talk I'm giving to the Aeronautical Internet >>Collaboration working group, I've been considering the various entities >>that may use a mobile network onboard an aircraft including: Air Traffic >>Control, the Airline maintenance, Airline Entertainment >>Services, etcetera. I believe each of these may desire to have their >>own Home Agent... > >Interesting: the MR essentially becomes a mobile ISP POP, >providing connectivity for multiple user groups, each of >which has its own home network etc. Exactly. This is one possible use. I think it may be a rather common use. Take you car for instance. You may have your personal ISP for surfing, downloading maps, VOIP. Then you may have the manufacturer who would like to access the vehicle for maintenance, preventative maintenance and software/firmware updates. Will From nemo-admin@nal.motlabs.com Tue Apr 15 17:03:51 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11809 for ; Tue, 15 Apr 2003 17:03:50 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3FL53FM027642; Tue, 15 Apr 2003 23:05:04 +0200 Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [IPv6:3ffe:501:100c:d210:2e0:18ff:fe98:936d] (may be forged)) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3FL4vFM027631 for ; Tue, 15 Apr 2003 23:04:59 +0200 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (luna.sfc.wide.ad.jp [203.178.143.62]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h3FL4gU7020833; Wed, 16 Apr 2003 06:04:42 +0900 Message-ID: From: Ryuji Wakikawa To: William.D.Ivancic@grc.nasa.gov Cc: stu@critical.com, nemo@nal.motlabs.com, dave.schroeder@critical.com, doug.owen@critical.com, stephen.zabele@alphatech.com Subject: Re: [nemo] Multiple Home Networks In-Reply-To: <5.1.1.5.2.20030415160654.02408948@popserve.grc.nasa.gov> References: <5.1.1.5.2.20030415085911.0242eff8@popserve.grc.nasa.gov> <5.1.1.6.0.20030415145913.00a76de8@pop3.norton.antivirus> <5.1.1.5.2.20030415160654.02408948@popserve.grc.nasa.gov> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 16 Apr 2003 05:59:25 +0900 Hello Will. At Tue, 15 Apr 2003 16:11:25 -0400, William D Ivancic wrote: > > At 03:19 PM 4/15/2003 -0400, Stuart W. Card wrote: > >At 09:07 AM 4/15/2003 -0400, William D Ivancic wrote: > > > >>While preparing for a talk I'm giving to the Aeronautical Internet > >>Collaboration working group, I've been considering the various entities > >>that may use a mobile network onboard an aircraft including: Air Traffic > >>Control, the Airline maintenance, Airline Entertainment > >>Services, etcetera. I believe each of these may desire to have their > >>own Home Agent... > > > >Interesting: the MR essentially becomes a mobile ISP POP, > >providing connectivity for multiple user groups, each of > >which has its own home network etc. > > > Exactly. This is one possible use. I think it may be a rather common > use. Take you car for instance. You may have your personal ISP for > surfing, downloading maps, VOIP. Then you may have the manufacturer who > would like to access the vehicle for maintenance, preventative maintenance > and software/firmware updates. Exactly. As far as I know, car companies consider this issue. They really want to divide operations of manufacturer's managed network and the other network which user can configure. The manufacture network must be completely secured and isolated. The possible idea is assignment different prefixes to each network. There are 4 choices to operate these prefixes such as: 1. single HA and single MR 2. single HA and multiple MR 3. multiple HA and single MR 4. multiple HA and multiple MR I think some company assumes No.4, because it is unforgivable that user configurable network affects any packets sent by the manufacture network regarding "control" such as traffic control, maintenance, and motion control. Furthermore, they also consider to use different egress interfaces for each networks. The system configuration may become complicated like multiple HA, MR, and egress interfaces... regards, ryuji From nemo-admin@nal.motlabs.com Wed Apr 16 10:56:45 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04682 for ; Wed, 16 Apr 2003 10:56:44 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3GEvFFM001963; Wed, 16 Apr 2003 16:57:16 +0200 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3GEuKFM001949 for ; Wed, 16 Apr 2003 16:56:26 +0200 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 41E246B9CF for ; Wed, 16 Apr 2003 10:56:00 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3GEtfuW027902; Wed, 16 Apr 2003 10:55:42 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (tb2-78.grc.nasa.gov [139.88.2.78]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h3GEtUYM027893; Wed, 16 Apr 2003 10:55:32 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030416105147.02405ef0@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Ryuji Wakikawa From: William D Ivancic Subject: Re: [nemo] Multiple Home Networks Cc: stu@critical.com, nemo@nal.motlabs.com, dave.schroeder@critical.com, doug.owen@critical.com, stephen.zabele@alphatech.com In-Reply-To: References: <5.1.1.5.2.20030415160654.02408948@popserve.grc.nasa.gov> <5.1.1.5.2.20030415085911.0242eff8@popserve.grc.nasa.gov> <5.1.1.6.0.20030415145913.00a76de8@pop3.norton.antivirus> <5.1.1.5.2.20030415160654.02408948@popserve.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 16 Apr 2003 10:55:26 -0400 > >Exactly. As far as I know, car companies consider this issue. They >really want to divide operations of manufacturer's managed network >and the other network which user can configure. The manufacture >network must be completely secured and isolated. > >The possible idea is assignment different prefixes to each network. >There are 4 choices to operate these prefixes such as: > >1. single HA and single MR >2. single HA and multiple MR >3. multiple HA and single MR >4. multiple HA and multiple MR > >I think some company assumes No.4, because it is unforgivable that user >configurable network affects any packets sent by the manufacture network >regarding "control" such as traffic control, maintenance, and motion >control. No. 4 is easiest to handle security wise, but number 3 is most cost effective. No. 3 allows one to share the RF links. No. 4 probably does not as (IMHO) the idea behind N0. 4 is to keep the networks completely separate. We just have to figure out how to secure No. 3 and prove to the end users that this is acceptable. Will From nemo-admin@nal.motlabs.com Fri Apr 18 07:42:28 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10166 for ; Fri, 18 Apr 2003 07:42:26 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3IBhFFM018783; Fri, 18 Apr 2003 13:43:15 +0200 Received: from soleil.uvsq.fr (root@soleil.uvsq.fr [193.51.24.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3IAngFM018356 for ; Fri, 18 Apr 2003 12:49:42 +0200 Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by soleil.uvsq.fr (8.12.8p1/jtpda-5.4) with ESMTP id h3IAd09Y099065 ; Fri, 18 Apr 2003 12:39:02 +0200 (CEST) Received: from BRUNE (brune.prism.uvsq.fr [193.51.25.132]) by guillotin.prism.uvsq.fr (8.11.4/jtpda-5.3.2) with SMTP id h3IAOM104226 ; Fri, 18 Apr 2003 12:24:22 +0200 (MET DST) Message-ID: <102e01c30597$81fbf6c0$841933c1@BRUNE> From: "Ahmed Mehaoua" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1029_01C305A7.66886D00" 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-Antivirus: scanned by sophie at soleil.uvsq.fr Subject: [nemo] Fw: CFP IEEE/IFIP Intern. Conference on Management of Multimedia Networks & Services 2003 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 18 Apr 2003 12:38:23 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_1029_01C305A7.66886D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Colleagues,=20 /* PLEASE APOLOGIZE IF YOU RECEIVE MULTIPLE COPIES OF THIS ANNOUNCEMENT = * / /* LAST DAYS FOR ARTICLE SUBMISSIONS TO IFIP/IEEE MMNS 2003 /* THE SUBMISSION DEADLINE IS 18th APRIL 2003 */ Best Regards A. Mehaoua (Univ. of Versailles) ------------------------------------------------------------------- Please distribute to interested people to encourage contributions and = submissions to MMNS 2003 6th IFIP/IEEE International Conference on Management of Multimedia = Networks and Services 7th - 10th September 2003, Queen's University of Belfast, = Northern Ireland=20 http://www.ee.qub.ac.uk/mmns2003=20 Second Call For Papers Multimedia services over IP networks are proliferating at an enormous = speed. There=20 is also increasing demand for solutions which provide assured levels of = service quality.=20 All of these require novel paradigms, models and architectures for = realising integrated=20 end-to-end service management rather than managing network elements in = isolation.=20 Providing scalable Quality of Service (QoS) while maintaining fairness, = along with=20 secure and optimal network resource management are key challenges for = the future=20 Internet. These challenges apply to both fixed and wireless networks.=20 The IFIP/IEEE International Conference on Management of Multimedia = Networks and Services=20 will hold its sixth annual meeting from September 7th to September 10th, = 2003 in Belfast, Northern Ireland. MMNS provides an intimate setting for discussion and = debate. In just 6 years,=20 MMNS has established itself as one of the premier conferences with a = focus on the management=20 of multimedia networks and services. The conference objective is to = bring together researchers=20 working in all facets of network and service management as applied to = broadband networks and=20 multimedia services. MMNS deals with all aspects of designing, = developing and deploying=20 networked multimedia systems and it serves as a forum for the = dissemination of state-of-the-art=20 research and development results.=20 MMNS 2003 will also include panel sessions in which experts=20 offer their observations and opinions about current hot topics. The = keynote speaker will be=20 Professor Ian Akyildiz, Georgia Institute of Technology who will present = a vision of future=20 interplanetary network architectures. Professor Derek McAuley, head of = Intel's recently formed=20 laboratory at Cambridge, UK, will describe some of the new research = being undertaken on global=20 overlay networks and applications. The program committee is soliciting original papers describing research = in the area of=20 management of multimedia networks and services. Topics of interest = include, but are not=20 limited to, the following: * Active multimedia network management=20 * Ad-hoc and Sensor Networks=20 * Augmented and Virtual Reality Networks=20 * Billing and Accounting=20 * Cable multimedia network management=20 * Content distribution internetworking=20 * Deployment of multimedia services=20 * Distributed multimedia service management=20 * End-to-end IP multimedia network and service management=20 * IP Video, streaming, interactive video service management=20 * Middleware support for management=20 * Multimedia network traffic engineering and optimization=20 * Multimedia traffic management=20 * Multimedia content protection=20 * Multimedia session management=20 * Multi-point, multicast services management=20 * Network management models and architectures=20 * Network programmability for multimedia services=20 * Optical multimedia network management=20 * Policy-based management for multi-media services=20 * Provisioning of multimedia networks and services=20 * QoS in WLANs=20 * QoS management=20 * Resource, performance and fault management=20 * Security and Authentication=20 * VoIP service management=20 * Web Services=20 * Wireless and mobile multimedia network management=20 Papers must be submitted electronically in postscript or PDF format. = Detailed=20 instructions are provided on the conference web site, = http://www.ee.qub.ac.uk/mmns2003.=20 Submission date: 18th April 2003 Notification of acceptance: 6th June 2003 Final version: 4th July 2003 Conference Chairs: Professor Alan Marshall, a.marshall@ee.qub.ac.uk, Queen's University = of Belfast, UK Professor Nazim Agoulmine, nazim@rp.lip6.fr, University of Evry, = France ------=_NextPart_000_1029_01C305A7.66886D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Colleagues,
/* PLEASE APOLOGIZE IF YOU RECEIVE = MULTIPLE COPIES=20 OF THIS ANNOUNCEMENT * /
/*  LAST DAYS FOR ARTICLE = SUBMISSIONS TO=20 IFIP/IEEE MMNS 2003
/* THE SUBMISSION DEADLINE IS = 18th APRIL=20 2003 */
Best Regards
A. Mehaoua (Univ. of=20 Versailles)

----------------------------------------------------------------= ---

 Please=20 distribute to interested people to encourage contributions and = submissions to=20 MMNS=20 2003
6th IFIP/IEEE International Conference on Management of = Multimedia Networks and = Services
       =20 7th - 10th September 2003, Queen's University of Belfast, Northern = Ireland=20
           &nb= sp;           &nbs= p;   =20 http://www.ee.qub.ac.uk/mmns2003=20
 

          =             &= nbsp;          =20 Second Call For Papers
 
Multimedia services over IP networks = are=20 proliferating at an enormous speed. There
is also increasing demand = for=20 solutions which provide assured levels of service quality.
All of = these=20 require novel paradigms, models and architectures for realising = integrated=20
end-to-end service management rather than managing network elements = in=20 isolation.
Providing scalable Quality of Service (QoS) while = maintaining=20 fairness, along with
secure and optimal network resource management = are key=20 challenges for the future
Internet. These challenges apply to both = fixed and=20 wireless networks.
 
The IFIP/IEEE International Conference = on=20 Management of Multimedia Networks and Services
will hold its sixth = annual=20 meeting from September 7th to September 10th, 2003 in = Belfast,
Northern=20 Ireland. MMNS provides an intimate setting for discussion and debate. In = just 6=20 years,
MMNS has established itself as one of the premier conferences = with a=20 focus on the management
of multimedia networks and services. The = conference=20 objective is to bring together researchers
working in all facets of = network=20 and service management as applied to broadband networks and =
multimedia=20 services. MMNS deals with all aspects of designing, developing and = deploying=20
networked multimedia systems and it serves as a forum for the = dissemination=20 of state-of-the-art
research and development results.
 
MMNS 2003 will also include panel = sessions in which=20 experts
offer their observations and opinions about current hot = topics. The=20 keynote speaker will be
Professor Ian Akyildiz, Georgia Institute of = Technology who will present a vision of future
interplanetary = network=20 architectures. Professor Derek McAuley, head of Intel's recently formed=20
laboratory at Cambridge, UK, will describe some of the new research = being=20 undertaken on global
overlay networks and applications.
 

The program committee is soliciting = original=20 papers describing research in the area of
management of multimedia = networks=20 and services. Topics of interest include, but are not
limited to, = the=20 following:
 
        * Active=20 multimedia network management =
        *=20 Ad-hoc and Sensor Networks =
        *=20 Augmented and Virtual Reality Networks=20
        * Billing and Accounting=20
        * Cable multimedia = network=20 management
        * Content = distribution=20 internetworking
        * = Deployment of=20 multimedia services
        * = Distributed=20 multimedia service management =
        *=20 End-to-end IP multimedia network and service management=20
        * IP Video, streaming,=20 interactive video service management=20
        * Middleware support for=20 management
        * Multimedia = network=20 traffic engineering and optimization=20
        * Multimedia traffic = management=20
        * Multimedia content = protection=20
        * Multimedia session = management=20
        * Multi-point, multicast = services=20 management
        * Network = management=20 models and architectures
        = *=20 Network programmability for multimedia services=20
        * Optical multimedia = network=20 management
        * Policy-based = management for multi-media services=20
        * Provisioning of = multimedia=20 networks and services
        * = QoS in=20 WLANs
        * QoS management=20
        * Resource, performance = and fault=20 management
        * Security and = Authentication
        * VoIP = service=20 management
        * Web Services =
        * Wireless and mobile = multimedia=20 network management
 

Papers must be submitted = electronically in=20 postscript or PDF format. Detailed
instructions are provided on the=20 conference web site, http://www.ee.qub.ac.uk/mmns2003.
 
Submission=20 date:            18th April 2003
Notification of acceptance: = 6th June=20 2003
Final=20 version:           = ;  =20 4th July 2003
 
Conference Chairs:
   = Professor Alan=20 Marshall, a.marshall@ee.qub.ac.uk, = Queen=92s=20 University of Belfast, UK
   Professor Nazim Agoulmine, = nazim@rp.lip6.fr, = University of Evry,=20 France
 
------=_NextPart_000_1029_01C305A7.66886D00-- From nemo-admin@nal.motlabs.com Fri Apr 18 09:06:21 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12434 for ; Fri, 18 Apr 2003 09:06:20 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3ID83FM019463; Fri, 18 Apr 2003 15:08:03 +0200 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3ID7bFM019455; Fri, 18 Apr 2003 15:07:38 +0200 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA18161; Mon, 7 Apr 2003 15:58:11 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h37MvwS07110; Tue, 8 Apr 2003 00:57:59 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Link local addresses To: Alexandru Petrescu Cc: Erik Nordmark , =?iso-8859-1?Q?Pekka_=3D=3Fiso-8859-1=3FQ=3FP=E4=E4kk=F6nen=3F=3D?= , Ole Troan , nemo@nal.motlabs.com, rdroms@cisco.com In-Reply-To: "Your message with ID" <3E8DC4DE.3040301@nal.motlabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 7 Apr 2003 23:18:06 +0200 (CEST) > Aha, DUID, so the discovery phase has already happened, so probably no > need for ll's. I can't parse. A client can form a DUID without any communication. See draft-ietf-dhc-dhcpv6-28.txt secion 8. Erik From nemo-admin@nal.motlabs.com Sat Apr 19 14:27:16 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28986 for ; Sat, 19 Apr 2003 14:27:14 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3JIBPFM005512; Sat, 19 Apr 2003 20:11:25 +0200 Received: from multihop.net ([192.103.16.205]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3JIA2FM005483 for ; Sat, 19 Apr 2003 20:10:03 +0200 Received: from [64.36.73.242] (homegw.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.8) with ESMTP id h3JI9sGi005492; Sat, 19 Apr 2003 11:10:00 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 From: "T.J. Kniveton" To: Wanrong Yu CC: Message-ID: In-Reply-To: <002801c300ff$11864ae0$7119190d@x20809.sbjr.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [nemo] Re: Comments on Implicit Signaling in MRTP Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sat, 19 Apr 2003 11:09:52 -0700 Content-Transfer-Encoding: 7bit Hi, I was on vacation when you wrote this; now I'm back. On 4/12/03 7:23 AM, "Wanrong Yu" wrote: > Hi T.j, > > Some comments again. > >> 4.2. Implicit Signaling > >> In general, implicit signaling means that signaling is not necessary >> because of the implication of other factors. When a mobile router >> sends >> a binding update to its home agent, the home agent knows which prefixes >> are assigned to the router, and it sets up the static route and begins >> forwarding traffic to the mobile network. > > What will happen if the mobile router sends a binding update to its home > agent > -only- want itself to be regarded as a normal mobile node, not a mobile > router? > > According to the draft, after receiving a binding update from a mobile > router, > the HA sets up the static routes belong to the mobile route automatically, > so in the upper scenario, the HA does unnecessary work, wastes resources > and may introduce new security problem. > > Does it a problem or i am just worry unnecessarily:-) Well, I would say that's the price you pay if you want to use implicit signaling: the MR is implicitly assumed to be a MR. I wouldn't say that it's a lot of work to set up a route in the HA, relative to all the work it must do to complete a home registration. What is the security problem you have in mind? TJ From nemo-admin@nal.motlabs.com Mon Apr 21 21:49:39 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11777 for ; Mon, 21 Apr 2003 21:49:38 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3M1oDFM027556; Tue, 22 Apr 2003 03:50:14 +0200 Received: from ds20.nudt.edu.cn ([61.187.56.12]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3M1nIFM027544 for ; Tue, 22 Apr 2003 03:49:25 +0200 Received: from fish (unknown [172.26.20.21]) by ds20.nudt.edu.cn (Postfix) with SMTP id 549585A79B; Tue, 22 Apr 2003 09:52:28 +0800 (HKT) Message-ID: <001001c30871$3b22aa00$7119190d@x20809.sbjr.com> From: "Wanrong Yu" To: "T.J. Kniveton" Cc: References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by jessica.nal.motlabs.com id h3M1nIFM027544 Subject: [nemo] Re: Comments on Implicit Signaling in MRTP Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 22 Apr 2003 09:48:10 +0800 Content-Transfer-Encoding: 8bit Hi, TJ > Well, I would say that's the price you pay if you want to use implicit > signaling: the MR is implicitly assumed to be a MR. I wouldn't say that it's > a lot of work to set up a route in the HA, relative to all the work it must > do to complete a home registration. Oh, I see. You mean we should use explicit signaling as more as possible. > What is the security problem you have in mind? I don't have detailed examples in my mind. I just think it is dangerous that the MR does things unnecessary, for I am affrightted by Distributed Denial of Service(DDoS) and I am afraid that maybe the same thing will happen to MR , hehe. Now I think it is not a serious problem, maybe not a problem at all! Wanrong Yu From nemo-admin@nal.motlabs.com Tue Apr 22 20:44:14 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02750 for ; Tue, 22 Apr 2003 20:44:12 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3N0jCFM023735; Wed, 23 Apr 2003 02:45:13 +0200 Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3N0hxFM023717 for ; Wed, 23 Apr 2003 02:44:00 +0200 Subject: Re: [nemo] Multiple Home Networks From: Alper Yegin To: William D Ivancic , Ryuji Wakikawa CC: , , , , Message-ID: In-Reply-To: <5.1.1.5.2.20030416105147.02405ef0@popserve.grc.nasa.gov> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 22 Apr 2003 17:44:11 -0700 Content-Transfer-Encoding: 7bit >> 1. single HA and single MR >> 2. single HA and multiple MR >> 3. multiple HA and single MR >> 4. multiple HA and multiple MR >> >> I think some company assumes No.4, because it is unforgivable that user >> configurable network affects any packets sent by the manufacture network >> regarding "control" such as traffic control, maintenance, and motion >> control. > > > No. 4 is easiest to handle security wise, but number 3 is most cost > effective. No. 3 allows one to share the RF links. No. 4 probably does > not as (IMHO) the idea behind N0. 4 is to keep the networks completely > separate. > > We just have to figure out how to secure No. 3 and prove to the end users > that this is acceptable. From security perspective, I think #3 and #4 are not as different. An MR in #3 can have multiple physical interfaces on the NEMO side and hence able to physically separate prefixes and the hosts using them. Alper From nemo-admin@nal.motlabs.com Wed Apr 23 04:41:17 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07776 for ; Wed, 23 Apr 2003 04:41:12 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3N8edFM029643; Wed, 23 Apr 2003 10:40:45 +0200 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3N8dtFM029626 for ; Wed, 23 Apr 2003 10:39:57 +0200 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 23 Apr 2003 10:39:42 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3N8bo2R019546 for ; Wed, 23 Apr 2003 10:37:56 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 23 Apr 2003 10:38:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [nemo] Multiple Egress vs multihoming Message-ID: Thread-Topic: [nemo] Multiple Egress vs multihoming Thread-Index: AcMFVmArpXluoxENSUyue2vb2zx48gAHpwSgAPzuuUA= From: "Pascal Thubert (pthubert)" To: "IETF NEMO" X-OriginalArrivalTime: 23 Apr 2003 08:38:50.0991 (UTC) FILETIME=[C3F37FF0:01C30973] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h3N8dtFM029626 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 23 Apr 2003 09:38:50 +0100 Content-Transfer-Encoding: 8bit In the v 00 of the requirements, Thierry had the multihoming included. This was discussed at the WG and you'll find the summary at http://www.nal.motlabs.com/nemo/ietf56/chat-ietf56.txt Since the requirement draft is the base for the design, I suggest we finalize that one first, what do you think? I understand that r16 is gone, so is r14.4. As of multihoming, I understand that we would give names to specific situation, multihoming being a catch all. Now, if you look at this requirement: R13.1: The solution MUST support mobile networks with multiple MRs, I understand it as one mobile prefix owned by several MRs, considering the problems Erik raised otherwise. Say we have 2 MRs, MR1 and MR2. If there's no coordination between the 2, they may register to 2 different HAs. One of them may be at home and not the other. This impacts the choice of routing model between the HA and the MR. We have 3 approaches: - static: a static route in the HA(s) to the mobile profix via the MR home address. Implicit in all drafts. ->If we use static, then the 2 MRs have to have the same home address or to be both available at all time, because the HA will distribute the packets over the available static routes. If they have the same Home address, then the model is close to one MR, multiple careof (multiple interfaces), as long as the 2 MRs register to the same Home Agent. In case of DHAAD, this requires coordination between the MRs. - dynamic: MR tells HA about the mobile prefix. Present in Ryuji's and TJ's draft. -> Dynamic should work. But if one MR is at home and not the other, the redistribution model must be studied. Note that there's no requirement for home coming in version 00 of the draft. But that we were close to reach a consensus that this model is not part of basic Nemo. Do we want to open Pendora's box? - delegation: HA tells MR about the mobile prefix. MR installs the prefix. Present in Pekka's draft, and should be working using DHCP-PD on MRHA as well. -> Delegation must be extended to let the DHCP server know that those 2 MRs are paired. Again, this is not supposed to be addressed in basic Nemo. All this to say that in my humble view, dynamic will be the enabler for R13.1. As a consequence, I believe that this requirement should be delayed and not part of basic Nemo. What do you think? Pascal From nemo-admin@nal.motlabs.com Wed Apr 23 06:15:17 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10009 for ; Wed, 23 Apr 2003 06:15:14 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3NAEbFM030355; Wed, 23 Apr 2003 12:14:40 +0200 Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3NADTFM030347 for ; Wed, 23 Apr 2003 12:13:32 +0200 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h3NA6KD25623; Wed, 23 Apr 2003 18:06:20 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 73E2F10E8881; Wed, 23 Apr 2003 18:37:16 +0800 (SGT) Subject: Re: [nemo] Multiple Egress vs multihoming From: Chan-Wah Ng To: Pascal "Thubert (pthubert)" Cc: IETF NEMO In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1051094236.1698.38.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3- Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 23 Apr 2003 18:37:16 +0800 Content-Transfer-Encoding: 7bit Hello Pascal, On Wed, 2003-04-23 at 16:38, Pascal Thubert (pthubert) wrote: > In the v 00 of the requirements, Thierry had the multihoming included. > This was discussed at the WG and you'll find the summary at > http://www.nal.motlabs.com/nemo/ietf56/chat-ietf56.txt > > Since the requirement draft is the base for the design, I suggest we > finalize that one first, what do you think? > > I understand that r16 is gone, so is r14.4. As of multihoming, I > understand that we would give names to specific situation, multihoming > being a catch all. > > Now, if you look at this requirement: > > R13.1: The solution MUST support mobile networks with multiple > MRs, > > I understand it as one mobile prefix owned by several MRs, considering > the problems Erik raised otherwise. > > Say we have 2 MRs, MR1 and MR2. If there's no coordination between the > 2, they may register to 2 different HAs. > One of them may be at home and not the other. > > This impacts the choice of routing model between the HA and the MR. We > have 3 approaches: > > - static: a static route in the HA(s) to the mobile profix via the MR > home address. Implicit in all drafts. > ->If we use static, then the 2 MRs have to have the same home address or > to be both available at all time, because the HA will distribute the > packets over the available static routes. If they have the same Home > address, then the model is close to one MR, multiple careof (multiple > interfaces), as long as the 2 MRs register to the same Home Agent. In > case of DHAAD, this requires coordination between the MRs. > > - dynamic: MR tells HA about the mobile prefix. Present in Ryuji's and > TJ's draft. > -> Dynamic should work. But if one MR is at home and not the other, the > redistribution model must be studied. Note that there's no requirement > for home coming in version 00 of the draft. But that we were close to > reach a consensus that this model is not part of basic Nemo. Do we want > to open Pendora's box? > > - delegation: HA tells MR about the mobile prefix. MR installs the > prefix. Present in Pekka's draft, and should be working using DHCP-PD on > MRHA as well. > -> Delegation must be extended to let the DHCP server know that those 2 > MRs are paired. Again, this is not supposed to be addressed in basic > Nemo. > > > All this to say that in my humble view, dynamic will be the enabler for > R13.1. As a consequence, I believe that this requirement should be > delayed and not part of basic Nemo. What do you think? > I beg to differ. Requirement 13.1 does not equate to "Multiple MRs with different HAs advertising same prefix". Why in the first place would two MR choose to advertise the same network prefix if they does not belong to the same administration domain? For static: Why would we require both MR to be on at the same time? If one MR is down, its corresponding HA will not receive any BU from that MR, and thus cannot establish a route to that MR. Hence it will respond to any packet that is destined to the mobile prefix with a ICMP destination unreachable or ICMP redirect messgae. Just as in the case of w non-mobile, multiple router scenario. In addition, I don't understand why DHAAD would require co-ordination of both MRs, unless you are saying the two MR must discover the same HA. Question then is why? -- Chan-Wah Ng Panasonic Singapore Laboratories From nemo-admin@nal.motlabs.com Wed Apr 23 08:17:29 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15046 for ; Wed, 23 Apr 2003 08:17:25 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3NCH7FM031035; Wed, 23 Apr 2003 14:17:09 +0200 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3NCG8FM031023 for ; Wed, 23 Apr 2003 14:16:10 +0200 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 23 Apr 2003 14:15:54 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3NCE3Ad001491; Wed, 23 Apr 2003 14:14:06 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 23 Apr 2003 14:15:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] Multiple Egress vs multihoming Message-ID: Thread-Topic: [nemo] Multiple Egress vs multihoming Thread-Index: AcMJgUJdyTJ9ePQwQvmGtgTJ/pVH5wADTJiA From: "Pascal Thubert (pthubert)" To: "Chan-Wah Ng" Cc: "IETF NEMO" X-OriginalArrivalTime: 23 Apr 2003 12:15:50.0525 (UTC) FILETIME=[1432BAD0:01C30992] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h3NCG8FM031023 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 23 Apr 2003 13:15:50 +0100 Content-Transfer-Encoding: 8bit Hi Chan-Wah > I beg to differ. Requirement 13.1 does not equate to > "Multiple MRs with different HAs advertising same prefix". > Why in the first place would two MR choose to advertise the > same network prefix if they does not belong to the same > administration domain? It's one way of being multihomed. You have a mobile network in a train. One prefix. But you want redundancy (load sharing?) so you serve it by not 1 but 2 MRs. They share the same home network. But may end up on different HAs if DHAAD is being used or of configured that way. That was my understanding of the requirement. But I agree it can be understood differently; IMHO, we should build a clear taxonomy of all cases (I mean list them, and name them). And then see what we keep for basic nemo. > > For static: > Why would we require both MR to be on at the same time? If > one MR is down, its corresponding HA will not receive any BU > from that MR, and thus cannot establish a route to that MR. > Hence it will respond to any packet that is destined to the > mobile prefix with a ICMP destination unreachable or ICMP > redirect messgae. Just as in the case of w non-mobile, > multiple router scenario. > Say you have one prefix, P, and 2 MRs, with home address A1 and A2, respectively The static routes in the HA look like "ipv6 route P A1" and "ipv6 route P A2" meaning that P is reachable via either MR at equal cost. Static Route are permanent things. The routes are always there. Including if the MR is at home, or power off. This is no big deal if there's a single MR. If it's joinable (home or registered), you'll get to P. If not, since there's no alternate path to P, there's no harm having the route. This keeps the routing protocols quiet and allows for a large number of MRs/movements. This is the way things happen unless you add a dynamicity like the MR exposes itself when at home, and the HA exposes the MR when the MR is registered. But this is not static routes anymore (I guess it's the model you have in mind). If you have 2 MRs, and 2 real static routes of equal cost, the router behaviour is a round robin traffic splitting, unless you add policies to the picture. If the HA has static routes to the mobile network via two MRs, and only one is reachable, half of the packets are dropped. Now, it's a pain. > In addition, I don't understand why DHAAD would require > co-ordination of both MRs, unless you are saying the two MR > must discover the same HA. > Question then is why? > That's if they register the same home address. This allows to have a single static route and alleviates the problem mentioned above. But then, even if we create a support for multiple careofs, you still have to have them on a single home agent, because of DAD. Unless you create a new coordication between HAs. Anyway, you see that this leads us into complex grounds (much more then other items we dropped in order to release a quick spec for basic :) Pendora's box. Pascal From nemo-admin@nal.motlabs.com Wed Apr 23 12:56:39 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26014 for ; Wed, 23 Apr 2003 12:56:37 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3NGvBFM032450; Wed, 23 Apr 2003 18:57:11 +0200 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3NGuBFM032441 for ; Wed, 23 Apr 2003 18:56:12 +0200 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h3NGoVnH003893; Wed, 23 Apr 2003 09:50:31 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h3NGoQM5007374; Wed, 23 Apr 2003 11:50:28 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1BEC12EC86; Wed, 23 Apr 2003 18:50:26 +0200 (CEST) Message-ID: <3EA6C451.6080508@nal.motlabs.com> From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: =?ISO-8859-1?Q?Pekka_=3D=3Fiso-8859-1=3FQ=3FP=E4=E4kk=F6nen=3F=3D?= , Ole Troan , nemo@nal.motlabs.com, rdroms@cisco.com Subject: Re: [nemo] Link local addresses References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 23 Apr 2003 18:50:25 +0200 Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >> Aha, DUID, so the discovery phase has already happened, so probably >> no need for ll's. > > > I can't parse. A client can form a DUID without any communication. > See draft-ietf-dhc-dhcpv6-28.txt secion 8. Right. I've made the assumption that you mentioned DUID to indicate that server identifies host by DUID, and that ll addresses were not involved. But I was referring specifically to messages that have as source or destination the ll addresses of the host. It would be nice if those messages were tunneled freely back and forth between MN and HA. For example, the Mobile IPv6 spec says: "However, packets addressed to the mobile node's link-local address MUST NOT be tunneled to the mobile node." Later on it says: "Mobile nodes desiring to locate a DHCPv6 service may reverse tunnel standard DHCPv6 packets to the home agent. Since these link-scope packets can not be forwarded onto the home network it is necessary for the home agent to either implement a DHCPv6 relay agent or a DHCPv6 server function itself." My reading of the spec is: "because Mobile IPv6 forbids HA to forward ll-scoped packets to the home link, then co-locate the HA with a relay". This is a bit wrong: Mobile IPv6 does not forbid to tunnel ll-scoped packets from MN to HA, it forbids only the other way around. I guess what I'm looking after is to have the HA separated from relay, and to have the HA forward ll-scoped packets addressed to MN. Or maybe I need to ask on the Mobile IP mailing list why the HA is banned from forwarding the ll-scoped packets addressed to MN? Or ask why does the HA intercept the ll-scoped packets when L=1, what does the HA do with those packets if it must drop them anyways? Alex GBU From nemo-admin@nal.motlabs.com Wed Apr 23 22:46:07 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19396 for ; Wed, 23 Apr 2003 22:46:01 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3O2jSFM008647; Thu, 24 Apr 2003 04:45:28 +0200 Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3O2iAFM008637 for ; Thu, 24 Apr 2003 04:44:15 +0200 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h3O2b8D06495; Thu, 24 Apr 2003 10:37:08 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 548DB103C2EF; Thu, 24 Apr 2003 11:08:03 +0800 (SGT) Subject: RE: [nemo] Multiple Egress vs multihoming From: Chan-Wah Ng To: Pascal "Thubert (pthubert)" Cc: IETF NEMO In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1051153683.1690.29.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3- Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 24 Apr 2003 11:08:03 +0800 Content-Transfer-Encoding: 7bit Hello again, Pascal, On Wed, 2003-04-23 at 20:15, Pascal Thubert (pthubert) wrote: > Hi Chan-Wah > > > I beg to differ. Requirement 13.1 does not equate to > > "Multiple MRs with different HAs advertising same prefix". > > Why in the first place would two MR choose to advertise the > > same network prefix if they does not belong to the same > > administration domain? > > It's one way of being multihomed. You have a mobile network in a train. > One prefix. But you want redundancy (load sharing?) so you serve it by > not 1 but 2 MRs. They share the same home network. But may end up on > different HAs if DHAAD is being used or of configured that way. That was > my understanding of the requirement. > I completely agree that your interpretation is one of the possible scenario of requriement 13.1. However, there are other equally pausible scenarios. IMHO, dropping R13.1 because one of its interpretation is deemed too complex (which is arguable in the first place) is too drastic an action. > > But I agree it can be understood differently; IMHO, we should build a > clear taxonomy of all cases (I mean list them, and name them). And then > see what we keep for basic nemo. > I raise both hands in agreement to that :) > > > > For static: > > Why would we require both MR to be on at the same time? If > > one MR is down, its corresponding HA will not receive any BU > > from that MR, and thus cannot establish a route to that MR. > > Hence it will respond to any packet that is destined to the > > mobile prefix with a ICMP destination unreachable or ICMP > > redirect messgae. Just as in the case of w non-mobile, > > multiple router scenario. > > > > Say you have one prefix, P, and 2 MRs, with home address A1 and A2, > respectively > The static routes in the HA look like "ipv6 route P A1" and "ipv6 route > P A2" meaning that P is reachable via either MR at equal cost. > Static Route are permanent things. The routes are always there. > Including if the MR is at home, or power off. > This is no big deal if there's a single MR. If it's joinable (home or > registered), you'll get to P. If not, since there's no alternate path to > P, there's no harm having the route. This keeps the routing protocols > quiet and allows for a large number of MRs/movements. > This is the way things happen unless you add a dynamicity like the MR > exposes itself when at home, and the HA exposes the MR when the MR is > registered. But this is not static routes anymore (I guess it's the > model you have in mind). > If you have 2 MRs, and 2 real static routes of equal cost, the router > behaviour is a round robin traffic splitting, unless you add policies to > the picture. > If the HA has static routes to the mobile network via two MRs, and only > one is reachable, half of the packets are dropped. Now, it's a pain. > Okay. Let's consider non-mobile case. Suppose you have a subnet that has two routers, R1 and R2. Somehow their egress links are all connected (directly or indirectly) to a border router, or gateway, RG. Static routes are used. If R2 is down, how would RG respond? Now change R1=MR1, R2=MR2, RG=HA. Is there any differences? If not, NEMO is not introducing any new problems that does not occur in non-NEMO case. So having requirement R13.1 does not dictates the basic solution to solve a problem that is already in existence in non-mobile case. > > In addition, I don't understand why DHAAD would require > > co-ordination of both MRs, unless you are saying the two MR > > must discover the same HA. > > Question then is why? > > > That's if they register the same home address. This allows to have a > single static route and alleviates the problem mentioned above. But > then, even if we create a support for multiple careofs, you still have > to have them on a single home agent, because of DAD. Unless you create a > new coordication between HAs. The catch is why must they share the same home-address. I am not convince that this is the case. Perhaps you can convince me on that with the responsd to the wired-scanrio above, based on your expertise in routers operations. > > Anyway, you see that this leads us into complex grounds (much more then > other items we dropped in order to release a quick spec for basic :) > Pendora's box. > > Pascal -- Chan-Wah Ng Panasonic Singapore Laboratories From nemo-admin@nal.motlabs.com Thu Apr 24 03:06:42 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06887 for ; Thu, 24 Apr 2003 03:06:39 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3O76GFM010154; Thu, 24 Apr 2003 09:06:17 +0200 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:3ffe:501:100c:d120::53]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3O75KFM010144 for ; Thu, 24 Apr 2003 09:05:22 +0200 Received: from galibier.sfc.wide.ad.jp (galibier.sfc.wide.ad.jp [203.178.143.153]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id B7D465D024; Thu, 24 Apr 2003 16:05:09 +0900 (JST) From: Thierry Ernst To: nemo@nal.motlabs.com Cc: pthubert@cisco.com, Chan-Wah Ng Subject: Re: [nemo] Multiple Egress vs multihoming Message-Id: <20030424160310.5aedfed9.ernst@sfc.wide.ad.jp> In-Reply-To: <1051153683.1690.29.camel@beethoven> References: <1051153683.1690.29.camel@beethoven> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 24 Apr 2003 16:03:10 +0900 Content-Transfer-Encoding: 7bit Hi all, Pascal, Chan-Wah, > In the v 00 of the requirements, Thierry had the multihoming included. > This was discussed at the WG and you'll find the summary at > http://www.nal.motlabs.com/nemo/ietf56/chat-ietf56.txt > > Since the requirement draft is the base for the design, I suggest we > finalize that one first, what do you think? OK, I'm the onw to blame here, I'm due to submit the new version ASAP. Please wait a couple of days more. Sorry for the delay. > > > I beg to differ. Requirement 13.1 does not equate to > > > "Multiple MRs with different HAs advertising same prefix". > > > Why in the first place would two MR choose to advertise the > > > same network prefix if they does not belong to the same > > > administration domain? > > > > It's one way of being multihomed. You have a mobile network in a train. > > One prefix. But you want redundancy (load sharing?) so you serve it by > > not 1 but 2 MRs. They share the same home network. But may end up on > > different HAs if DHAAD is being used or of configured that way. That was > > my understanding of the requirement. This requirement allows another scenario. I have a car. I want distinct ISPs at the same time, not for redundancy. One MR will be my mobile phone and the ISP a cellular operator. The second one will be the built-in MR in my car. It has a 802.11xx interface, and DHRC. The ISP for DHRC is the RoadInfrastrucure company. The ISP of the 802.11xx is maybe the same as the one I have in my house. I can use 802.11xx in the gaz station, in the parking lot. So, I have 3 distinct HAs here. What I don't know yet is if I have one or more prefix. > I completely agree that your interpretation is one of the possible > scenario of requriement 13.1. However, there are other equally pausible > scenarios. IMHO, dropping R13.1 because one of its interpretation is > deemed too complex (which is arguable in the first place) is too drastic > an action. I agree with Chan-Wah. Not that R13.1 doesn't say that a solution must be provided, but it allow it to work (at last meeting I was agreeing that "MUST support" is not the best way to express this requirement). > > But I agree it can be understood differently; IMHO, we should build a > > clear taxonomy of all cases (I mean list them, and name them). And then > > see what we keep for basic nemo. > > > I raise both hands in agreement to that :) You mean you are volunteering here ? :-) FYI, this is something we are currenrly investigating here. But we expect this to take time. > > > For static: > > > Why would we require both MR to be on at the same time? If > > > one MR is down, its corresponding HA will not receive any BU > > > from that MR, and thus cannot establish a route to that MR. > > > Hence it will respond to any packet that is destined to the > > > mobile prefix with a ICMP destination unreachable or ICMP > > > redirect messgae. Just as in the case of w non-mobile, > > > multiple router scenario. > > > > > > > Say you have one prefix, P, and 2 MRs, with home address A1 and A2, > > respectively > > The static routes in the HA look like "ipv6 route P A1" and "ipv6 route > > P A2" meaning that P is reachable via either MR at equal cost. > > Static Route are permanent things. The routes are always there. > > Including if the MR is at home, or power off. > > This is no big deal if there's a single MR. If it's joinable (home or > > registered), you'll get to P. If not, since there's no alternate path to > > P, there's no harm having the route. This keeps the routing protocols > > quiet and allows for a large number of MRs/movements. > > This is the way things happen unless you add a dynamicity like the MR > > exposes itself when at home, and the HA exposes the MR when the MR is > > registered. But this is not static routes anymore (I guess it's the > > model you have in mind). > > If you have 2 MRs, and 2 real static routes of equal cost, the router > > behaviour is a round robin traffic splitting, unless you add policies to > > the picture. > > If the HA has static routes to the mobile network via two MRs, and only > > one is reachable, half of the packets are dropped. Now, it's a pain. > > > > Okay. Let's consider non-mobile case. > > Suppose you have a subnet that has two routers, R1 and R2. Somehow their > egress links are all connected (directly or indirectly) to a border > router, or gateway, RG. Static routes are used. If R2 is down, how > would RG respond? > > Now change R1=MR1, R2=MR2, RG=HA. Is there any differences? If not, > NEMO is not introducing any new problems that does not occur in non-NEMO > case. So having requirement R13.1 does not dictates the basic solution > to solve a problem that is already in existence in non-mobile case. > > > > > In addition, I don't understand why DHAAD would require > > > co-ordination of both MRs, unless you are saying the two MR > > > must discover the same HA. > > > Question then is why? > > > > > That's if they register the same home address. This allows to have a > > single static route and alleviates the problem mentioned above. But > > then, even if we create a support for multiple careofs, you still have > > to have them on a single home agent, because of DAD. Unless you create a > > new coordication between HAs. > > The catch is why must they share the same home-address. I am not > convince that this is the case. Perhaps you can convince me on that > with the responsd to the wired-scanrio above, based on your expertise in > routers operations. > > > > > Anyway, you see that this leads us into complex grounds (much more then > > other items we dropped in order to release a quick spec for basic :) > > Pendora's box. Thierry. From nemo-admin@nal.motlabs.com Thu Apr 24 05:04:43 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08904 for ; Thu, 24 Apr 2003 05:04:37 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3O94JFM012917; Thu, 24 Apr 2003 11:04:19 +0200 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3O938FM012862 for ; Thu, 24 Apr 2003 11:03:12 +0200 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3O931Rs018799; Thu, 24 Apr 2003 11:03:01 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 24 Apr 2003 11:03:03 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053807FEF7F2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Pascal Thubert (pthubert)'" , Chan-Wah Ng Cc: IETF NEMO Subject: RE: [nemo] Multiple Egress vs multihoming MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 24 Apr 2003 11:02:51 +0200 > > I beg to differ. Requirement 13.1 does not equate to > > "Multiple MRs with different HAs advertising same prefix". > > Why in the first place would two MR choose to advertise the > > same network prefix if they does not belong to the same > > administration domain? > > It's one way of being multihomed. You have a mobile network > in a train. > One prefix. But you want redundancy (load sharing?) => I was confused by the previous mail and thought that you must have made this assumption to get the previous conclusion. Multihomed mobile networks do not need to use multihoming for redundancy. They mightbe multihomed because they just happened to have two MRs, period. So the initial aim should be to make this configuration work (i.e. how to route outbound traffic through the right MR). I fully agree that multihoming for redundancy should be done later and not part of basic nemo. Hesham From nemo-admin@nal.motlabs.com Thu Apr 24 05:26:21 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09337 for ; Thu, 24 Apr 2003 05:26:15 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3O9Q6FM013701; Thu, 24 Apr 2003 11:26:06 +0200 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3O9P1FM013679 for ; Thu, 24 Apr 2003 11:25:02 +0200 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 24 Apr 2003 11:24:49 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3O9N29s019707; Thu, 24 Apr 2003 11:23:03 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Apr 2003 11:24:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] Multiple Egress vs multihoming Message-ID: Thread-Topic: [nemo] Multiple Egress vs multihoming Thread-Index: AcMKC2T6iw/aj+YTQ8yMnpDfiVgb3QANQuvg From: "Pascal Thubert (pthubert)" To: "Chan-Wah Ng" Cc: "IETF NEMO" X-OriginalArrivalTime: 24 Apr 2003 09:24:52.0571 (UTC) FILETIME=[5C64EAB0:01C30A43] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h3O9P1FM013679 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 24 Apr 2003 10:24:51 +0100 Content-Transfer-Encoding: 8bit > Okay. Let's consider non-mobile case. > > Suppose you have a subnet that has two routers, R1 and R2. > Somehow their egress links are all connected (directly or > indirectly) to a border router, or gateway, RG. Static > routes are used. If R2 is down, how would RG respond? > > Now change R1=MR1, R2=MR2, RG=HA. Is there any differences? > If not, NEMO is not introducing any new problems that does > not occur in non-NEMO case. So having requirement R13.1 does > not dictates the basic solution to solve a problem that is > already in existence in non-mobile case. The difference is that R1 and R2 will always be there, reachable. And I guess that soon as you have 2 of them, a sensible network designer would start thinking of a routing protocol. If R1 and R2 become mobile, there's a chance that one of them is able to bind and not the other. With static routes, you'll get only half of the packets through, which is not the desired result. > > > > > In addition, I don't understand why DHAAD would require > > > co-ordination of both MRs, unless you are saying the two MR > > > must discover the same HA. > > > Question then is why? > > > > > That's if they register the same home address. This allows > to have a > > single static route and alleviates the problem mentioned above. But > > then, even if we create a support for multiple careofs, you > still have > > to have them on a single home agent, because of DAD. Unless > you create > > a new coordication between HAs. > > The catch is why must they share the same home-address. I am > not convince that this is the case. Perhaps you can convince > me on that with the responsd to the wired-scanrio above, > based on your expertise in routers operations. > If they have the same home address, there's a single static route, so all the packets go over that route. The question is the coordination between the MRs to register to the same HA or the coordination between the HAs to accept that multiple registration and share the load accordingly (there are clustering techniques that allow that much). > > > > Anyway, you see that this leads us into complex grounds (much more > > then other items we dropped in order to release a quick > spec for basic > > :) Pendora's box. > > > > Pascal > -- > Chan-Wah Ng > Panasonic Singapore Laboratories From nemo-admin@nal.motlabs.com Thu Apr 24 08:28:01 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14419 for ; Thu, 24 Apr 2003 08:27:56 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3OCHeFM016646; Thu, 24 Apr 2003 14:17:42 +0200 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3OCGLFM016605 for ; Thu, 24 Apr 2003 14:16:22 +0200 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 24 Apr 2003 14:16:04 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3OCECqa029191; Thu, 24 Apr 2003 14:14:16 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Apr 2003 14:16:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] Multiple Egress vs multihoming Message-ID: Thread-Topic: [nemo] Multiple Egress vs multihoming Thread-Index: AcMKQGMXM5USnl5/R8umy2PyU057+wAAzmkg From: "Pascal Thubert (pthubert)" To: "Hesham Soliman (EAB)" , "Chan-Wah Ng" Cc: "IETF NEMO" X-OriginalArrivalTime: 24 Apr 2003 12:16:04.0234 (UTC) FILETIME=[46C84EA0:01C30A5B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h3OCGLFM016605 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 24 Apr 2003 13:15:45 +0100 Content-Transfer-Encoding: 8bit Hi Hesham and Chan-Wah OK, it's time to start the taxonomy :) In the context of multihoming, When we talk about 'mobile networks', I'd rather consider mobile prefixes, because it's what the MRs carry with them. A MR may actually use the services of a fixed access point though it's a bit weird to me. It may happen that over the wireless, two prefixes, carried by 2 different routers, share the same media for a period of time, and then, possibly split. I understand that this is the case you're talking about? While my case was when 2 MRs own the same prefix and move together like in a train case. Talking prefixes allows to make that distinction. Also, when we talk about multiple egress, we may rather consider multiple access routers. Whether the ARs are on a same egress link or on different interfaces is IMHO to be supported implicitely (R13.2). What's impacting the protocol is rather if you want to build more than one CareOf. And if you let the HA(s) know about that, which would be an extension to MIPv6. So I would build my taxonomy on single vs multiple registered CareOf per prefix: x : same (x=0) vs multiple (x=1) Home Agents for different CareOfs of same prefix In one hand and single vs multiple Mobile Router per ingress: y : same (y=0) vs different (y=1) Prefixes for different MRs of same link In the other hand. Note that this discussion does not presume on whether Ryiji's elegant solution is finally taken or not. Which gives us 4 multihoming problems sets, MH(x=0), MH(x=1), MH(y=0) and MH(y=1), x and y being orthogonal (as far as I can see). Names for the 4 cases could be taken from specific instances. Examples: Tarzan: One MR building and registering (to same HA) several CareOf in order to maintain connectivity while moving is a MH(x=0) JetSet: one MR that registers its prefix to Paris and New York at the same time in order to optimize routing is a MH(x=1) Shinkansen: A train with one prefix, one care of per MR and 2 MRs, which is a MH(y=0). doubleBed: 2 MRs happening to share the same wireless media for their mobile prefix (Erik's problem) is a MH(y=1) Note that IMHO: - one MR with 2 ISPs, one prefix and one HA per ISP, is a collapsed form of doubleBed. The MR really runs 2 instances of Nemo, and whatever policies we may apply to doubleBed will hopefully run there too. - "R13.1: The solution MUST support mobile networks with multiple MRs" is a catch all for Shinkansen and doubleBed - "R13.2: The solution MUST support MR with multiple interfaces" goes without a saying since we're talking about routers - "R13.3: The solution must support MR with multiple global addresses on an egress interface" concerns us only as a catch all for Tarzan and JetSet. Any IPv6 node may build multiple global addresses. Long as we do not register several CareOfs at the same time, it's not a Nemo issue, it's a standard feature. Comments anyone? Pascal > -----Original Message----- > From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] > Sent: jeudi 24 avril 2003 11:03 > To: Pascal Thubert (pthubert); Chan-Wah Ng > Cc: IETF NEMO > Subject: RE: [nemo] Multiple Egress vs multihoming > > > > > > I beg to differ. Requirement 13.1 does not equate to > > > "Multiple MRs with different HAs advertising same prefix". > > > Why in the first place would two MR choose to advertise the > > > same network prefix if they does not belong to the same > > > administration domain? > > > > It's one way of being multihomed. You have a mobile network > > in a train. > > One prefix. But you want redundancy (load sharing?) > > > => I was confused by the previous mail and thought > that you must have made this assumption to get the previous > conclusion. Multihomed mobile networks do not need to use > multihoming for redundancy. They mightbe multihomed because > they just happened to have two MRs, period. So the initial > aim should be to make this configuration work (i.e. how to > route outbound traffic through the right MR). I fully agree > that multihoming for redundancy should be done > later and not part of basic nemo. > > Hesham > > From nemo-admin@nal.motlabs.com Thu Apr 24 08:50:46 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14797 for ; Thu, 24 Apr 2003 08:50:43 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3OCn3FM017132; Thu, 24 Apr 2003 14:49:03 +0200 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3OCmRFM017113 for ; Thu, 24 Apr 2003 14:48:32 +0200 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 9EEDF68991 for ; Thu, 24 Apr 2003 08:48:18 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3OCmHuW003008; Thu, 24 Apr 2003 08:48:17 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp2-21.grc.nasa.gov [139.88.246.21]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.8) with ESMTP id h3OCmFYM004646; Thu, 24 Apr 2003 08:48:15 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030424084455.02575f68@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: "Pascal Thubert (pthubert)" From: William D Ivancic Subject: RE: [nemo] Multiple Egress vs multihoming Cc: "Chan-Wah Ng" , "IETF NEMO" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 24 Apr 2003 08:47:46 -0400 > >If you have 2 MRs, and 2 real static routes of equal cost, the router >behaviour is a round robin traffic splitting, unless you add policies to >the picture. > >>If the HA has static routes to the mobile network via two MRs, and only >one is reachable, half of the packets are dropped. Now, it's a pain.<< Pascal, could you explain the last statement better. If an MR is unreachable, I think the binding goes away and therefore the route. I think the picture in my head and the one being described are different. Will From nemo-admin@nal.motlabs.com Thu Apr 24 08:58:11 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15012 for ; Thu, 24 Apr 2003 08:58:07 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3OCx4FM017279; Thu, 24 Apr 2003 14:59:04 +0200 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3OCwYFM017247 for ; Thu, 24 Apr 2003 14:58:35 +0200 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 24 Apr 2003 14:58:23 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3OCuZWB007776; Thu, 24 Apr 2003 14:56:35 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Apr 2003 14:58:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] Multiple Egress vs multihoming Message-ID: Thread-Topic: [nemo] Multiple Egress vs multihoming Thread-Index: AcMKX9SVAWYME7oqQ32ETDigFg6MWwAANI0A From: "Pascal Thubert (pthubert)" To: "William D Ivancic" Cc: "Chan-Wah Ng" , "IETF NEMO" X-OriginalArrivalTime: 24 Apr 2003 12:58:26.0219 (UTC) FILETIME=[31EC6FB0:01C30A61] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h3OCwYFM017247 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 24 Apr 2003 13:58:25 +0100 Content-Transfer-Encoding: 8bit Hi William: A static route does not go away. That's the point. You code it and it's stays there. If we make it dynamic, then you're right. For instance, upon registration, Nemo installs the route. Or the route is via a tunnel that is externalized. But is the route is in the form 'MR via MR's home address' then since the home address is expected to be on the home network, the route is used... Pascal > -----Original Message----- > From: William D Ivancic [mailto:William.D.Ivancic@grc.nasa.gov] > Sent: jeudi 24 avril 2003 14:48 > To: Pascal Thubert (pthubert) > Cc: Chan-Wah Ng; IETF NEMO > Subject: RE: [nemo] Multiple Egress vs multihoming > > > > > > >If you have 2 MRs, and 2 real static routes of equal cost, > the router > >behaviour is a round robin traffic splitting, unless you add > policies > >to the picture. > > >>If the HA has static routes to the mobile network via two > MRs, and > > >>only > >one is reachable, half of the packets are dropped. Now, it's > a pain.<< > > Pascal, could you explain the last statement better. If an MR is > unreachable, I think the binding goes away and therefore the > route. I > think the picture in my head and the one being described are > different. > > Will > > From nemo-admin@nal.motlabs.com Thu Apr 24 11:07:48 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19252 for ; Thu, 24 Apr 2003 11:07:46 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3OF96FM021123; Thu, 24 Apr 2003 17:09:06 +0200 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3OF8RFM021108 for ; Thu, 24 Apr 2003 17:08:28 +0200 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3OF8KRs026729; Thu, 24 Apr 2003 17:08:20 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 24 Apr 2003 17:08:22 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053807FEF7F8@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Pascal Thubert (pthubert)'" , Chan-Wah Ng Cc: IETF NEMO Subject: RE: [nemo] Multiple Egress vs multihoming MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 24 Apr 2003 17:08:19 +0200 > In the context of multihoming, When we talk about 'mobile > networks', I'd > rather consider mobile prefixes, because it's what the MRs > carry with > them. A MR may actually use the services of a fixed access > point though > it's a bit weird to me. It may happen that over the wireless, two > prefixes, carried by 2 different routers, share the same media for a > period of time, and then, possibly split. => Yes, they may or may not split. I understand that > this is the > case you're talking about? While my case was when 2 MRs own the same > prefix and move together like in a train case. Talking > prefixes allows > to make that distinction. => I thought multihoming refers to the number of interfaces rather than prefixes. So I'm assuming that when you say 2 prefixes you mean either 2 MRs or one MR with 2 interfaces. Having cleared that, your case actually seems more difficult to achieve ;) Are you assuming that the "home" prefix is shared between the 2 MRs? If so how does the HA distinguish between the 2 MRs? Is one SA used to setup the tunnel or 2? > > Also, when we talk about multiple egress, we may rather consider > multiple access routers. Whether the ARs are on a same > egress link or on > different interfaces is IMHO to be supported implicitely > (R13.2). What's > impacting the protocol is rather if you want to build more than one > CareOf. And if you let the HA(s) know about that, which would be an > extension to MIPv6. > > So I would build my taxonomy on single vs multiple > registered CareOf per > prefix: > x : same (x=0) vs multiple (x=1) Home Agents for different > CareOfs of > same prefix => I'm interested to know how multiple care-ofs could work in MIP. We did that for FMIP some time ago but it was based on bi-casting for a short period (1 second). I will comment on the rest of the email separately. Hesham From nemo-admin@nal.motlabs.com Thu Apr 24 23:15:16 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14013 for ; Thu, 24 Apr 2003 23:15:12 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3P3FJFM024858; Fri, 25 Apr 2003 05:15:19 +0200 Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3P3EFFM024848 for ; Fri, 25 Apr 2003 05:14:19 +0200 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h3P374D06397; Fri, 25 Apr 2003 11:07:04 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 0B3B111A42F8; Fri, 25 Apr 2003 11:37:56 +0800 (SGT) Subject: RE: [nemo] Multiple Egress vs multihoming From: Chan-Wah Ng To: Pascal "Thubert (pthubert)" Cc: IETF NEMO In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1051241876.1707.3.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3- Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 25 Apr 2003 11:37:56 +0800 Content-Transfer-Encoding: 7bit On Thu, 2003-04-24 at 17:24, Pascal Thubert (pthubert) wrote: > > Okay. Let's consider non-mobile case. > > > > Suppose you have a subnet that has two routers, R1 and R2. > > Somehow their egress links are all connected (directly or > > indirectly) to a border router, or gateway, RG. Static > > routes are used. If R2 is down, how would RG respond? > > > > Now change R1=MR1, R2=MR2, RG=HA. Is there any differences? > > If not, NEMO is not introducing any new problems that does > > not occur in non-NEMO case. So having requirement R13.1 does > > not dictates the basic solution to solve a problem that is > > already in existence in non-mobile case. > > The difference is that R1 and R2 will always be there, reachable. And I > guess that soon as you have 2 of them, a sensible network designer would > start thinking of a routing protocol. If R1 and R2 become mobile, > there's a chance that one of them is able to bind and not the other. > With static routes, you'll get only half of the packets through, which > is not the desired result. > > AH, but you never answered the first part. For non-mobile case, what will happen if R2 is down? Is it any different in a mobile case? > > > > > > > In addition, I don't understand why DHAAD would require > > > > co-ordination of both MRs, unless you are saying the two MR > > > > must discover the same HA. > > > > Question then is why? > > > > > > > That's if they register the same home address. This allows > > to have a > > > single static route and alleviates the problem mentioned above. But > > > then, even if we create a support for multiple careofs, you > > still have > > > to have them on a single home agent, because of DAD. Unless > > you create > > > a new coordication between HAs. > > > > The catch is why must they share the same home-address. I am > > not convince that this is the case. Perhaps you can convince > > me on that with the responsd to the wired-scanrio above, > > based on your expertise in routers operations. > > > If they have the same home address, there's a single static route, so > all the packets go over that route. The question is the coordination > between the MRs to register to the same HA or the coordination between > the HAs to accept that multiple registration and share the load > accordingly (there are clustering techniques that allow that much). > Yes, yes, I agree that if they must have the same HoA, then the HAs and/or MRs must coordinate. I have no dispute on that. What I disagree is "they must have the same HoA". > > > > > > Anyway, you see that this leads us into complex grounds (much more > > > then other items we dropped in order to release a quick > > spec for basic > > > :) Pendora's box. > > > > > > Pascal > > -- > > Chan-Wah Ng > > Panasonic Singapore Laboratories -- Chan-Wah Ng Panasonic Singapore Laboratories From nemo-admin@nal.motlabs.com Fri Apr 25 00:24:40 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15365 for ; Fri, 25 Apr 2003 00:24:35 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3P4P7FM025085; Fri, 25 Apr 2003 06:25:09 +0200 Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3P4OOFM025075 for ; Fri, 25 Apr 2003 06:24:28 +0200 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with ESMTP id h3P4HFD08509; Fri, 25 Apr 2003 12:17:15 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id 36C03103C2EF; Fri, 25 Apr 2003 12:48:08 +0800 (SGT) Subject: RE: [nemo] Multiple Egress vs multihoming From: Chan-Wah Ng To: Pascal "Thubert (pthubert)" Cc: "Hesham Soliman (EAB)" , IETF NEMO In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1051246087.1707.51.camel@beethoven> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3- Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 25 Apr 2003 12:48:08 +0800 Content-Transfer-Encoding: 7bit On Thu, 2003-04-24 at 20:15, Pascal Thubert (pthubert) wrote: > Hi Hesham and Chan-Wah > > OK, it's time to start the taxonomy :) > > In the context of multihoming, When we talk about 'mobile networks', I'd > rather consider mobile prefixes, because it's what the MRs carry with > them. A MR may actually use the services of a fixed access point though > it's a bit weird to me. It may happen that over the wireless, two > prefixes, carried by 2 different routers, share the same media for a > period of time, and then, possibly split. I understand that this is the > case you're talking about? While my case was when 2 MRs own the same > prefix and move together like in a train case. Talking prefixes allows > to make that distinction. > > Also, when we talk about multiple egress, we may rather consider > multiple access routers. Whether the ARs are on a same egress link or on > different interfaces is IMHO to be supported implicitely (R13.2). What's > impacting the protocol is rather if you want to build more than one > CareOf. And if you let the HA(s) know about that, which would be an > extension to MIPv6. > > So I would build my taxonomy on single vs multiple registered CareOf per > prefix: > x : same (x=0) vs multiple (x=1) Home Agents for different CareOfs of > same prefix > > In one hand and single vs multiple Mobile Router per ingress: > y : same (y=0) vs different (y=1) Prefixes for different MRs of same > link > > In the other hand. Note that this discussion does not presume on whether > Ryiji's elegant solution is finally taken or not. > > Which gives us 4 multihoming problems sets, MH(x=0), MH(x=1), MH(y=0) > and MH(y=1), x and y being orthogonal (as far as I can see). > > Names for the 4 cases could be taken from specific instances. Examples: > > Tarzan: One MR building and registering (to same HA) several CareOf in > order to maintain connectivity while moving is a MH(x=0) > JetSet: one MR that registers its prefix to Paris and New York at the > same time in order to optimize routing is a MH(x=1) > Shinkansen: A train with one prefix, one care of per MR and 2 MRs, which > is a MH(y=0). > doubleBed: 2 MRs happening to share the same wireless media for their > mobile prefix (Erik's problem) is a MH(y=1) > > Note that IMHO: > > - one MR with 2 ISPs, one prefix and one HA per ISP, is a collapsed form > of doubleBed. The MR really runs 2 instances of Nemo, and whatever > policies we may apply to doubleBed will hopefully run there too. > - "R13.1: The solution MUST support mobile networks with multiple MRs" > is a catch all for Shinkansen and doubleBed > - "R13.2: The solution MUST support MR with multiple interfaces" goes > without a saying since we're talking about routers > - "R13.3: The solution must support MR with multiple global addresses on > an egress interface" concerns us only as a catch all for Tarzan and > JetSet. Any IPv6 node may build multiple global addresses. Long as we do > not register several CareOfs at the same time, it's not a Nemo issue, > it's a standard feature. > > Comments anyone? Hi, Pascal, and fellow NEMO WG members, I think it is a bit of a jump on the gun to relate your classifications to requirements. I have a slow mind, so let us back track abit, and first agree on the the taxonomy. As I see it, we are talking about multi-egress mobile network (multi-homing may raise too much confusion). Thus the way I would build the taxonomy is to start from multi-egress. It can be either 1 MR with multiple egress interface, or multiple MRs. For each cases, we can have the distintcions as Pascal suggested of single-vs-multiple HA, and single-vs-multiple mobile network prefix. It turns out that on top of Pascal's (x,y), I have (w,x,y), where {w=0: 1 MR with multiple egress interface, w=1: 2 or more MRs }. With, that, I have the following taxanomy tree: [Multi-egress NEMO] | +->[Multi-Interface]: Single MR with multiple egress interface | | | +->[Single HA]: all HoA-CoA bindings sent to same HA | | | | | +->(A)[Single Prefix]: MR advertises a single prefix | | | | | +->(B)[Multiple Prefix]: MR advertises multiple prefices | | | +->[Multiple HA]: HoA-CoA bindings to different HAs | | | +->(C)[Single Prefix]: MR advertises a single prefix | | | +->(D)[Multiple Prefix]: MR advertises multple prefices | +->[Multi-MR]: Multiple MR | +->[Single HA]: all HoA-CoA bindings sent to same HA | | | +->(E)[Single Prefix]: both MRs advertise same prefix | | | +->(F)[Multiple Prefix]: MRs advertise different prefices | +->[Multiple HA]: MRs send HoA-CoA bindings to different HAs | +->(G)[Single Prefix]: both MRs advertise same prefix | +->(H)[Multiple Prefix]: MRs advertise different prefices Let's for the moment ignore whether or not all the 8 different leaf-nodes (A-H) are pratical, or functionally different. But first off, do everybody agree that teh above taxanomy tree covers all scenarios that we face in NEMO? After we get that clear, perhaps we can start evaluating each case. (and maybe giving them names like Tarzan or Shinkansen, ;) /rgds /cwng -- Chan-Wah Ng Panasonic Singapore Laboratories From nemo-admin@nal.motlabs.com Fri Apr 25 03:10:05 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29423 for ; Fri, 25 Apr 2003 03:10:02 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3P79EFM025774; Fri, 25 Apr 2003 09:09:15 +0200 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3P78lFM025766 for ; Fri, 25 Apr 2003 09:08:51 +0200 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Apr 2003 09:08:34 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3P76F9u001239; Fri, 25 Apr 2003 09:06:48 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 25 Apr 2003 09:08:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] Multiple Egress vs multihoming Message-ID: Thread-Topic: [nemo] Multiple Egress vs multihoming Thread-Index: AcMK2LuWUnHHNTMuR+qkszP1Yx5CPgAH/XBw From: "Pascal Thubert (pthubert)" To: "Chan-Wah Ng" Cc: "IETF NEMO" X-OriginalArrivalTime: 25 Apr 2003 07:08:12.0457 (UTC) FILETIME=[6F289190:01C30AF9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h3P78lFM025766 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 25 Apr 2003 08:08:12 +0100 Content-Transfer-Encoding: 8bit > > The difference is that R1 and R2 will always be there, > reachable. And > > I guess that soon as you have 2 of them, a sensible network > designer > > would start thinking of a routing protocol. If R1 and R2 become > > mobile, there's a chance that one of them is able to bind > and not the > > other. With static routes, you'll get only half of the packets > > through, which is not the desired result. > > > > > AH, but you never answered the first part. For non-mobile > case, what will happen if R2 is down? Is it any different in > a mobile case? Sorry, I thought that was implicit. Same problem, half the packets dropped. This is why a sensible network designer etc... > > > > > If they have the same home address, there's a single static > route, so > > all the packets go over that route. The question is the > coordination > > between the MRs to register to the same HA or the > coordination between > > the HAs to accept that multiple registration and share the load > > accordingly (there are clustering techniques that allow that much). > > > > Yes, yes, I agree that if they must have the same HoA, then the HAs > and/or MRs must coordinate. I have no dispute on that. What I > disagree is "they must have the same HoA". Same home Address for both makes a single static route, all the packets to that route. If there's a distribution, it happens at BCE time, when choosing between multiple parallel registrations, which is DYNAMIC, this time. The problem is to have both MRs register to the same HA and make as if there was a single MR with multiple CareOf (Tarzan). Or else you need to coordinate the HAs, but it seems even a bigger change from MIPv6 because of ND interaction. Pascal From nemo-admin@nal.motlabs.com Fri Apr 25 03:51:03 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29951 for ; Fri, 25 Apr 2003 03:50:57 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3P7p6FM025918; Fri, 25 Apr 2003 09:51:06 +0200 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3P7oSFM025910 for ; Fri, 25 Apr 2003 09:50:29 +0200 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Apr 2003 09:50:15 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3P7m7KS007666; Fri, 25 Apr 2003 09:48:31 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 25 Apr 2003 09:50:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] Multiple Egress vs multihoming Message-ID: Thread-Topic: [nemo] Multiple Egress vs multihoming Thread-Index: AcMK4okafI3gjWZNTKKc57RBa5QNJgAGLTpg From: "Pascal Thubert (pthubert)" To: "Chan-Wah Ng" Cc: "Hesham Soliman (EAB)" , "IETF NEMO" X-OriginalArrivalTime: 25 Apr 2003 07:50:19.0239 (UTC) FILETIME=[513CE770:01C30AFF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h3P7oSFM025910 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 25 Apr 2003 08:50:18 +0100 Content-Transfer-Encoding: 8bit > > on different interfaces is IMHO to be supported implicitly (R13.2). > It can be either 1 MR with multiple egress interface, or > multiple MRs. For each cases, we can have the distinctions as > Pascal suggested of single-vs.-multiple HA, and > single-vs.-multiple mobile network prefix. It turns out that > on top of Pascal's (x,y), I have (w,x,y), where {w=0: 1 MR > with multiple egress interface, w=1: 2 or more MRs }. > > With, that, I have the following taxanomy tree: > > > [Multi-egress NEMO] > | > +->[Multi-Interface]: Single MR with multiple egress interface > | | > | +->[Single HA]: all HoA-CoA bindings sent to same HA > | | | > | | +->(A)[Single Prefix]: MR advertises a single prefix > | | | > | | +->(B)[Multiple Prefix]: MR advertises multiple prefices > | | > | +->[Multiple HA]: HoA-CoA bindings to different HAs > | | > | +->(C)[Single Prefix]: MR advertises a single prefix > | | > | +->(D)[Multiple Prefix]: MR advertises multple prefices > | > +->[Multi-MR]: Multiple MR > | > +->[Single HA]: all HoA-CoA bindings sent to same HA > | | > | +->(E)[Single Prefix]: both MRs advertise same prefix > | | > | +->(F)[Multiple Prefix]: MRs advertise different prefices > | > +->[Multiple HA]: MRs send HoA-CoA bindings to different HAs > | > +->(G)[Single Prefix]: both MRs advertise same prefix > | > +->(H)[Multiple Prefix]: MRs advertise different prefices > I add proposed in the initial mail that a MR with multiple interfaces fell into the sense (R13.2). The real thing is whether there are more then one active CareOf at a given point of time, which is where we extend MIP. If you look at it, You can autoconf more than one CareOf on a single interface if you hear from more than one AR, and this is already a multihoming scenario (so there is multihoming with w=0!). Whether the ARs are on the same egress link or different egress links of a same MR does not seem to impact the mobility protocol, does it? That may impact QoS related issues, though, but it seems far from basic nemo. Also, it seems to me that the x and y directions should be orthogonal. This is a design decision. The protocol changes that allow multiple CareOf should not be related to the protocol changes that allow multiple MRs. This assumption may be eliminating some solutions, but I think it's the clean approach. It is related to the parallel discussion we are having with the same title. With all this in mind, I reduced the problem set to 4 cases, knowing that a solution for either x must allow either y and reciprocally. To come back to your classification, I'd suggest you start thinking for w in terms of CareOf as opposed to links. Read my initial mail carefully, I spent quite some time wording it. A second point is that I associate the CareOf with the prefixes, not the home addresses. Think about it with Ryuji's draft in mind. From nemo-admin@nal.motlabs.com Fri Apr 25 05:59:09 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01823 for ; Fri, 25 Apr 2003 05:59:07 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3P9vMFM026692; Fri, 25 Apr 2003 11:57:24 +0200 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:3ffe:501:100c:d120::53]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3P9kdFM026558 for ; Fri, 25 Apr 2003 11:46:52 +0200 Received: from juryan (unknown [3ffe:501:100c:d220:220:e0ff:fe89:e01]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id A7E435D0FF for ; Fri, 25 Apr 2003 18:45:56 +0900 (JST) From: Julien Charbon To: nemo@nal.motlabs.com Subject: Re: [nemo] Multiple Egress vs multihoming Message-Id: <20030425194555.240679f1.julien@sfc.wide.ad.jp> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 25 Apr 2003 19:45:55 +0900 Content-Transfer-Encoding: 7bit Thierry, il semblerait que nal.motlabs.com ne soit plus joignable pour le moment alors mon mail pour nemo@nal.motlabs.com n'est pas pres d'arriver. Mais tu as la primeur avant ma prochaine tentative. ------------------------------ Hi all, hi Pascal, I'm working [1] on using Nemo in Multi-Homing cases so I read this thread with interest. So I allows itself to make some comments. On Thu, 24 Apr 2003 13:15:45 +0100 "Pascal Thubert (pthubert)" wrote: > OK, it's time to start the taxonomy :) Great ! it is a part of one of my goals. > Also, when we talk about multiple egress, we may rather consider > multiple access routers. Whether the ARs are on a same egress link or on > different interfaces is IMHO to be supported implicitely (R13.2). What's > impacting the protocol is rather if you want to build more than one > CareOf. And if you let the HA(s) know about that, which would be an > extension to MIPv6. > > So I would build my taxonomy on single vs multiple registered CareOf per > prefix: > x : same (x=0) vs multiple (x=1) Home Agents for different CareOfs of > same prefix > > In one hand and single vs multiple Mobile Router per ingress: > y : same (y=0) vs different (y=1) Prefixes for different MRs of same > link > > In the other hand. Note that this discussion does not presume on whether > Ryiji's elegant solution is finally taken or not. > > Which gives us 4 multihoming problems sets, MH(x=0), MH(x=1), MH(y=0) > and MH(y=1), x and y being orthogonal (as far as I can see). > > Names for the 4 cases could be taken from specific instances. Examples: > > Tarzan: One MR building and registering (to same HA) several CareOf in > order to maintain connectivity while moving is a MH(x=0) > JetSet: one MR that registers its prefix to Paris and New York at the > same time in order to optimize routing is a MH(x=1) > Shinkansen: A train with one prefix, one care of per MR and 2 MRs, which > is a MH(y=0). > doubleBed: 2 MRs happening to share the same wireless media for their > mobile prefix (Erik's problem) is a MH(y=1) I prefer graphical and so if I understand well : o Tarzan: [Single HA for CoAs of a same Prefix] Example with one "Multi-egress-interfaced" MR. _____ _ _ | | |_|-| _ |-|_|-| |-| _ _ |-|_|=| |_____| | _ |-|_| |_|-| | |-|_|-| | MNNs MR AR Internet AR HA Remarks : - "Multi-egress-interfaced" MR: A MR which has more than one Egress Interface. [I didn't find this in the Terminology-Draft]. - [=] Symbol <=> Two Interfaces. In this example : - MR have multiple egress interfaces, and registered all its CoAs to the same HA with a same prefix. Useful for: Keep L2 Connectivity to the Internet while moving by switching between interfaces. [Like Tarzan] o JetSet: [Multiple HAs for CoAs of a same Prefix] Example with one "Multi-egress-interfaced" MR. AR HA1 _ | |-|_|-| _ _____ | |-|_| _ _ | |-| |_|-| _ |-|_|-| | _ |-|_|=| |_____|-| _ |_|-| | | _ |-|_| |-|_|-| | MNNs MR AR Internet AR HA2 In this example : - Mr have multiple egress interfaces, and registered its CoAs to differents HAs. Useful for: Kind of Routing Optimization make by the MR. [Prefer send packet to the nearest HA]. [It's an hypothesis, I'm not sure of that]. o Shinkansen: [Single prefix announced by Egress Router(s)] Example with two Egress Routers. P ---> MR2 _ | _ |-|_|-| _____ |_|-| |-| | _ | | |-| _ |_|-| _ |-|_____| | _ |-|_| |-|_|-| |-|_|-| | | MNNs MR1 Internet AR HA P ---> Useful for: Router Redundancy. o DoubleBed: [Multiple prefix announced by Egress Router(s)] Example with two Egress Routers. P2 ---> MR2 _ | _ |-|_|-| _____ |_|-| |-| | _ | | |-| _ |_|-| _ |-|_____| | _ |-|_| |-|_|-| |-|_|-| | | MNNs MR1 Internet AR HA P1 ---> Useful for: ISP Redundancy or Keep connectivity through differents kind of technology provide by differents ISPs. > Note that IMHO: > > - one MR with 2 ISPs, one prefix and one HA per ISP, is a collapsed form > of doubleBed. The MR really runs 2 instances of Nemo, and whatever > policies we may apply to doubleBed will hopefully run there too. Your example: ISP 1 AR HA2 P1 _ | --> | |-|_|-| _ _ | __| _____ | |-|_| |_|-| _/ |-| |-| _ |-|_| | | |_|-| \__|-|_____|-| _ | | | _ |-|_| --> | |-|_|-| P2 | ISP2 AR HA1 MNNs MR Internet Well,... IMHO I think it's preferable to say : It's a + Multiple-Interfaced MR [Multiple Interfaces] + Single HA [Just one HA for CoAs for a same prefix] + Multiple Prefix [Announced by Egress Routers] case. So I think our classification need one level more. [See at the end of this mail]. > - "R13.1: The solution MUST support mobile networks with multiple MRs" > is a catch all for Shinkansen and doubleBed Not only for Shinkansen and DoubleBed because, you can have this case: P ---> _ _____ _ |-|_|-| _ | | |_|-| |-|_|-| |-| _ _ | | |_____| | _ |-|_| |_|-| _ | |-|_|-| |-|_|-| | ---> P MNNs MR AR Internet AR HA Which is a Tarzan case. [Single HA for CoAs of a same Prefix] > - "R13.2: The solution MUST support MR with multiple interfaces" goes > without a saying since we're talking about routers In fact, the requirement should say : - "R13.2: The solution MUST support MR with multiple interfaces", especially the multi-egress-interfaced MR. But it is a tiny detail. > - "R13.3: The solution must support MR with multiple global addresses on > an egress interface" concerns us only as a catch all for Tarzan and > JetSet. Can you be more clear with the notion of "catch-all" ? I am explained: There is many classes of Multi-Homing: o Multi-Address: The more interesting case is then an interface have more than one IPv6 global address. o Multi-Interface: More than one Interface. o Multi-Site: More than one "Border Router". So for the Tarzan you can have: - One multi-addressed MR. AR2 [P2] _ _ _____ |_|-| _ |-|_|-| | _ |-|_|-| _ | |-| _ |_|-| |-|_|-|_____| | _ |-|_| |-|_|-| | AR1 [P1] MNNs MR Internet AR HA - One "Multi-egress-interfaced" MR. _____ _ _ | | |_|-| _ |-|_|-| |-| _ _ |-|_|=| |_____| | _ |-|_| |_|-| | |-|_|-| | MNNs MR AR Internet AR HA - Two MR in multi-site case. P ---> _ _____ _ |-|_|-| _ | | |_|-| |-|_|-| |-| _ _ | | |_____| | _ |-|_| |_|-| _ | |-|_|-| |-|_|-| | ---> P MNNs MR AR Internet AR HA In all this examples the HA will have two CoAs for the same prefix in one HA. According with your definition they are Tarzan cases. > Any IPv6 node may build multiple global addresses. Long as we do not > register several CareOfs at the same time, it's not a Nemo issue, > it's a standard feature. I just add a remark : - Example with one MR multi-addressed. AR2 [P2] _ _ _____ |_|-| _ |-|_|-| | _ |-|_|-| _ | |-| _ |_|-| |-|_|-|_____| | _ |-|_| |-|_|-| | AR1 [P1] MNNs MR Internet AR HA P1/P2: Differents IPv6 /64 Prefix. And of course Ingress Filtering is made on AR1 and AR2. So the MR may have this two IPv6 global address : P2:EUI-64-MR and P1:EUI-64-MR If the bi-directional tunnel between the MR and the HA pass through AR2 and if AR2 is destroyed by Tarzan anger [the real one] and so its reachability to the Internet lost, how the NEMO mechanism should deal with this case ? So I think Multi-Addressed Multi-Homing is an important case in NEMO, not just a standard fearture. [But maybe I'm wrong]. Also maybe it will be resolve by the same mechanism in NEMO, so I put it with the Multi-Interfaced case. > Comments anyone? I think you have found the good discrimants to classify the Multi-Homing in NEMO. So I have just read the Chan Wah Ng's mail [2], and just by taking again his classification and ours : And I obtain (w, x, y) : with w: 0: A Mobile Router have more than one Global IPv6 Address. OR a Mobile Router have more than one Interface. 1: There is more then one Egress Mobile Router. x: 0: There is single HA for CoAs of a same Prefix. 1: There is muliple HA for CoAs of a same Prefix. y: 0: A single Prefix is announced by Egress Router(s). 1: Muliple Prefix are announced by Egress Router(s). Excuse for this long mail, it's difficult to be sharp and short. -- Julien [1] http://www.sfc.wide.ad.jp/~julien/ [Work in big progress] [2] http://www.nal.motlabs.com/pipermail/nemo/2003-April/000563.html From nemo-admin@nal.motlabs.com Fri Apr 25 06:08:20 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01948 for ; Fri, 25 Apr 2003 06:08:17 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3P9MHFM026249; Fri, 25 Apr 2003 11:22:19 +0200 Received: from shonan.sfc.wide.ad.jp ([IPv6:3ffe:501:100c:d120::53]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3P9LqFM026241 for ; Fri, 25 Apr 2003 11:21:54 +0200 Received: from juryan (unknown [3ffe:501:100c:d220:220:e0ff:fe89:e01]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 27BB55D0F9 for ; Fri, 25 Apr 2003 18:21:26 +0900 (JST) From: Julien Charbon To: nemo@nal.motlabs.com Subject: Re: [nemo] Multiple Egress vs multihoming Message-Id: <20030425192124.60bde7fc.julien@sfc.wide.ad.jp> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 25 Apr 2003 19:21:24 +0900 Content-Transfer-Encoding: 7bit Hi all, hi Pascal, I'm working [1] on using Nemo in Multi-Homing cases so I read this thread with interest. So I allows itself to make some comments. On Thu, 24 Apr 2003 13:15:45 +0100 "Pascal Thubert (pthubert)" wrote: > OK, it's time to start the taxonomy :) Great ! it is a part of one of my goals. > Also, when we talk about multiple egress, we may rather consider > multiple access routers. Whether the ARs are on a same egress link or on > different interfaces is IMHO to be supported implicitely (R13.2). What's > impacting the protocol is rather if you want to build more than one > CareOf. And if you let the HA(s) know about that, which would be an > extension to MIPv6. > > So I would build my taxonomy on single vs multiple registered CareOf per > prefix: > x : same (x=0) vs multiple (x=1) Home Agents for different CareOfs of > same prefix > > In one hand and single vs multiple Mobile Router per ingress: > y : same (y=0) vs different (y=1) Prefixes for different MRs of same > link > > In the other hand. Note that this discussion does not presume on whether > Ryiji's elegant solution is finally taken or not. > > Which gives us 4 multihoming problems sets, MH(x=0), MH(x=1), MH(y=0) > and MH(y=1), x and y being orthogonal (as far as I can see). > > Names for the 4 cases could be taken from specific instances. Examples: > > Tarzan: One MR building and registering (to same HA) several CareOf in > order to maintain connectivity while moving is a MH(x=0) > JetSet: one MR that registers its prefix to Paris and New York at the > same time in order to optimize routing is a MH(x=1) > Shinkansen: A train with one prefix, one care of per MR and 2 MRs, which > is a MH(y=0). > doubleBed: 2 MRs happening to share the same wireless media for their > mobile prefix (Erik's problem) is a MH(y=1) I prefer graphical and so if I understand well : o Tarzan: [Single HA for CoAs of a same Prefix] Example with one "Multi-egress-interfaced" MR. _____ _ _ | | |_|-| _ |-|_|-| |-| _ _ |-|_|=| |_____| | _ |-|_| |_|-| | |-|_|-| | MNNs MR AR Internet AR HA Remarks : - "Multi-egress-interfaced" MR: A MR which has more than one Egress Interface. [I didn't find this in the Terminology-Draft]. - [=] Symbol <=> Two Interfaces. In this example : - MR have multiple egress interfaces, and registered all its CoAs to the same HA with a same prefix. Useful for: Keep L2 Connectivity to the Internet while moving by switching between interfaces. [Like Tarzan] o JetSet: [Multiple HAs for CoAs of a same Prefix] Example with one "Multi-egress-interfaced" MR. AR HA1 _ | |-|_|-| _ _____ | |-|_| _ _ | |-| |_|-| _ |-|_|-| | _ |-|_|=| |_____|-| _ |_|-| | | _ |-|_| |-|_|-| | MNNs MR AR Internet AR HA2 In this example : - Mr have multiple egress interfaces, and registered its CoAs to differents HAs. Useful for: Kind of Routing Optimization make by the MR. [Prefer send packet to the nearest HA]. [It's an hypothesis, I'm not sure of that]. o Shinkansen: [Single prefix announced by Egress Router(s)] Example with two Egress Routers. P ---> MR2 _ | _ |-|_|-| _____ |_|-| |-| | _ | | |-| _ |_|-| _ |-|_____| | _ |-|_| |-|_|-| |-|_|-| | | MNNs MR1 Internet AR HA P ---> Useful for: Router Redundancy. o DoubleBed: [Multiple prefix announced by Egress Router(s)] Example with two Egress Routers. P2 ---> MR2 _ | _ |-|_|-| _____ |_|-| |-| | _ | | |-| _ |_|-| _ |-|_____| | _ |-|_| |-|_|-| |-|_|-| | | MNNs MR1 Internet AR HA P1 ---> Useful for: ISP Redundancy or Keep connectivity through differents kind of technology provide by differents ISPs. > Note that IMHO: > > - one MR with 2 ISPs, one prefix and one HA per ISP, is a collapsed form > of doubleBed. The MR really runs 2 instances of Nemo, and whatever > policies we may apply to doubleBed will hopefully run there too. Your example: ISP 1 AR HA2 P1 _ | --> | |-|_|-| _ _ | __| _____ | |-|_| |_|-| _/ |-| |-| _ |-|_| | | |_|-| \__|-|_____|-| _ | | | _ |-|_| --> | |-|_|-| P2 | ISP2 AR HA1 MNNs MR Internet Well,... IMHO I think it's preferable to say : It's a + Multiple-Interfaced MR [Multiple Interfaces] + Single HA [Just one HA for CoAs for a same prefix] + Multiple Prefix [Announced by Egress Routers] case. So I think our classification need one level more. [See at the end of this mail]. > - "R13.1: The solution MUST support mobile networks with multiple MRs" > is a catch all for Shinkansen and doubleBed Not only for Shinkansen and DoubleBed because, you can have this case: P ---> _ _____ _ |-|_|-| _ | | |_|-| |-|_|-| |-| _ _ | | |_____| | _ |-|_| |_|-| _ | |-|_|-| |-|_|-| | ---> P MNNs MR AR Internet AR HA Which is a Tarzan case. [Single HA for CoAs of a same Prefix] > - "R13.2: The solution MUST support MR with multiple interfaces" goes > without a saying since we're talking about routers In fact, the requirement should say : - "R13.2: The solution MUST support MR with multiple interfaces", especially the multi-egress-interfaced MR. But it is a tiny detail. > - "R13.3: The solution must support MR with multiple global addresses on > an egress interface" concerns us only as a catch all for Tarzan and > JetSet. Can you be more clear with the notion of "catch-all" ? I am explained: There is many classes of Multi-Homing: o Multi-Address: The more interesting case is then an interface have more than one IPv6 global address. o Multi-Interface: More than one Interface. o Multi-Site: More than one "Border Router". So for the Tarzan you can have: - One multi-addressed MR. AR2 [P2] _ _ _____ |_|-| _ |-|_|-| | _ |-|_|-| _ | |-| _ |_|-| |-|_|-|_____| | _ |-|_| |-|_|-| | AR1 [P1] MNNs MR Internet AR HA - One "Multi-egress-interfaced" MR. _____ _ _ | | |_|-| _ |-|_|-| |-| _ _ |-|_|=| |_____| | _ |-|_| |_|-| | |-|_|-| | MNNs MR AR Internet AR HA - Two MR in multi-site case. P ---> _ _____ _ |-|_|-| _ | | |_|-| |-|_|-| |-| _ _ | | |_____| | _ |-|_| |_|-| _ | |-|_|-| |-|_|-| | ---> P MNNs MR AR Internet AR HA In all this examples the HA will have two CoAs for the same prefix in one HA. According with your definition they are Tarzan cases. > Any IPv6 node may build multiple global addresses. Long as we do not > register several CareOfs at the same time, it's not a Nemo issue, > it's a standard feature. I just add a remark : - Example with one MR multi-addressed. AR2 [P2] _ _ _____ |_|-| _ |-|_|-| | _ |-|_|-| _ | |-| _ |_|-| |-|_|-|_____| | _ |-|_| |-|_|-| | AR1 [P1] MNNs MR Internet AR HA P1/P2: Differents IPv6 /64 Prefix. And of course Ingress Filtering is made on AR1 and AR2. So the MR may have this two IPv6 global address : P2:EUI-64-MR and P1:EUI-64-MR If the bi-directional tunnel between the MR and the HA pass through AR2 and if AR2 is destroyed by Tarzan anger [the real one] and so its reachability to the Internet lost, how the NEMO mechanism should deal with this case ? So I think Multi-Addressed Multi-Homing is an important case in NEMO, not just a standard fearture. [But maybe I'm wrong]. Also maybe it will be resolve by the same mechanism in NEMO, so I put it with the Multi-Interfaced case. > Comments anyone? I think you have found the good discrimants to classify the Multi-Homing in NEMO. So I have just read the Chan Wah Ng's mail [2], and just by taking again his classification and ours : And I obtain (w, x, y) : with w: 0: A Mobile Router have more than one Global IPv6 Address. OR a Mobile Router have more than one Interface. 1: There is more then one Egress Mobile Router. x: 0: There is single HA for CoAs of a same Prefix. 1: There is muliple HA for CoAs of a same Prefix. y: 0: A single Prefix is announced by Egress Router(s). 1: Muliple Prefix are announced by Egress Router(s). Excuse for this long mail, it's difficult to be sharp and short. -- Julien [1] http://www.sfc.wide.ad.jp/~julien/ [Work in big progress] [2] http://www.nal.motlabs.com/pipermail/nemo/2003-April/000563.html From nemo-admin@nal.motlabs.com Fri Apr 25 12:00:23 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13036 for ; Fri, 25 Apr 2003 12:00:22 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3PG1FFM001209; Fri, 25 Apr 2003 18:01:15 +0200 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3PG0IFM001187 for ; Fri, 25 Apr 2003 18:00:18 +0200 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Apr 2003 18:00:06 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3PFwLeM015727; Fri, 25 Apr 2003 17:58:21 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 25 Apr 2003 18:00:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] Multiple Egress vs multihoming Message-ID: Thread-Topic: [nemo] Multiple Egress vs multihoming Thread-Index: AcMLGFRFlSIPfSNOTK+HDJXG5G6ZBQAFLx0g From: "Pascal Thubert (pthubert)" To: "Julien Charbon" , X-OriginalArrivalTime: 25 Apr 2003 16:00:11.0474 (UTC) FILETIME=[C0600B20:01C30B43] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h3PG0IFM001187 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 25 Apr 2003 17:00:11 +0100 Content-Transfer-Encoding: 8bit Hi Julien: I like your work very much. Very useful and constructive :) I hope we keep your pictures in the final taxonomy. A general remark, the fact that the multiple careofs are one the same interface or on different interfaces does not strike me as relevant. There must be a way for the MR to sort out the available careOfs and use the best one(s). The interface that provides a careOf is relevant in that selection. But the protocol to the Home Agent is not impacted, is it? > + Single HA [Just one HA for CoAs for a same prefix] > + Multiple Prefix [Announced by Egress Routers] > Right. > > Not only for Shinkansen and DoubleBed because, you can have this > case: > > P > ---> > _ _____ > _ |-|_|-| _ | | > |_|-| |-|_|-| |-| _ > _ | | |_____| | _ |-|_| > |_|-| _ | |-|_|-| > |-|_|-| | > > ---> > P > > MNNs MR AR Internet AR HA > > Which is a Tarzan case. [Single HA for CoAs of a same Prefix] > You're right :) > > So for the Tarzan you can have: > > - One multi-addressed MR. > > AR2 [P2] > _ _ _____ > |_|-| _ |-|_|-| | > _ |-|_|-| _ | |-| _ > |_|-| |-|_|-|_____| | _ |-|_| > |-|_|-| > | > AR1 [P1] > > MNNs MR Internet AR HA > > > - One "Multi-egress-interfaced" MR. > _____ > _ _ | | > |_|-| _ |-|_|-| |-| _ > _ |-|_|=| |_____| | _ |-|_| > |_|-| | |-|_|-| > | > > MNNs MR AR Internet AR HA > > > - Two MR in multi-site case. > > P > ---> > _ _____ > _ |-|_|-| _ | | > |_|-| |-|_|-| |-| _ > _ | | |_____| | _ |-|_| > |_|-| _ | |-|_|-| > |-|_|-| | > > ---> > P > > MNNs MR AR Internet AR HA Yes, they are all Tarzan. The most typical in my mind is: Note that the [=] sign is extended to mean 'may or may not be the same interface' AR2 [P2] _ _ _____ |_|-| _ |-|_|-| | _ |-|_|= _ | |-| _ |_|-| |-|_|-|_____| | _ |-|_| |-|_|-| | AR1 [P1] MNNs MR Internet AR HA > > In all this examples the HA will have two CoAs for the > same prefix in one HA. According with your definition they > are Tarzan cases. > Shinkansen and doubleBed are Tarzans by definition. I meant x and y to be orthogonal, not mutually exclusive. I just hope that the problems can be addressed separately. > > Any IPv6 node may build multiple global addresses. Long as > we do not > > register several CareOfs at the same time, it's not a Nemo > issue, it's > > a standard feature. > > I just add a remark : > > - Example with one MR multi-addressed. > > AR2 [P2] > _ _ _____ > |_|-| _ |-|_|-| | > _ |-|_|-| _ | |-| _ > |_|-| |-|_|-|_____| | _ |-|_| > |-|_|-| > | > AR1 [P1] > > MNNs MR Internet AR HA > > P1/P2: Differents IPv6 /64 Prefix. > > And of course Ingress Filtering is made on AR1 and AR2. > > So the MR may have this two IPv6 global address : > > P2:EUI-64-MR and P1:EUI-64-MR > > If the bi-directional tunnel between the MR and the HA pass > through AR2 and if AR2 is destroyed by Tarzan anger [the real > one] and so its reachability to the Internet lost, how the > NEMO mechanism should deal with this case ? > So I think Multi-Addressed Multi-Homing is an important > case in NEMO, not just a standard fearture. [But maybe I'm > wrong]. Also maybe it will be resolve by the same mechanism > in NEMO, so I put it with the Multi-Interfaced case. > Reread me well: I meant that if you register only one CareOf at a given point of time, it is a standard MIP flows. If a MIP MN sees 2 ARs on a link, it can build 2 careOfs, but can only bind the primary. If the primary careOf fails to bind, or times out rebinding, a standard MIP MN should go try the next available careOf. That process is not necessarily described in MIPv6, but should it? Now, if you have 2 concurent tunnels, it is a whole new problem, to be designed :) . The HA may try to load balance over the 2 tunnels, and if one dies, we must make sure the HA knows quite fast. For instance by encapsulating over TCP or SCTP. Anyway, it's one of the good problems to resolve if we want multiple careOfs. Multihoming is not trivial, we'll have to decide whether to amend the requirements draft for basic about that. > > Comments anyone? > > I think you have found the good discrimants to classify the > Multi-Homing in NEMO. So I have just read the Chan Wah Ng's > mail [2], and just by taking again his classification and ours : > > And I obtain (w, x, y) : > > with > > w: 0: A Mobile Router have more than one Global IPv6 Address. > OR a Mobile Router have more than one Interface. > 1: There is more then one Egress Mobile Router. > I expect that in any case you imply that multiple CareOfs are registered in parallel, right? > x: 0: There is single HA for CoAs of a same Prefix. > 1: There is muliple HA for CoAs of a same Prefix. > I meant mobile prefixes, no the prefix that the careOf is built upon. I'm sure you mean that too? > y: 0: A single Prefix is announced by Egress Router(s). > 1: Muliple Prefix are announced by Egress Router(s). > I meant present on INGRESS; see the discussion with Hesham; is this a typo or is there a misunderstanding between us? I do agree with your vision. My view is a summarization to focus on where the problems are in my own view. We may start your standpoint and see what are the meaningful case between the 8 combinations. For instance (0,0,1) is a trivial extension of (0,0,0). Like this, we'll find my 4 problems, and other if I missed some? Do you want to pursue that way? Pascal From nemo-admin@nal.motlabs.com Fri Apr 25 12:58:52 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14822 for ; Fri, 25 Apr 2003 12:58:51 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3PH03FM001434; Fri, 25 Apr 2003 19:00:03 +0200 Received: from fox (bb-203-125-111-5.singnet.com.sg [203.125.111.5]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3PGxwFM001422 for ; Fri, 25 Apr 2003 18:59:59 +0200 Received: by fox (Postfix, from userid 1000) id C4534116DC0D; Sat, 26 Apr 2003 01:00:49 +0800 (SGT) From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: IETF-NEMO Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1051290049.5416.20.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3- Subject: [nemo] Multi-Homing Taxanomy Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 26 Apr 2003 01:00:49 +0800 Content-Transfer-Encoding: 7bit Hi all, This is an attempt to capture what have been discussed on the mailing list thread: "Multiple Egress vs multihoming". I guess we can pretty much agree on the complete taxanomy now, and discussion can then be carry on forward with this set of taxanomy. My am is to update the draft 'draft-ng-nemo-multihoming-issues-00.txt' (perhaps renaming it to draft-ng-nemo-multi-egress-issues-00.txt'). In the discussion of multi-egress mobile network, we identify three parameters, collectively a truple of (w,x,y) to classify multi-egress mobile network into 8 different categories. 'w' differentiate the case of single-vs-multiple mobile routers on a mobile network, where w = 0: A mobile router with more than one gloabl address may be of the multiple egress interface, or multiple addresses bound to the same interface = 1: More than one mobile router 'x' differentiates the case of single-vs-multiple home agents the MR(s) send binding updates to, where x = 0: A single HA for all bindings of the mobile network prefices = 1: The binding mobile prefices is spread across more than one HAs 'y' differentiates the case of single-vs-multiple mobile network prefices advertised to the mobile network nodes, where y = 0: A single prefix is advertise to the MNNs = 1: More than one prefices is advertised to the MNNs With the above classifications, we have 8 different categories: (0,0,0): single MR, single HA, single prefix (0,0,1): single MR, single HA, multiple prefices (0,1,0): single MR, multiple HAs, single prefix (0,1,1): single MR, multiple HAs, multiple prefices (1,0,0): multiple MRs, single HA, single prefix (1,0,1): multiple MRs, single HA, multiple prefices (1,1,0): multiple MRs, multiple HAs, single prefix (1,1,1): multiple MRs, multiple HAs, multiple prefices Is everyone agreeable on this taxanomy? /rgds /cwng From nemo-admin@nal.motlabs.com Fri Apr 25 16:18:34 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21178 for ; Fri, 25 Apr 2003 16:18:33 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3PKIpFM002107; Fri, 25 Apr 2003 22:18:51 +0200 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3PKHPFM002097; Fri, 25 Apr 2003 22:17:26 +0200 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA07957; Fri, 25 Apr 2003 14:17:06 -0600 (MDT) Received: from localhost (d-mpk17-81-217.Eng.Sun.COM [129.146.81.217]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h3PKGwL11145; Fri, 25 Apr 2003 22:16:58 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Link local addresses To: Alexandru Petrescu Cc: Erik Nordmark , =?iso-8859-1?Q?Pekka_=3D=3Fiso-8859-1=3FQ=3FP=E4=E4kk=F6nen=3F=3D?= , Ole Troan , nemo@nal.motlabs.com, rdroms@cisco.com In-Reply-To: "Your message with ID" <3EA6C451.6080508@nal.motlabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 25 Apr 2003 22:16:41 +0200 (CEST) > I guess what I'm looking after is to have the HA separated from relay, > and to have the HA forward ll-scoped packets addressed to MN. > > Or maybe I need to ask on the Mobile IP mailing list why the HA is > banned from forwarding the ll-scoped packets addressed to MN? Or ask > why does the HA intercept the ll-scoped packets when L=1, what does the > HA do with those packets if it must drop them anyways? I think I've already given my views on the above two points on the Nemo list, but you are welcome to ask the MIP list. Erik From nemo-admin@nal.motlabs.com Fri Apr 25 21:13:30 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28672 for ; Fri, 25 Apr 2003 21:13:29 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3Q1FDFM003250; Sat, 26 Apr 2003 03:15:13 +0200 Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [IPv6:3ffe:501:100c:d210:2e0:18ff:fe98:936d] (may be forged)) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3Q1DwFM003238 for ; Sat, 26 Apr 2003 03:14:00 +0200 Received: from [192.168.0.11] (pdd8831.tkyoac00.ap.so-net.ne.jp [218.221.136.49]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h3Q1Dd4X028499; Sat, 26 Apr 2003 10:13:41 +0900 From: Ryuji Wakikawa To: "Hesham Soliman (EAB)" Subject: Re: [nemo] Multiple Egress vs multihoming Cc: "'Pascal Thubert (pthubert)'" , Chan-Wah Ng , IETF NEMO In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053807FEF7F8@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053807FEF7F8@Esealnt861.al.sw.ericsson.se> Message-Id: <20030426095944.2F2A.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.08 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sat, 26 Apr 2003 10:02:56 +0900 Content-Transfer-Encoding: 7bit Hi Hesham > => I'm interested to know how multiple care-ofs could > work in MIP. We did that for FMIP some time ago but > it was based on bi-casting for a short period (1 second). > I will comment on the rest of the email separately. There are some researches for multiple CoA on MIP. draft-montavont-mobileip-mmi-00.txt and draft-wakikawa-multiplecoa-00.txt regards, ryuji From nemo-admin@nal.motlabs.com Sun Apr 27 22:21:39 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06895 for ; Sun, 27 Apr 2003 22:21:35 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3S2KhFM003535; Mon, 28 Apr 2003 04:20:47 +0200 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3S2J0FM003521; Mon, 28 Apr 2003 04:19:02 +0200 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3S2IklY022712; Sun, 27 Apr 2003 22:18:48 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-1046.cisco.com [10.21.100.22]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA12694; Sun, 27 Apr 2003 22:18:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20030427132037.03f2a258@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Alexandru Petrescu From: Ralph Droms Subject: Re: [nemo] Link local addresses Cc: Erik Nordmark , Pekka =?iso-8859-1?Q? =?iso-8859-1?Q?P=E4=E4kk=F6nen?= ?= , Ole Troan , nemo@nal.motlabs.com In-Reply-To: <3EA6C451.6080508@nal.motlabs.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sun, 27 Apr 2003 15:03:44 -0400 At 06:50 PM 4/23/2003 +0200, Alexandru Petrescu wrote: >Erik Nordmark wrote: >>>Aha, DUID, so the discovery phase has already happened, so probably >>> no need for ll's. >> >>I can't parse. A client can form a DUID without any communication. See draft-ietf-dhc-dhcpv6-28.txt secion 8. > >Right. I've made the assumption that you mentioned DUID to indicate >that server identifies host by DUID, and that ll addresses were not >involved. LL addresses and DUID are orthogonal ... the requesting router (MR) and delegating router (HA) use LL unicast or multicast addresses in all DHCP message exchanges. The requesting router had a DUID that is invariant and is used in all DHCP transactions. >But I was referring specifically to messages that have as source or >destination the ll addresses of the host. It would be nice if those >messages were tunneled freely back and forth between MN and HA. > >For example, the Mobile IPv6 spec says: > > "However, packets addressed to the mobile node's link-local address > MUST NOT be tunneled to the mobile node." > >Later on it says: > > "Mobile nodes desiring to locate a DHCPv6 service may reverse tunnel > standard DHCPv6 packets to the home agent. Since these link-scope > packets can not be forwarded onto the home network it is necessary > for the home agent to either implement a DHCPv6 relay agent or a > DHCPv6 server function itself." > >My reading of the spec is: "because Mobile IPv6 forbids HA to forward >ll-scoped packets to the home link, then co-locate the HA with a >relay". This is a bit wrong: Mobile IPv6 does not forbid to tunnel >ll-scoped packets from MN to HA, it forbids only the other way around. > >I guess what I'm looking after is to have the HA separated from relay, >and to have the HA forward ll-scoped packets addressed to MN. The only way to separate the HA from the relay is if the HA acts as a bridge (or supports multi-link subnets) and forwards datagrams with LL unicast and multicast addresses between the link shared by the HA and the relay and the tunnel to the MR. >Or maybe I need to ask on the Mobile IP mailing list why the HA is >banned from forwarding the ll-scoped packets addressed to MN? Or ask >why does the HA intercept the ll-scoped packets when L=1, what does the >HA do with those packets if it must drop them anyways? > >Alex >GBU > From nemo-admin@nal.motlabs.com Mon Apr 28 02:54:04 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22431 for ; Mon, 28 Apr 2003 02:53:59 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3S6sGFM004557; Mon, 28 Apr 2003 08:54:16 +0200 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3S6rEFM004544 for ; Mon, 28 Apr 2003 08:53:15 +0200 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 28 Apr 2003 08:52:56 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3S6pEJM001096; Mon, 28 Apr 2003 08:51:14 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Apr 2003 08:53:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] Multiple Egress vs multihoming Message-ID: Thread-Topic: [nemo] Multiple Egress vs multihoming Thread-Index: AcMLkR4/wf9DtfpMSE+haiYwKwNnPgBwXHZA From: "Pascal Thubert (pthubert)" To: "Ryuji Wakikawa" Cc: "IETF NEMO" X-OriginalArrivalTime: 28 Apr 2003 06:53:05.0129 (UTC) FILETIME=[D1968D90:01C30D52] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h3S6rEFM004544 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 28 Apr 2003 07:53:04 +0100 Content-Transfer-Encoding: 8bit Hi Ryuji: I was not aware of your draft, nor could I find it in th eitf site or on google. Is that something you just submitted? Pascal > -----Original Message----- > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > Sent: samedi 26 avril 2003 03:03 > To: Hesham Soliman (EAB) > Cc: Pascal Thubert (pthubert); Chan-Wah Ng; IETF NEMO > Subject: Re: [nemo] Multiple Egress vs multihoming > > > Hi Hesham > > > => I'm interested to know how multiple care-ofs could > > work in MIP. We did that for FMIP some time ago but > > it was based on bi-casting for a short period (1 second). > > I will comment on the rest of the email separately. > > There are some researches for multiple CoA on MIP. > draft-montavont-mobileip-mmi-00.txt and > draft-wakikawa-multiplecoa-00.txt > > regards, > ryuji > From nemo-admin@nal.motlabs.com Mon Apr 28 04:53:17 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24391 for ; Mon, 28 Apr 2003 04:53:04 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3S8mrFM004975; Mon, 28 Apr 2003 10:48:53 +0200 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:3ffe:501:100c:d120::53]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3S8cdFM004923 for ; Mon, 28 Apr 2003 10:38:45 +0200 Received: from localhost (unknown [3ffe:501:100c:d210:202:b3ff:fe87:cb44]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id DC7535D019; Mon, 28 Apr 2003 17:38:03 +0900 (JST) Message-Id: <20030428.173704.41671487.watari@sfc.wide.ad.jp> To: pthubert@cisco.com Cc: ryuji@sfc.wide.ad.jp, nemo@nal.motlabs.com Subject: Re: [nemo] Multiple Egress vs multihoming From: Masafumi Watari In-Reply-To: References: Organization: Keio University X-Mailer: Mew version 4.0.53 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 28 Apr 2003 17:37:04 +0900 (JST) Content-Transfer-Encoding: 7bit Hello, You can find the draft in the URL below. http://www.ietf.org/internet-drafts/draft-wakikawa-mobileip-multiplecoa-00.txt regards, watari On Mon, 28 Apr 2003 07:53:04 +0100, "Pascal Thubert (pthubert)" wrote: > Hi Ryuji: > > I was not aware of your draft, nor could I find it in th eitf site or on > google. Is that something you just submitted? > > Pascal > > > -----Original Message----- > > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > > Sent: samedi 26 avril 2003 03:03 > > To: Hesham Soliman (EAB) > > Cc: Pascal Thubert (pthubert); Chan-Wah Ng; IETF NEMO > > Subject: Re: [nemo] Multiple Egress vs multihoming > > > > > > Hi Hesham > > > > > => I'm interested to know how multiple care-ofs could > > > work in MIP. We did that for FMIP some time ago but > > > it was based on bi-casting for a short period (1 second). > > > I will comment on the rest of the email separately. > > > > There are some researches for multiple CoA on MIP. > > draft-montavont-mobileip-mmi-00.txt and > > draft-wakikawa-multiplecoa-00.txt > > > > regards, > > ryuji > > > > From nemo-admin@nal.motlabs.com Mon Apr 28 18:48:08 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17928 for ; Mon, 28 Apr 2003 18:48:07 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3SMn9FM008294; Tue, 29 Apr 2003 00:49:09 +0200 Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [IPv6:3ffe:501:100c:d210:2e0:18ff:fe98:936d] (may be forged)) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3SMmBFM008286 for ; Tue, 29 Apr 2003 00:48:12 +0200 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pdd8831.tkyoac00.ap.so-net.ne.jp [218.221.136.49]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h3SMlm4W023403; Tue, 29 Apr 2003 07:47:49 +0900 Message-ID: From: Ryuji Wakikawa To: watari@sfc.wide.ad.jp Cc: pthubert@cisco.com, nemo@nal.motlabs.com Subject: Re: [nemo] Multiple Egress vs multihoming In-Reply-To: <20030428.173704.41671487.watari@sfc.wide.ad.jp> References: <20030428.173704.41671487.watari@sfc.wide.ad.jp> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 29 Apr 2003 07:48:59 +0900 Hi Pascal, and thanks watari. Let me summarize the draft briefly. We propose how to register multiple CoAs with single HoA. It is very simple, we assign new ID number to each interfaces on MN. MN always registers bindings with the ID. For example, - IF1 has CoA1 and ID1. - IF2 has CoA2 and ID2. single HoA +- MN-+ | | IF1 IF2 MN sends BUx with HoA, CoAx and IDx. HA will have multiple bindings of MN which are association of HoA and either CoA1 or CoA2. Then, HA searches BC with ID and HoA. Managements of each binding are done with correspondent ID respectively. This ID is not only used for multiple binding managements but also it could be used to associate some policies to a binding. For example, if MN want to receive TCP packets by IF1, it could send a policy (TCP->ID1) somehow (by MIP or by applications) to HA. Before HA can search BC with ID and HoA, it can decide which binding is used for outgoing packets by the policy. Policy parts are not discussed in the draft, yet. regards, ryuji At Mon, 28 Apr 2003 17:37:04 +0900 (JST), Masafumi Watari wrote: > > Hello, > > You can find the draft in the URL below. > > http://www.ietf.org/internet-drafts/draft-wakikawa-mobileip-multiplecoa-00.txt > > regards, > watari > > On Mon, 28 Apr 2003 07:53:04 +0100, > "Pascal Thubert (pthubert)" wrote: > > > Hi Ryuji: > > > > I was not aware of your draft, nor could I find it in th eitf site or on > > google. Is that something you just submitted? > > > > Pascal > > > > > -----Original Message----- > > > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > > > Sent: samedi 26 avril 2003 03:03 > > > To: Hesham Soliman (EAB) > > > Cc: Pascal Thubert (pthubert); Chan-Wah Ng; IETF NEMO > > > Subject: Re: [nemo] Multiple Egress vs multihoming > > > > > > > > > Hi Hesham > > > > > > > => I'm interested to know how multiple care-ofs could > > > > work in MIP. We did that for FMIP some time ago but > > > > it was based on bi-casting for a short period (1 second). > > > > I will comment on the rest of the email separately. > > > > > > There are some researches for multiple CoA on MIP. > > > draft-montavont-mobileip-mmi-00.txt and > > > draft-wakikawa-multiplecoa-00.txt > > > > > > regards, > > > ryuji > > > > > > > From nemo-admin@nal.motlabs.com Tue Apr 29 03:11:51 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09054 for ; Tue, 29 Apr 2003 03:11:42 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3T7BWFM010297; Tue, 29 Apr 2003 09:11:34 +0200 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3T7ATFM010289 for ; Tue, 29 Apr 2003 09:10:30 +0200 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 29 Apr 2003 09:10:11 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3T78Pti010051; Tue, 29 Apr 2003 09:08:29 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Apr 2003 09:09:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] Multiple Egress vs multihoming Message-ID: Thread-Topic: [nemo] Multiple Egress vs multihoming Thread-Index: AcMN2EsyJcvODu9ATyCcjCGlaY/4CgAQzzTQ From: "Pascal Thubert (pthubert)" To: "Ryuji Wakikawa" , Cc: X-OriginalArrivalTime: 29 Apr 2003 07:09:45.0377 (UTC) FILETIME=[50320910:01C30E1E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h3T7ATFM010289 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 29 Apr 2003 08:09:44 +0100 Content-Transfer-Encoding: 8bit Cool! It reminds me of your draft on network registration. Good ideas and a lot of work ahead :) Question: if we use your other draft, could the MR just have several IP addresses on its mobile network, and use that as ID? Does not seem to me we are short of these! To be honest, I believe that if we have to include multihoming in the picture for basic, you approach seems to be the most straightforward, leading to the simplest solution. At the expense of the support of home network, which pains me some, but I could accept it considering the rewards. If we do that, we are back to the case with several routes to a same network. Also, the various MR addresses may be owned by the same MR or by different MRs. So what? If you associate a distance to the advertisement, the HA can use that to select the best CareOf. As I said, it's yet an other (simple) routing protocol, and we need to understand how these routes are injected to the routing table of the HA, and then redistributed to the others (you need a metric that can be configured on the HA for instance). I would not use the Routing protocol of the AS of the HAs to do that, because I'd contain it inside a HA multicast group, even if that group spans outside of the AS (JetSet). You may recognize my initial comments on your other draft here :) Anyway, I believe that this protocol between HA is really a key for both your drafts to turn into a solution. Pascal > -----Original Message----- > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > Sent: mardi 29 avril 2003 00:49 > To: watari@sfc.wide.ad.jp > Cc: Pascal Thubert (pthubert); nemo@nal.motlabs.com > Subject: Re: [nemo] Multiple Egress vs multihoming > > > > Hi Pascal, and thanks watari. > > Let me summarize the draft briefly. > We propose how to register multiple CoAs with single HoA. > It is very simple, we assign new ID number to each interfaces > on MN. MN always registers bindings with the ID. > > For example, > - IF1 has CoA1 and ID1. > - IF2 has CoA2 and ID2. > > single HoA > +- MN-+ > | | > IF1 IF2 > > MN sends BUx with HoA, CoAx and IDx. HA will have multiple > bindings of MN which are association of HoA and either CoA1 > or CoA2. Then, HA searches BC with ID and HoA. Managements of > each binding are done with correspondent ID respectively. > > This ID is not only used for multiple binding managements but > also it could be used to associate some policies to a > binding. For example, if MN want to receive TCP packets by > IF1, it could send a policy > (TCP->ID1) somehow (by MIP or by applications) to HA. Before > HA can search BC with ID and HoA, it can decide which binding > is used for outgoing packets by the policy. > > Policy parts are not discussed in the draft, yet. > > regards, > ryuji > > At Mon, 28 Apr 2003 17:37:04 +0900 (JST), > Masafumi Watari wrote: > > > > Hello, > > > > You can find the draft in the URL below. > > > > > http://www.ietf.org/internet-drafts/draft-> wakikawa-mobileip-multipleco > > a-00.txt > > > > regards, > > watari > > > > On Mon, 28 Apr 2003 07:53:04 +0100, > > "Pascal Thubert (pthubert)" wrote: > > > > > Hi Ryuji: > > > > > > I was not aware of your draft, nor could I find it in th > eitf site > > > or on google. Is that something you just submitted? > > > > > > Pascal > > > > > > > -----Original Message----- > > > > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > > > > Sent: samedi 26 avril 2003 03:03 > > > > To: Hesham Soliman (EAB) > > > > Cc: Pascal Thubert (pthubert); Chan-Wah Ng; IETF NEMO > > > > Subject: Re: [nemo] Multiple Egress vs multihoming > > > > > > > > > > > > Hi Hesham > > > > > > > > > => I'm interested to know how multiple care-ofs could work in > > > > > MIP. We did that for FMIP some time ago but it was based on > > > > > bi-casting for a short period (1 second). I will > comment on the > > > > > rest of the email separately. > > > > > > > > There are some researches for multiple CoA on MIP. > > > > draft-montavont-mobileip-mmi-00.txt and > > > > draft-wakikawa-multiplecoa-00.txt > > > > > > > > regards, > > > > ryuji > > > > > > > > > > > From nemo-admin@nal.motlabs.com Tue Apr 29 05:13:29 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10712 for ; Tue, 29 Apr 2003 05:13:23 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3T96iFM010680; Tue, 29 Apr 2003 11:06:54 +0200 Received: from melanieb.vtt.fi (melanieb.vtt.fi [130.188.1.12]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3T94sFM010662 for ; Tue, 29 Apr 2003 11:05:14 +0200 Received: from elemail.ele.vtt.fi ([127.0.0.1]) by melanieb.vtt.fi (8.12.9/8.12.9) with ESMTP id h3T94dOt009138 for ; Tue, 29 Apr 2003 12:04:39 +0300 (EEST) Received: from ele4114.vtt.fi (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with ESMTP id MAA01828 for ; Tue, 29 Apr 2003 12:04:36 +0300 (EET DST) Message-Id: <4.3.2.7.2.20030429104417.00c07650@elemail.ele.vtt.fi> X-Sender: eleppa@elemail.ele.vtt.fi X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: nemo@nal.motlabs.com From: Pekka =?iso-8859-1?Q?Pääkkönen?= Subject: Re: [nemo] Link local addresses In-Reply-To: References: <"Your message with ID" <3E8991FD.6070400@nal.motlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 29 Apr 2003 12:04:27 +0200 At 17:31 1.4.2003 +0200, Erik Nordmark wrote: > > Aha. There's a particular phrase in the Mobile IPv6 that I would like > > to better understand. When describing the HA behaviour when > > intercepting packets, it says: > > > > "However, packets addressed to the mobile node's link-local address > > MUST NOT be tunneled to the mobile node." > > > > With the previous interpretation, that would become: > > > > "However, packets addressed to the mobile node's link-local address > > MUST NOT be forwarded to the mobile node, but they SHOULD (if L=1) > > be tunneled over the virtual tunnel interface MN-HA." > > > > Is this the intended meaning? > >No, since this is in the context of intercepting packets destined to >the mobile node. The need for DHCPv6 etc is to be able to _originate_ (not >forward) packets on the tunnel link which uses link-local addresses. > >The formation of link-local addresses for tunnels is described in RFC 2473. >Note that the MNs link-local address on the tunnel interface might be >different >than the link-local address the MN has on its non-tunnel interface when it is >at home, but they might also be the same. In any case it doesn't matter since >the link-local addresses only need to be unique per link and the tunnel is a >different link than the non-tunnel. In order for DHCPv6 tunneling to be possible, there should be link-local addresses configured on both the MR's and HA's tunnel-interface. These addresses are used on the inner IPv6 header when sending DHCPv6 packets through the MR-HA tunnel. So how to get the link-local addresses for the tunnel-interfaces. The link-local addresses configured on the non-tunnel interface could be configured also on the tunnel-interface at both MR and HA as mentioned by Erik. If those same link-local addresses are not used, then I agree that there should a specification somewhere on how to configure link-local addresses on the tunnel-interfaces. Pekka > > I think HA could operate a DHCPv6 agent over the tunnel interface, but > > only when MN is not at home, right? > >*If* there was a tunnel when the MN was at home it could oerate >DHCPv6 while at home. MIPv6 doesn't have a tunnel while at >home. >Point is this is not an issue for DHCPv6 - it is an issue whether the >tunnel exists or not. >If Nemo doesn't use a tunnel at home, presumably DHCPv6 for prefix delegation >could be used over the home link. > > > Also, I wonder whether it would be benefic that the entire scheme > > works with three separated entities: DHCPv6 agent, the HA and the BR > > in the home domain, on the same home link (as opposed to having all > > three entities co-located in the BR). > >What's a BR? MR? Border Router? >And DHCP can already have two levels - a relay agent and a server. > > Erik From nemo-admin@nal.motlabs.com Wed Apr 30 02:51:21 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23602 for ; Wed, 30 Apr 2003 02:51:03 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3U6fj3U025852; Wed, 30 Apr 2003 08:41:52 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3U6S23U025796 for ; Wed, 30 Apr 2003 08:28:09 +0200 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id VAA17181; Tue, 29 Apr 2003 21:54:23 -0600 (MDT) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h3U3sIL04951; Wed, 30 Apr 2003 05:54:18 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [nemo] Multiple Egress vs multihoming To: pthubert@cisco.com Cc: cwng@psl.com.sg, nemo@nal.motlabs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 30 Apr 2003 05:53:56 +0200 (CEST) > Same home Address for both makes a single static route, all the packets > to that route. If there's a distribution, it happens at BCE time, when > choosing between multiple parallel registrations, which is DYNAMIC, this > time. The problem is to have both MRs register to the same HA and make > as if there was a single MR with multiple CareOf (Tarzan). Or else you > need to coordinate the HAs, but it seems even a bigger change from MIPv6 > because of ND interaction. Pascal, I don't understand what you think is the "bigger change". Routing protocols already do such "coordination" in the the same route can arrive at the same router (within the home site) from different routers = HAs. So I don't understand why routing protocols are excluded from the thinking. What am I missing? One thing that matters in this multihoming picture which everybody seems to be omitting is the location of the Home Agents with respect to administrative boundaries. The case when one or more MRs (one with multiple interfaces/CoAs or two MRs each with a CoA) have separate HAs where the HAs are in the same admin domain can be made to work very well by having the HAs advertise the prefix route for the mobile network into the IGP. (Whether the HAs do this only when the tunnel is "up" or whether a routing protocol is run over the MR-HA tunnels is at some level a detail here.) The case (with one or more MRs as above) where the HAs are in different admin domains is quite different. If you want routing to scale you can't use a single prefix for the mobile network in this case since that prefix would need to get advertised in BGP. Essentially this case becomes the site multihoming problem; the mobile network is a site which has to ISPs - one running each HA. Thus to the extent that site multihoming is solved this is also something that the Nemo WG doesn't need to worry about. Erik From nemo-admin@nal.motlabs.com Wed Apr 30 02:52:20 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23672 for ; Wed, 30 Apr 2003 02:52:04 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3U5Z03U025368; Wed, 30 Apr 2003 07:35:08 +0200 Received: from shaku.sfc.wide.ad.jp ([IPv6:3ffe:501:100c:d210:2e0:18ff:fe98:936d]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3TMDT3U019952 for ; Wed, 30 Apr 2003 00:13:41 +0200 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pdd8831.tkyoac00.ap.so-net.ne.jp [218.221.136.49]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h3TMCM4W030305 for ; Wed, 30 Apr 2003 07:12:58 +0900 Message-ID: From: Ryuji Wakikawa To: nemo@nal.motlabs.com Subject: Re: [nemo] Multiple Egress vs multihoming In-Reply-To: References: User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 30 Apr 2003 07:10:13 +0900 Hi Pascal At Tue, 29 Apr 2003 08:09:44 +0100, Pascal Thubert (pthubert) wrote: > > Cool! Thanks! > It reminds me of your draft on network registration. Good ideas and a > lot of work ahead :) > > Question: if we use your other draft, could the MR just have several IP > addresses on its mobile network, and use that as ID? Does not seem to me > we are short of these! Yes, it can. BUT we need some changes due to 1 byte ID field. Easy solution for this is that MR calculates ID from MR-A. However, as you noted, it is possible to use MR-A as ID. If MR has two egress interfaces, then MR assigns two MR-A for each egress interfaces and uses MR-A as ID of egress interface. Since MR-A is stored in BU and also in binding cache, "ID field" in draft-multiplecoa is no longer needed for MR. It indicates no extensions is needed to the current draft-wakikawa-nemo-basic. > To be honest, I believe that if we have to include multihoming in the > picture for basic, you approach seems to be the most straightforward, > leading to the simplest solution. At the expense of the support of home > network, which pains me some, but I could accept it considering the > rewards. Our approach does not have "returning home", but I want to emphasize that our solution still have the optimization in terms of no-tunneling at home network. I try to summarize the differences between TJ/PSBU and mine when MR returns to home domain. If I miss something or misunderstand here, please correct me. TJ/PSBU Advantages 1. No tunneling 2. No binding management except for de-registration 3. Dynamic Routing (i.e. neighbour routers at home network learn a route of MR) Weak points 1. De-registration procedure is high cost and complicated. 2. Need to co-operate with IGP routing protocol to tell MR's route to neighbour routers. WAKIKAWA Advantages 1. No tunneling 2. No de-registration procedure 3. Not requirement to run IGP routing protocol at any time. Weak points 1. Binding Management even at home network 2. Static Routing (all packets are routed via HA) For better revision of my draft, I want to know whether management of binding instead of de-registration operations is real problem or not at home network. I want to know what a kind of advantages should a NEMO solution support? > If we do that, we are back to the case with several routes to a same > network. > > Also, the various MR addresses may be owned by the same MR or by > different MRs. So what? MR can own several MR addresses. IPv6 allows to assign various addresses to a same node/interface. > If you associate a distance to the advertisement, the HA can use that to > select the best CareOf. Yes. > As I said, it's yet an other (simple) routing protocol, and we need to > understand how these routes are injected to the routing table of the HA, > and then redistributed to the others (you need a metric that can be > configured on the HA for instance). I would not use the Routing protocol > of the AS of the HAs to do that, because I'd contain it inside a HA > multicast group, even if that group spans outside of the AS (JetSet). > > You may recognize my initial comments on your other draft here :) > > Anyway, I believe that this protocol between HA is really a key for both > your drafts to turn into a solution. Yes, I see your point of your earlier mail with better understanding now. I will consider all possible cases such as Tarzan, JetSet, Shinkansen, and doubleBed. I will update draft-wakikawa-basic-nemo before next IETF. # BTW, Shinkansen is name of express train in Japan. I don't know how # many people recognize what is Shinkansen :-p regards, ryuji > Pascal > > -----Original Message----- > > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > > Sent: mardi 29 avril 2003 00:49 > > To: watari@sfc.wide.ad.jp > > Cc: Pascal Thubert (pthubert); nemo@nal.motlabs.com > > Subject: Re: [nemo] Multiple Egress vs multihoming > > > > > > > > Hi Pascal, and thanks watari. > > > > Let me summarize the draft briefly. > > We propose how to register multiple CoAs with single HoA. > > It is very simple, we assign new ID number to each interfaces > > on MN. MN always registers bindings with the ID. > > > > For example, > > - IF1 has CoA1 and ID1. > > - IF2 has CoA2 and ID2. > > > > single HoA > > +- MN-+ > > | | > > IF1 IF2 > > > > MN sends BUx with HoA, CoAx and IDx. HA will have multiple > > bindings of MN which are association of HoA and either CoA1 > > or CoA2. Then, HA searches BC with ID and HoA. Managements of > > each binding are done with correspondent ID respectively. > > > > This ID is not only used for multiple binding managements but > > also it could be used to associate some policies to a > > binding. For example, if MN want to receive TCP packets by > > IF1, it could send a policy > > (TCP->ID1) somehow (by MIP or by applications) to HA. Before > > HA can search BC with ID and HoA, it can decide which binding > > is used for outgoing packets by the policy. > > > > Policy parts are not discussed in the draft, yet. > > > > regards, > > ryuji > > > > At Mon, 28 Apr 2003 17:37:04 +0900 (JST), > > Masafumi Watari wrote: > > > > > > Hello, > > > > > > You can find the draft in the URL below. > > > > > > > > http://www.ietf.org/internet-drafts/draft-> > wakikawa-mobileip-multipleco > > > a-00.txt > > > > > > regards, > > > watari > > > > > > On Mon, 28 Apr 2003 07:53:04 +0100, > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > Hi Ryuji: > > > > > > > > I was not aware of your draft, nor could I find it in th > > eitf site > > > > or on google. Is that something you just submitted? > > > > > > > > Pascal > > > > > > > > > -----Original Message----- > > > > > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > > > > > Sent: samedi 26 avril 2003 03:03 > > > > > To: Hesham Soliman (EAB) > > > > > Cc: Pascal Thubert (pthubert); Chan-Wah Ng; IETF NEMO > > > > > Subject: Re: [nemo] Multiple Egress vs multihoming > > > > > > > > > > > > > > > Hi Hesham > > > > > > > > > > > => I'm interested to know how multiple care-ofs could work in > > > > > > MIP. We did that for FMIP some time ago but it was based on > > > > > > bi-casting for a short period (1 second). I will > > comment on the > > > > > > rest of the email separately. > > > > > > > > > > There are some researches for multiple CoA on MIP. > > > > > draft-montavont-mobileip-mmi-00.txt and > > > > > draft-wakikawa-multiplecoa-00.txt > > > > > > > > > > regards, > > > > > ryuji > > > > > > > > > > > > > > > From nemo-admin@nal.motlabs.com Wed Apr 30 03:14:46 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24073 for ; Wed, 30 Apr 2003 03:14:33 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3U7A23U026104; Wed, 30 Apr 2003 09:10:02 +0200 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3U78i3U026059 for ; Wed, 30 Apr 2003 09:08:52 +0200 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 30 Apr 2003 09:08:10 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3U6EsbT016108 for ; Wed, 30 Apr 2003 08:16:16 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Apr 2003 08:16:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: FW: [nemo] Multiple Egress vs multihoming Message-ID: Thread-Topic: [nemo] Multiple Egress vs multihoming Thread-Index: AcMN2EsyJcvODu9ATyCcjCGlaY/4CgAQzzTQADEhYhA= From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 30 Apr 2003 06:16:46.0286 (UTC) FILETIME=[13B8FEE0:01C30EE0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h3U78i3U026059 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 30 Apr 2003 07:16:45 +0100 Content-Transfer-Encoding: 8bit Seems this one was never published by the nemo list ??? > -----Original Message----- > From: Pascal Thubert (pthubert) > Sent: mardi 29 avril 2003 09:10 > To: 'Ryuji Wakikawa'; 'watari@sfc.wide.ad.jp' > Cc: 'nemo@nal.motlabs.com' > Subject: RE: [nemo] Multiple Egress vs multihoming > > > Cool! > > It reminds me of your draft on network registration. Good > ideas and a lot of work ahead :) > > Question: if we use your other draft, could the MR just have > several IP addresses on its mobile network, and use that as > ID? Does not seem to me we are short of these! > > To be honest, I believe that if we have to include > multihoming in the picture for basic, you approach seems to > be the most straightforward, leading to the simplest > solution. At the expense of the support of home network, > which pains me some, but I could accept it considering the rewards. > > If we do that, we are back to the case with several routes to > a same network. > > Also, the various MR addresses may be owned by the same MR or > by different MRs. So what? > > If you associate a distance to the advertisement, the HA can > use that to select the best CareOf. > > As I said, it's yet an other (simple) routing protocol, and > we need to understand how these routes are injected to the > routing table of the HA, and then redistributed to the others > (you need a metric that can be configured on the HA for > instance). I would not use the Routing protocol of the AS of > the HAs to do that, because I'd contain it inside a HA > multicast group, even if that group spans outside of the AS (JetSet). > > You may recognize my initial comments on your other draft here :) > > Anyway, I believe that this protocol between HA is really a > key for both your drafts to turn into a solution. > > Pascal > > -----Original Message----- > > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > > Sent: mardi 29 avril 2003 00:49 > > To: watari@sfc.wide.ad.jp > > Cc: Pascal Thubert (pthubert); nemo@nal.motlabs.com > > Subject: Re: [nemo] Multiple Egress vs multihoming > > > > > > > > Hi Pascal, and thanks watari. > > > > Let me summarize the draft briefly. > > We propose how to register multiple CoAs with single HoA. > > It is very simple, we assign new ID number to each interfaces > > on MN. MN always registers bindings with the ID. > > > > For example, > > - IF1 has CoA1 and ID1. > > - IF2 has CoA2 and ID2. > > > > single HoA > > +- MN-+ > > | | > > IF1 IF2 > > > > MN sends BUx with HoA, CoAx and IDx. HA will have multiple > > bindings of MN which are association of HoA and either CoA1 > > or CoA2. Then, HA searches BC with ID and HoA. Managements of > > each binding are done with correspondent ID respectively. > > > > This ID is not only used for multiple binding managements but > > also it could be used to associate some policies to a > > binding. For example, if MN want to receive TCP packets by > > IF1, it could send a policy > > (TCP->ID1) somehow (by MIP or by applications) to HA. Before > > HA can search BC with ID and HoA, it can decide which binding > > is used for outgoing packets by the policy. > > > > Policy parts are not discussed in the draft, yet. > > > > regards, > > ryuji > > > > At Mon, 28 Apr 2003 17:37:04 +0900 (JST), > > Masafumi Watari wrote: > > > > > > Hello, > > > > > > You can find the draft in the URL below. > > > > > > > > http://www.ietf.org/internet-drafts/draft-> > > wakikawa-mobileip-multipleco > > > a-00.txt > > > > > > regards, > > > watari > > > > > > On Mon, 28 Apr 2003 07:53:04 +0100, > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > Hi Ryuji: > > > > > > > > I was not aware of your draft, nor could I find it in th > > eitf site > > > > or on google. Is that something you just submitted? > > > > > > > > Pascal > > > > > > > > > -----Original Message----- > > > > > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > > > > > Sent: samedi 26 avril 2003 03:03 > > > > > To: Hesham Soliman (EAB) > > > > > Cc: Pascal Thubert (pthubert); Chan-Wah Ng; IETF NEMO > > > > > Subject: Re: [nemo] Multiple Egress vs multihoming > > > > > > > > > > > > > > > Hi Hesham > > > > > > > > > > > => I'm interested to know how multiple care-ofs > could work in > > > > > > MIP. We did that for FMIP some time ago but it was based on > > > > > > bi-casting for a short period (1 second). I will > > comment on the > > > > > > rest of the email separately. > > > > > > > > > > There are some researches for multiple CoA on MIP. > > > > > draft-montavont-mobileip-mmi-00.txt and > > > > > draft-wakikawa-multiplecoa-00.txt > > > > > > > > > > regards, > > > > > ryuji > > > > > > > > > > > > > > > > From nemo-admin@nal.motlabs.com Wed Apr 30 03:34:09 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24469 for ; Wed, 30 Apr 2003 03:33:55 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3U7QV3U026434; Wed, 30 Apr 2003 09:26:36 +0200 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3U7NQ3U026409 for ; Wed, 30 Apr 2003 09:23:33 +0200 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 30 Apr 2003 09:23:01 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3U7LJ9m024485; Wed, 30 Apr 2003 09:21:20 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Apr 2003 09:23:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] Multiple Egress vs multihoming Message-ID: Thread-Topic: [nemo] Multiple Egress vs multihoming Thread-Index: AcMO0vlR46HxNBPIS8SmGOWJzYvWnwADOSbg From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" Cc: , , "Ryuji Wakikawa" X-OriginalArrivalTime: 30 Apr 2003 07:23:10.0921 (UTC) FILETIME=[5AC00B90:01C30EE9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h3U7NQ3U026409 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 30 Apr 2003 08:23:06 +0100 Content-Transfer-Encoding: 8bit Hi Erik, We did not really omit that case (ain't it JetSet, see below:). The note you attach was about static routes. The topic there was whether we wanted to enter the domain of dynamic routes between the HA and the MR. The discussion was that dynamic routes seem to be quite inevitable if you want some forms of multihoming; as a result multihoming => complex basic spec, slow to mature. But that's the current req draft. I initially proposed to work on a quick bare bones solution first, based on TJ's draft with no dynamic protocol and no multihoming, but did not get much success. I'd be very happy to include multihoming and dynamic networks, but then, why not things like IPv4 traversal and RO, where we are actually more mature? I resent tihs morning a mail to Ryuji that I could not find in my nemo folder, just in case it was lost. If the HAs were coordinated by the local (legacy) IGP: A) Frequent movement of many routers may disrupt the workings of the IGP in the HA AS B) The HA coordination would be limited to one AS (your point, right?) C) We'd loose the on-demand flavour of ND (if the 'wrong HA' does not have a neighbor entry for the MR, it will look it up, and eventually get an other HA, which is actually a next hop). I like this half proactive, half reactive behaviour when it comes to a high rate of movemement. D) If there are other routers in the AS then the HAs and ARs then we'd loose the 'self-contained' aspect as well and propagate the impact of MR mobility throughout a larger space. Plainly wouldn't scale with legacy IGPs. The question of a separate layer 3 protocol between the HAs, was in my mail (3/16) with my comments on Ryuji's draft. I guess that the idea of such a protocol is already present in MIP or NSIIM as well? "additional work could be required to cover the case of multiple HAs. In MIPv6, the detection of multiple registration id done by DAD on the home network. Since there is no home network, the detection of double registration has to be done at the routing protocol level (When the same net is registered to a 2nd, different HA, it should reject it if it got a route from the first HA... Something like that. Note that as we discussed earlier, the fine grained info should be contained in the HAs." In the design list (4/11) I also pointed out that a MANET type of protocol could be used for the dynamic solution: "I believe it's hard to include a dynamic routing protocol without this kind of prior research. Also, some routing protocols may scale better than others. Maybe we could use a MANET derived routing protocol such as OLSR. Maybe we could pass the routing info in the BU like in PSBU or draft-wakikawa..." I proposed (4/29) that this protocol be run on a multicast group regardless of the admin boundaries: "it's yet an other (simple) routing protocol, and we need to understand how these routes are injected to the routing table of the HA, and then redistributed to the others (you need a metric that can be configured on the HA for instance). I would not use the Routing protocol of the AS of the HAs to do that, because I'd contain it inside a HA multicast group, even if that group spans outside of the AS (JetSet)" You see where this is all leading to: A) A topology as proposed earlier in the MIP list (was that Greg?) with no home network. B) A virtual network that encompasses a group of commonly administered Mobile Networks. C) HAs organised in multicast groups, one per virtual network, many of them. D) A routing protocol, maybe with a MANET origin, between the HAs, one instance per multicast group E) A registration derived from Ruyji's draft, with maybe a MANET twist to interoperate with the HA routing protocol F) Still from Ruyji's drafts, one MNET address per careOf, a number of MNET addresses per MR. G) Potentially a new form of anycast, "anyone in a multicast group", for DHAAD related stuff. From the bare bones approach, it's quite a quantum leap. Far from an obvious adaptation of MIPv6 as bare bones was to be. Much more interesting to design, though. What should we do? Voila! Pascal > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: mercredi 30 avril 2003 05:54 > To: Pascal Thubert (pthubert) > Cc: cwng@psl.com.sg; nemo@nal.motlabs.com > Subject: RE: [nemo] Multiple Egress vs multihoming > > > > Same home Address for both makes a single static route, all the > > packets to that route. If there's a distribution, it happens at BCE > > time, when choosing between multiple parallel > registrations, which is > > DYNAMIC, this time. The problem is to have both MRs register to the > > same HA and make as if there was a single MR with multiple CareOf > > (Tarzan). Or else you need to coordinate the HAs, but it > seems even a > > bigger change from MIPv6 because of ND interaction. > > Pascal, > > I don't understand what you think is the "bigger change". > > Routing protocols already do such "coordination" in the the > same route can arrive at the same router (within the home > site) from different routers = HAs. > > So I don't understand why routing protocols are excluded from > the thinking. > > What am I missing? > > One thing that matters in this multihoming picture which > everybody seems to be omitting is the location of the Home > Agents with respect to administrative boundaries. > > The case when one or more MRs (one with multiple > interfaces/CoAs or two MRs each with a CoA) have separate HAs > where the HAs are in the same admin domain can be made to > work very well by having the HAs advertise the prefix route > for the mobile network into the IGP. (Whether the HAs do this > only when the tunnel is "up" or whether a routing protocol is > run over the MR-HA tunnels is at some level a detail here.) > > The case (with one or more MRs as above) where the HAs are in > different admin domains is quite different. If you want > routing to scale you can't use a single prefix for the mobile > network in this case since that prefix would need to get > advertised in BGP. > Essentially this case becomes the site multihoming problem; > the mobile network is a site which has to ISPs - one running > each HA. Thus to the extent that site multihoming is solved > this is also something that the Nemo WG doesn't need to worry about. > > Erik > > From nemo-admin@nal.motlabs.com Wed Apr 30 06:47:47 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28140 for ; Wed, 30 Apr 2003 06:47:30 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3UAaW3U028361; Wed, 30 Apr 2003 12:36:45 +0200 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3UAWP3U028341 for ; Wed, 30 Apr 2003 12:32:33 +0200 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 30 Apr 2003 12:31:50 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3UAU1ue029398; Wed, 30 Apr 2003 12:30:02 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Apr 2003 12:31:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] Multiple Egress vs multihoming Message-ID: Thread-Topic: [nemo] Multiple Egress vs multihoming Thread-Index: AcMO9KkHVgB0vSkQQvOb4dqcVSaFagADUamA From: "Pascal Thubert (pthubert)" To: "Ryuji Wakikawa" , X-OriginalArrivalTime: 30 Apr 2003 10:31:52.0118 (UTC) FILETIME=[B6B59D60:01C30F03] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h3UAWP3U028341 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 30 Apr 2003 11:31:51 +0100 Content-Transfer-Encoding: 8bit > If MR has two egress interfaces, then MR assigns two MR-A for > each egress interfaces and uses MR-A as ID of egress > interface. Since MR-A is stored in BU and also in binding > cache, "ID field" in draft-multiplecoa is no longer needed > for MR. It indicates no extensions is needed to the current > draft-wakikawa-nemo-basic. nice > > > Also, the various MR addresses may be owned by the same MR or by > > different MRs. So what? > > MR can own several MR addresses. IPv6 allows to assign > various addresses to a same node/interface. > My point was that if the ID is a MNET address as I proposed, and if, as a consequence, we have a different address on the MNET per registration (per careof), it should make no difference whether there's a single MR or several of them. I think it's a nice feature, for the shinkansen case... > I will consider all possible cases such as Tarzan, JetSet, > Shinkansen, and doubleBed. I will update > draft-wakikawa-basic-nemo before next IETF. > We have to talk about the L3 HA-HA protocol; and whether the MRs need to be involved as well. ThatMUST be in your draft too, otherwise you're limited to a single HA, which sadly I'm not ready to accept ;) > # BTW, Shinkansen is name of express train in Japan. I don't > know how # many people recognize what is Shinkansen :-p I thought there were more people knowing it then TGV... Though there are a lot of French and France resident in the ML :) Pascal From nemo-admin@nal.motlabs.com Wed Apr 30 09:15:54 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01761 for ; Wed, 30 Apr 2003 09:15:41 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3UD8w3U029653; Wed, 30 Apr 2003 15:08:58 +0200 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3UD7X3U029632; Wed, 30 Apr 2003 15:07:43 +0200 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h3UD7DDm013229; Wed, 30 Apr 2003 06:07:19 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h3UD7A2J001049; Wed, 30 Apr 2003 08:07:11 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 91F5A2EC86; Wed, 30 Apr 2003 15:07:09 +0200 (CEST) Message-ID: <3EAFCA7C.6070602@nal.motlabs.com> From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@nal.motlabs.com Cc: nemo-admin@nal.motlabs.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [nemo] administrative, again Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 30 Apr 2003 15:07:08 +0200 Content-Transfer-Encoding: 7bit Hi all, Sorry for this late notice. An unexpected power outage relatively up in the grid (when looked from here) occured and as such we must stop the jessica mail server serving the nemo mailing list. This mail is sent on battery power so those who're reached within the next 5 minutes will know; Sorry again for this late notice and when power is up I'll send anthoter notice. Alex GBU From nemo-admin@nal.motlabs.com Wed Apr 30 09:28:13 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02168 for ; Wed, 30 Apr 2003 09:27:55 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3UDP83U029847; Wed, 30 Apr 2003 15:25:08 +0200 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3UDHT3U029785; Wed, 30 Apr 2003 15:17:34 +0200 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h3UDHGc9000238; Wed, 30 Apr 2003 06:17:18 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h3UDH9QL014010; Wed, 30 Apr 2003 08:17:10 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id E9EA42EC86; Wed, 30 Apr 2003 15:17:08 +0200 (CEST) Message-ID: <3EAFCCD4.4080804@nal.motlabs.com> From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo-admin@nal.motlabs.com Cc: nemo@nal.motlabs.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [nemo] list back again Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 30 Apr 2003 15:17:08 +0200 Content-Transfer-Encoding: 7bit Hi, list is back, power is up, everything is fine. From nemo-admin@nal.motlabs.com Wed Apr 30 19:00:16 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28788 for ; Wed, 30 Apr 2003 19:00:15 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3UMuv3U002521; Thu, 1 May 2003 00:56:59 +0200 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h3UMtl3U002511 for ; Thu, 1 May 2003 00:55:48 +0200 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA19822; Wed, 30 Apr 2003 16:55:43 -0600 (MDT) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h3UMtVL25215; Thu, 1 May 2003 00:55:31 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [nemo] Multiple Egress vs multihoming To: "Pascal Thubert (pthubert)" Cc: Erik Nordmark , cwng@psl.com.sg, nemo@nal.motlabs.com, Ryuji Wakikawa In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 30 Apr 2003 21:54:42 +0200 (CEST) > We did not really omit that case (ain't it JetSet, see below:). The note > you attach was about static routes. The topic there was whether we > wanted to enter the domain of dynamic routes between the HA and the MR. > The discussion was that dynamic routes seem to be quite inevitable if > you want some forms of multihoming; as a result multihoming => complex > basic spec, slow to mature. I completely fail to understand how you come to this conclusion. The basic spec would say how to establish the HA-MR tunnels and can be utterly silent on the fact that existing routing protocols can run over these tunnels. Some people call this modularity. > If the HAs were coordinated by the local (legacy) IGP: > > A) Frequent movement of many routers may disrupt the workings of the IGP > in the HA AS Unless you have a very different model than I have this isn't true. The HA<->MR tunnel getting a different CoA would not be visible to the routing protocol at all. > B) The HA coordination would be limited to one AS (your point, right?) Yes. And it might be further limited if OSPF or IS-IS areas are used within one domain in order to aggregate internal routing. > C) We'd loose the on-demand flavour of ND (if the 'wrong HA' does not > have a neighbor entry for the MR, it will look it up, and eventually get > an other HA, which is actually a next hop). I like this half proactive, > half reactive behaviour when it comes to a high rate of movemement. You seem to have either a conceptual model or an implementation model of how Nemo interacts with IP routing in a HA and I don't understand. IP routing reacts to interface changes and the tunnels are interfaces (conceptually, and they have an ifindex in the MIBs), thus the IGP would take care of the tunnels goming and going. Thus unless I misunderstand what you mean with "on-demand" the on-demand nature seems to be orthogonal with the IGP vs. not-IGP. > D) If there are other routers in the AS then the HAs and ARs then we'd > loose the 'self-contained' aspect as well and propagate the impact of MR > mobility throughout a larger space. Plainly wouldn't scale with legacy > IGPs. Nope. See my answer to A). > The question of a separate layer 3 protocol between the HAs, was in my > mail (3/16) with my comments on Ryuji's draft. I guess that the idea of > such a protocol is already present in MIP or NSIIM as well? MIP has a protocol for coordinating between HAs for different Home Addresses? For the same Home Address? I've never seen such a thing. > "additional work could be required to cover the case of multiple HAs. In > MIPv6, the detection of multiple registration id done by DAD on the home > network. Since there is no home network, the detection of double > registration has to be done at the routing protocol level (When the same > net is registered to a 2nd, different HA, it should reject it if it got > a route from the first HA... Something like that. Note that as we > discussed earlier, the fine grained info should be contained in the > HAs." We seem to be talking about different models. In my model each MR (or the different interfaces on the single MR) have a different home address, even though there is a single prefix for the mobile network. The above paragraph as well as A) and D) makes me believe you have a completely different model in mind where the IGP runs without tunnels between MR and HA. Further, in routing protocols there is an issue of who can advertise which routes; this is solved by configuration today even though it is typically done at IGP/EGP boundaries and not inside an IGP. (But the Magma anycast case is one where IGP routers would be configured with which routes to accept from which peer.) > In the design list (4/11) I also pointed out that a MANET type of > protocol could be used for the dynamic solution: But that is for the "no tunnels" model, right? > I proposed (4/29) that this protocol be run on a multicast group > regardless of the admin boundaries: > "it's yet an other (simple) routing protocol, and we need to understand > how these routes are injected to the routing table of the HA, and then > redistributed to the others (you need a metric that can be configured on > the HA for instance). I would not use the Routing protocol of the AS of > the HAs to do that, because I'd contain it inside a HA multicast group, > even if that group spans outside of the AS (JetSet)" Once we actually understand the high-level model for IGP+tunnels (what I'm advocating as a way to handle multihoming) there are at least two different ways to do the details: 1. Actually run a routing protocol over the tunnels between MR and HA. This consumes some background traffic (for the hello protocol) but the benefit is that the hello protocol will detect when there is no longer bidirectional connectivity over a tunnel. 2. Not running a routing protocol over the tunnel but instead have the establishment of the tunnel make the HA inject the route into the IGP. > You see where this is all leading to: No, I don't see because we are making different assumptions and have different models in mind. I don't think we want a different routing protocol for this but instead reuse existing ones. (There is a potential research topic on how to do routing in a network where lots of things move, so here I am limiting my concerns to the IETF more short-term issues.) > A) A topology as proposed earlier in the MIP list (was that Greg?) with > no home network. I believe the prefix(es) assigned to a mobile network have a home in the sense that they fall within a shorter prefix. And the HoA for each MR's interface may fall in a physical home network or a virtual home network. > B) A virtual network that encompasses a group of commonly administered > Mobile Networks. On what scope? Isn't this the same as the prefix I refer to above? > C) HAs organised in multicast groups, one per virtual network, many of > them. Here is where you are defining a new routing protocol, right? > D) A routing protocol, maybe with a MANET origin, between the HAs, one > instance per multicast group > E) A registration derived from Ruyji's draft, with maybe a MANET twist > to interoperate with the HA routing protocol > F) Still from Ruyji's drafts, one MNET address per careOf, a number of > MNET addresses per MR. > G) Potentially a new form of anycast, "anyone in a multicast group", for > DHAAD related stuff. For G) I think you are conflating the issues around the HoA for the MRs and the routing advertisement for the mobile network. DHAAD is useful for the former, but the routing stuff could be layered cleanly on top of that. > From the bare bones approach, it's quite a quantum leap. Far from an > obvious adaptation of MIPv6 as bare bones was to be. Much more > interesting to design, though. What should we do? I don't think we need any of what you are proposing because I think the WG should do the basic tunnels and allow routing to be layered on top of this. That avoids having to re-invent IP routing and potentially do it poorly. Erik From test-admin@nal.motlabs.com Wed Apr 30 23:05:32 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03887 for ; Wed, 30 Apr 2003 23:05:28 -0400 (EDT) Received: from jessica.nal.motlabs.com (localhost [127.0.0.1]) by jessica.nal.motlabs.com (8.12.9/8.12.9) with ESMTP id h413803U005642 for ; Thu, 1 May 2003 05:08:01 +0200 Date: Thu, 1 May 2003 05:08:00 +0200 Message-Id: <200305010308.h413803U005642@jessica.nal.motlabs.com> Subject: nal.motlabs.com mailing list memberships reminder From: mailman-owner@jessica.nal.motlabs.com To: nemo-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: test-admin@nal.motlabs.com Errors-To: test-admin@nal.motlabs.com X-BeenThere: test@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk This is a reminder, sent out once a month, about your nal.motlabs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nemo-request@nal.motlabs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@jessica.nal.motlabs.com. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@nal.motlabs.com pupafo http://www.nal.motlabs.com/mailman/options/nemo/nemo-archive%40lists.ietf.org