From nemo-admin@ietf.org Thu Oct 2 10:51:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23327 for ; Thu, 2 Oct 2003 10:51:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54nF-0003g1-Q0; Thu, 02 Oct 2003 10:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54mR-0003dl-Vk for nemo@optimus.ietf.org; Thu, 02 Oct 2003 10:50:12 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22966; Thu, 2 Oct 2003 10:50:01 -0400 (EDT) Message-Id: <200310021450.KAA22966@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 02 Oct 2003 10:50:00 -0400 Subject: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-01.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network Author(s) : J. Jeong et al. Filename : draft-jeong-nemo-ro-ndproxy-01.txt Pages : 13 Date : 2003-10-2 This document specifies a mechanism for enabling mobile nodes in IPv6 mobile network to perform route optimization. The route optimization is possible because mobile router relays the prefix of its Care-of address to its mobile nodes by playing the role of ND-proxy. Through binding updates associated with the network prefix of an access network, the mobile nodes can perform route optimization. In addition, this document explains how mobile nodes can optimize its DNS name resolution through RA-based DNS discovery. By announcing the address of local recursive DNS server, mobile router allows mobile nodes to optimize their DNS name resolution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-01.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-jeong-nemo-ro-ndproxy-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-jeong-nemo-ro-ndproxy-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-2105759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jeong-nemo-ro-ndproxy-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-jeong-nemo-ro-ndproxy-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-2105759.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Thu Oct 2 10:51:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23342 for ; Thu, 2 Oct 2003 10:51:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54nP-0003id-0X for nemo-archive@odin.ietf.org; Thu, 02 Oct 2003 10:51:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92EpAgU014284 for nemo-archive@odin.ietf.org; Thu, 2 Oct 2003 10:51:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54nO-0003iJ-Oz for nemo-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 10:51:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23290 for ; Thu, 2 Oct 2003 10:51:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54nM-0001VM-00 for nemo-web-archive@ietf.org; Thu, 02 Oct 2003 10:51:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A54nL-0001VF-00 for nemo-web-archive@ietf.org; Thu, 02 Oct 2003 10:51:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54nF-0003g1-Q0; Thu, 02 Oct 2003 10:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54mR-0003dl-Vk for nemo@optimus.ietf.org; Thu, 02 Oct 2003 10:50:12 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22966; Thu, 2 Oct 2003 10:50:01 -0400 (EDT) Message-Id: <200310021450.KAA22966@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 02 Oct 2003 10:50:00 -0400 Subject: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-01.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network Author(s) : J. Jeong et al. Filename : draft-jeong-nemo-ro-ndproxy-01.txt Pages : 13 Date : 2003-10-2 This document specifies a mechanism for enabling mobile nodes in IPv6 mobile network to perform route optimization. The route optimization is possible because mobile router relays the prefix of its Care-of address to its mobile nodes by playing the role of ND-proxy. Through binding updates associated with the network prefix of an access network, the mobile nodes can perform route optimization. In addition, this document explains how mobile nodes can optimize its DNS name resolution through RA-based DNS discovery. By announcing the address of local recursive DNS server, mobile router allows mobile nodes to optimize their DNS name resolution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-01.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-jeong-nemo-ro-ndproxy-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-jeong-nemo-ro-ndproxy-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-2105759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jeong-nemo-ro-ndproxy-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-jeong-nemo-ro-ndproxy-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-2105759.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Thu Oct 2 11:44:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27570 for ; Thu, 2 Oct 2003 11:44:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55cX-0007Lq-8c; Thu, 02 Oct 2003 11:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55cG-0007L8-PO for nemo@optimus.ietf.org; Thu, 02 Oct 2003 11:43:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27485 for ; Thu, 2 Oct 2003 11:43:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A55cF-0002Xs-00 for nemo@ietf.org; Thu, 02 Oct 2003 11:43:43 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A55cF-0002XB-00 for nemo@ietf.org; Thu, 02 Oct 2003 11:43:43 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Oct 2003 17:41:38 +0200 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h92Fh8EX005095; Thu, 2 Oct 2003 17:43:08 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 2 Oct 2003 16:43:11 +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" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Oct 2003 16:43:10 +0100 Message-ID: Thread-Topic: some inquiries Thread-Index: AcOI8mOc7xbbHGPSRJWlHG2fKLpIzQACDJCQ From: "Pascal Thubert (pthubert)" To: "KAI CHEONG WONG" Cc: X-OriginalArrivalTime: 02 Oct 2003 15:43:11.0284 (UTC) FILETIME=[E2636740:01C388FB] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: some inquiries Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: KAI CHEONG WONG [mailto:vincentkcwong@hotmail.com] > Sent: jeudi 2 octobre 2003 16:35 > To: Pascal Thubert (pthubert) > Subject: some inquiries >=20 > Dear sir, >=20 > I am an university student in australia. Iam doing a research on the problem of NEMO basic > potocol whch is the drawback of double crossing over tunnel. It happens when LFN decides to > communicate with VMN in the same subnetwork such as in the train. It is because the LFN dont > know the VMN is on the same link, that means LFN will send packets to the MR which forwards > packets to its HA crossing the tunnel. After the HA received the packets, it will send back > to the MR crossing the same tunnel again. It leads to the inefficiency. However, i have read > the draft-ietf, it seems doesnt mention about that problem. I would like to know more about > the following, >=20 > 1, Why there exist the bi-directional tunnel between the MR and its HA insteads of uni- > directional tunnel? Can MNN such as VMN send the packets to CN using VMN's home address as > the source address and send it directly through the foreign link which its attaching ? Normally VMN creates a connected route to the visited prefix. If the destination is on that prefix, then the routing should forward the packet on link as opposed to via the tunnel, and SAS should make the VMN select the careof as source. All normal business by RFC 3484. We thought of writing down a few words on that but did not because it all goes by standards. >=20 > 2, What is the FA of the VMN which attaching to the mobile network? >=20 No FA in MIPv6... > 3, What is the solution(based on NEMO basic protocol) which should clearly address the > problem of double crossing over tunnel? >=20 In a more complex topology behind the MR, it would be Route optimization, if the LFN supports CN. Pascal From exim@www1.ietf.org Thu Oct 2 11:44:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27586 for ; Thu, 2 Oct 2003 11:44:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55cb-0007N4-PD for nemo-archive@odin.ietf.org; Thu, 02 Oct 2003 11:44:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Fi510028328 for nemo-archive@odin.ietf.org; Thu, 2 Oct 2003 11:44:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55cb-0007Mp-LE for nemo-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 11:44:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27531 for ; Thu, 2 Oct 2003 11:43:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A55ca-0002YT-00 for nemo-web-archive@ietf.org; Thu, 02 Oct 2003 11:44:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A55ca-0002YQ-00 for nemo-web-archive@ietf.org; Thu, 02 Oct 2003 11:44:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55cX-0007Lq-8c; Thu, 02 Oct 2003 11:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55cG-0007L8-PO for nemo@optimus.ietf.org; Thu, 02 Oct 2003 11:43:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27485 for ; Thu, 2 Oct 2003 11:43:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A55cF-0002Xs-00 for nemo@ietf.org; Thu, 02 Oct 2003 11:43:43 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A55cF-0002XB-00 for nemo@ietf.org; Thu, 02 Oct 2003 11:43:43 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Oct 2003 17:41:38 +0200 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h92Fh8EX005095; Thu, 2 Oct 2003 17:43:08 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 2 Oct 2003 16:43:11 +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" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Oct 2003 16:43:10 +0100 Message-ID: Thread-Topic: some inquiries Thread-Index: AcOI8mOc7xbbHGPSRJWlHG2fKLpIzQACDJCQ From: "Pascal Thubert (pthubert)" To: "KAI CHEONG WONG" Cc: X-OriginalArrivalTime: 02 Oct 2003 15:43:11.0284 (UTC) FILETIME=[E2636740:01C388FB] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: some inquiries Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: KAI CHEONG WONG [mailto:vincentkcwong@hotmail.com] > Sent: jeudi 2 octobre 2003 16:35 > To: Pascal Thubert (pthubert) > Subject: some inquiries >=20 > Dear sir, >=20 > I am an university student in australia. Iam doing a research on the problem of NEMO basic > potocol whch is the drawback of double crossing over tunnel. It happens when LFN decides to > communicate with VMN in the same subnetwork such as in the train. It is because the LFN dont > know the VMN is on the same link, that means LFN will send packets to the MR which forwards > packets to its HA crossing the tunnel. After the HA received the packets, it will send back > to the MR crossing the same tunnel again. It leads to the inefficiency. However, i have read > the draft-ietf, it seems doesnt mention about that problem. I would like to know more about > the following, >=20 > 1, Why there exist the bi-directional tunnel between the MR and its HA insteads of uni- > directional tunnel? Can MNN such as VMN send the packets to CN using VMN's home address as > the source address and send it directly through the foreign link which its attaching ? Normally VMN creates a connected route to the visited prefix. If the destination is on that prefix, then the routing should forward the packet on link as opposed to via the tunnel, and SAS should make the VMN select the careof as source. All normal business by RFC 3484. We thought of writing down a few words on that but did not because it all goes by standards. >=20 > 2, What is the FA of the VMN which attaching to the mobile network? >=20 No FA in MIPv6... > 3, What is the solution(based on NEMO basic protocol) which should clearly address the > problem of double crossing over tunnel? >=20 In a more complex topology behind the MR, it would be Route optimization, if the LFN supports CN. Pascal From nemo-admin@ietf.org Thu Oct 2 11:53:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27946 for ; Thu, 2 Oct 2003 11:53:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55lF-0007uH-HV; Thu, 02 Oct 2003 11:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55ko-0007ry-Ff for nemo@optimus.ietf.org; Thu, 02 Oct 2003 11:52:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27904 for ; Thu, 2 Oct 2003 11:52:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A55kn-0002g2-00 for nemo@ietf.org; Thu, 02 Oct 2003 11:52:33 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A55km-0002fj-00 for nemo@ietf.org; Thu, 02 Oct 2003 11:52:32 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Oct 2003 17:50:27 +0200 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h92FpvTV006936; Thu, 2 Oct 2003 17:51:57 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 2 Oct 2003 16:52:00 +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" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-01.txt Date: Thu, 2 Oct 2003 16:52:00 +0100 Message-ID: Thread-Topic: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-01.txt Thread-Index: AcOI9LtWRNMToYNBSxa+HM5DgrFaDQABzs9w From: "Pascal Thubert (pthubert)" To: Cc: X-OriginalArrivalTime: 02 Oct 2003 15:52:00.0673 (UTC) FILETIME=[1DEDC110:01C388FD] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Paul: I read your draft with great interest, and it seems fair to discuss RO now that basic nemo has progressed a lot. I found the solution attractive and very clever. It has a close alternate with MR doing transparent bridging, where you'd use flooding down the nested tree (used as a spanning tree) to locate a CareOF and set the states.=20 For both approaches, I wonder how the mobility of a subtree works, because it's all states in the intermediate routers that need to be maintained. This is BTW the reason why we emulated source route bridging (with RRH) as opposed to transparent, though transparent looked more attractive for other reasons, including the HA side. What do you think? Pascal > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: jeudi 2 octobre 2003 16:50 > Cc: nemo@ietf.org > Subject: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-01.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directories. >=20 >=20 > Title : ND-Proxy based Route Optimization for Mobile Nodes in > Mobile Network > Author(s) : J. Jeong et al. > Filename : draft-jeong-nemo-ro-ndproxy-01.txt > Pages : 13 > Date : 2003-10-2 >=20 > This document specifies a mechanism for enabling mobile nodes in IPv6 > mobile network to perform route optimization. The route optimization > is possible because mobile router relays the prefix of its Care-of > address to its mobile nodes by playing the role of ND-proxy. > Through binding updates associated with the network prefix of an > access network, the mobile nodes can perform route optimization. In > addition, this document explains how mobile nodes can optimize its > DNS name resolution through RA-based DNS discovery. By announcing > the address of local recursive DNS server, mobile router allows > mobile nodes to optimize their DNS name resolution. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-01.txt >=20 > 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. >=20 > 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-jeong-nemo-ro-ndproxy-01.txt". >=20 > 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 >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-jeong-nemo-ro-ndproxy-01.txt". >=20 > 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. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From exim@www1.ietf.org Thu Oct 2 11:53:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27961 for ; Thu, 2 Oct 2003 11:53:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55lK-0007vW-5s for nemo-archive@odin.ietf.org; Thu, 02 Oct 2003 11:53:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Fr6Np030464 for nemo-archive@odin.ietf.org; Thu, 2 Oct 2003 11:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55lK-0007vH-0i for nemo-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 11:53:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27940 for ; Thu, 2 Oct 2003 11:52:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A55lI-0002gt-00 for nemo-web-archive@ietf.org; Thu, 02 Oct 2003 11:53:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A55lI-0002gq-00 for nemo-web-archive@ietf.org; Thu, 02 Oct 2003 11:53:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55lF-0007uH-HV; Thu, 02 Oct 2003 11:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55ko-0007ry-Ff for nemo@optimus.ietf.org; Thu, 02 Oct 2003 11:52:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27904 for ; Thu, 2 Oct 2003 11:52:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A55kn-0002g2-00 for nemo@ietf.org; Thu, 02 Oct 2003 11:52:33 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A55km-0002fj-00 for nemo@ietf.org; Thu, 02 Oct 2003 11:52:32 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Oct 2003 17:50:27 +0200 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h92FpvTV006936; Thu, 2 Oct 2003 17:51:57 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 2 Oct 2003 16:52:00 +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" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-01.txt Date: Thu, 2 Oct 2003 16:52:00 +0100 Message-ID: Thread-Topic: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-01.txt Thread-Index: AcOI9LtWRNMToYNBSxa+HM5DgrFaDQABzs9w From: "Pascal Thubert (pthubert)" To: Cc: X-OriginalArrivalTime: 02 Oct 2003 15:52:00.0673 (UTC) FILETIME=[1DEDC110:01C388FD] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Paul: I read your draft with great interest, and it seems fair to discuss RO now that basic nemo has progressed a lot. I found the solution attractive and very clever. It has a close alternate with MR doing transparent bridging, where you'd use flooding down the nested tree (used as a spanning tree) to locate a CareOF and set the states.=20 For both approaches, I wonder how the mobility of a subtree works, because it's all states in the intermediate routers that need to be maintained. This is BTW the reason why we emulated source route bridging (with RRH) as opposed to transparent, though transparent looked more attractive for other reasons, including the HA side. What do you think? Pascal > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: jeudi 2 octobre 2003 16:50 > Cc: nemo@ietf.org > Subject: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-01.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directories. >=20 >=20 > Title : ND-Proxy based Route Optimization for Mobile Nodes in > Mobile Network > Author(s) : J. Jeong et al. > Filename : draft-jeong-nemo-ro-ndproxy-01.txt > Pages : 13 > Date : 2003-10-2 >=20 > This document specifies a mechanism for enabling mobile nodes in IPv6 > mobile network to perform route optimization. The route optimization > is possible because mobile router relays the prefix of its Care-of > address to its mobile nodes by playing the role of ND-proxy. > Through binding updates associated with the network prefix of an > access network, the mobile nodes can perform route optimization. In > addition, this document explains how mobile nodes can optimize its > DNS name resolution through RA-based DNS discovery. By announcing > the address of local recursive DNS server, mobile router allows > mobile nodes to optimize their DNS name resolution. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-01.txt >=20 > 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. >=20 > 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-jeong-nemo-ro-ndproxy-01.txt". >=20 > 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 >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-jeong-nemo-ro-ndproxy-01.txt". >=20 > 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. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From nemo-admin@ietf.org Fri Oct 3 03:59:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26343 for ; Fri, 3 Oct 2003 03:59:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Kq5-0001Ww-5v; Fri, 03 Oct 2003 03:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5KpR-0001Vn-JL for nemo@optimus.ietf.org; Fri, 03 Oct 2003 03:58:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26315 for ; Fri, 3 Oct 2003 03:58:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5KpO-00058S-00 for nemo@ietf.org; Fri, 03 Oct 2003 03:58:18 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A5KpN-00058G-00 for nemo@ietf.org; Fri, 03 Oct 2003 03:58:18 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h937vsN1014844; Fri, 3 Oct 2003 09:57:54 +0200 (MEST) Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id T6YN4AMZ; Fri, 3 Oct 2003 09:58:53 +0200 Message-ID: <3F7D2C01.9080406@ericsson.com> Date: Fri, 03 Oct 2003 09:57:53 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: paul@etri.re.kr, nemo@ietf.org Subject: Re: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Hi Paul: > > I read your draft with great interest, and it seems fair to discuss RO > now that basic nemo has progressed a lot. I found the solution > attractive and very clever. It has a close alternate with MR doing > transparent bridging, where you'd use flooding down the nested tree > (used as a spanning tree) to locate a CareOF and set the states. I think this approach is attractive in the sense that it doesn't require any trust reationship between the MR and the MNNs. And trust is probably a huge problem for other solutions of RO in NEMO. On the other hand, every MNN have to signal their mobility independently, which may cause a BU storm when the network moves. Also, it would be interesting to know something about how quickly movement on the egress side of the root MR will be propagated down to all sub-NEMOs and their MNNs. MNNs will suffer from lost packets until the RAs have been propagated down, created CoAs and sent BUs. RA mechanism is unfortunately unreliable, so it is difficult to verify that all MNNs have learnt that the network has moved. Conclusion: the approach is very useful if the network moves occasionally, but not to recommend if it moves often. /Mattias > > For both approaches, I wonder how the mobility of a subtree works, > because it's all states in the intermediate routers that need to be > maintained. This is BTW the reason why we emulated source route bridging > (with RRH) as opposed to transparent, though transparent looked more > attractive for other reasons, including the HA side. > > What do you think? > > Pascal From exim@www1.ietf.org Fri Oct 3 03:59:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26358 for ; Fri, 3 Oct 2003 03:59:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5KqF-0001Xp-NE for nemo-archive@odin.ietf.org; Fri, 03 Oct 2003 03:59:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h937xBLp005938 for nemo-archive@odin.ietf.org; Fri, 3 Oct 2003 03:59:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5KqF-0001Xf-8X for nemo-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 03:59:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26319 for ; Fri, 3 Oct 2003 03:59:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5KqC-00058l-00 for nemo-web-archive@ietf.org; Fri, 03 Oct 2003 03:59:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5KqC-00058i-00 for nemo-web-archive@ietf.org; Fri, 03 Oct 2003 03:59:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Kq5-0001Ww-5v; Fri, 03 Oct 2003 03:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5KpR-0001Vn-JL for nemo@optimus.ietf.org; Fri, 03 Oct 2003 03:58:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26315 for ; Fri, 3 Oct 2003 03:58:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5KpO-00058S-00 for nemo@ietf.org; Fri, 03 Oct 2003 03:58:18 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A5KpN-00058G-00 for nemo@ietf.org; Fri, 03 Oct 2003 03:58:18 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h937vsN1014844; Fri, 3 Oct 2003 09:57:54 +0200 (MEST) Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id T6YN4AMZ; Fri, 3 Oct 2003 09:58:53 +0200 Message-ID: <3F7D2C01.9080406@ericsson.com> Date: Fri, 03 Oct 2003 09:57:53 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: paul@etri.re.kr, nemo@ietf.org Subject: Re: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Hi Paul: > > I read your draft with great interest, and it seems fair to discuss RO > now that basic nemo has progressed a lot. I found the solution > attractive and very clever. It has a close alternate with MR doing > transparent bridging, where you'd use flooding down the nested tree > (used as a spanning tree) to locate a CareOF and set the states. I think this approach is attractive in the sense that it doesn't require any trust reationship between the MR and the MNNs. And trust is probably a huge problem for other solutions of RO in NEMO. On the other hand, every MNN have to signal their mobility independently, which may cause a BU storm when the network moves. Also, it would be interesting to know something about how quickly movement on the egress side of the root MR will be propagated down to all sub-NEMOs and their MNNs. MNNs will suffer from lost packets until the RAs have been propagated down, created CoAs and sent BUs. RA mechanism is unfortunately unreliable, so it is difficult to verify that all MNNs have learnt that the network has moved. Conclusion: the approach is very useful if the network moves occasionally, but not to recommend if it moves often. /Mattias > > For both approaches, I wonder how the mobility of a subtree works, > because it's all states in the intermediate routers that need to be > maintained. This is BTW the reason why we emulated source route bridging > (with RRH) as opposed to transparent, though transparent looked more > attractive for other reasons, including the HA side. > > What do you think? > > Pascal From nemo-admin@ietf.org Fri Oct 3 14:30:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19465 for ; Fri, 3 Oct 2003 14:30:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Ugk-0003u4-RV; Fri, 03 Oct 2003 14:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Ufl-0003tA-Fx for nemo@optimus.ietf.org; Fri, 03 Oct 2003 14:29:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19393 for ; Fri, 3 Oct 2003 14:28:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Ufi-0004XX-00 for nemo@ietf.org; Fri, 03 Oct 2003 14:28:58 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1A5Ufh-0004XU-00 for nemo@ietf.org; Fri, 03 Oct 2003 14:28:58 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h93ISogV016116; Fri, 3 Oct 2003 11:28:51 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h93ISiwA010551; Fri, 3 Oct 2003 13:28:45 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id E13FC2EC95; Fri, 3 Oct 2003 20:23:45 +0200 (CEST) Message-ID: <3F7DBEAE.3090808@nal.motlabs.com> Date: Fri, 03 Oct 2003 20:23:42 +0200 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: KAI CHEONG WONG Cc: nemo@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: some inquiries Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit KAI CHEONG WONG wrote: > I am an university student in australia. Iam doing a research on the > problem of NEMO basic potocol whch is the drawback of double crossing > over tunnel. It happens when LFN decides to communicate with VMN in > the same subnetwork such as in the train. It is because the LFN dont > know the VMN is on the same link, that means LFN will send packets to > the MR which forwards packets to its HA crossing the tunnel. After > the HA received the packets, it will send back to the MR crossing the > same tunnel again. It leads to the inefficiency. This inefficiency is indeed not very good. However, if one considers that a MN that visits the train performs classical Mobile IPv6-based RO with the CN that resides fixed in that train, then the inefficiency of double encapsulation happens only before the RO procedure is performed. After RO, MN and CN talk directly, no tunnels. In addition to this, SAS (source address selection) employed correctly between MN and CN could help towards not needing RO at all; (of course this has the drawback that CN can not talk to MN's Home Address). I would also add that, when I read the generic train description you provide, I can't see that the tunnels involved (between MN and its HA, and between MR and its HA) would "cross over" each other, they are encapsulated one into the other. Two tunnels "cross" each other when one (and only one) endpoint of one tunnel is in the IP path formed by the the two endpoints of the other tunnel. This is a definition I'm trying, my oppinion only, feel free to invent other definitions. In your scenario, tunnels would "cross" each other only if the train moving network could be at home when inside the VMN, which is unrealistic of course. But in other scenarios, this problem _could_ be realistic: Assume that a car contains a mobile network and an MR to connect to the Internet via GPRS and WLAN hotspots only. Inside this car, there is another mobile network, that has another smaller MR that connects with Bluetooth to the car bigger mobile network, and that offers WLAN access to its LFN. This smaller mobile network is served by a HA deployed in the car. This grouping of mobile networks can move freely wherever GPRS or WLAN coverage exists. The smaller mobile network can separate, get out of the car and connect to a train, or go inside driver's house. All entities can connect to the Internet and be reached at their permanent home addresses, if the current nemo base solution is used. But, move the car to an area where is no GPRS nor WLAN coverage, such as a remote montaineous location, driver's cottage connected to the Internet with a satellite dish. There is only a Bluetooth AP in this small hose. In this case, the only way to connect everything to the Internet, is to first connect the smaller mobile network via Bluetooth to the house Bluetooth AP (instead of the car's BT AP) and the car bigger mobile network to the small mobile network with WLAN (instead of to a hotspot area AP). This can be done and all entities in both mobile networks can be connected to the Internet but, with current solution, they can not be reached at their permanent home address. (wondering about comercialization of this scenario, look at Carey doing GPRS outside and WLAN inside the luxury sedan). > However, i have read the draft-ietf, it seems doesnt mention about > that problem. I'm not sure that the current network mobility solution as described by the draft should treat this problem. Maybe this can be solved by other means, RO, SAS and other tools can be employed. At most this could be mentioned as an acknowledged limitation related to a particular scenario of deployment. But then again, maybe this is more related to "usages" or potential scenarios, or more to an applicability statement. One simple solution draft can not solve everything to everybody. It already does a good job for most scenarios, I believe. > 1, Why there exist the bi-directional tunnel between the MR and its > HA insteads of uni-directional tunnel? Bidirectional is better than uni-directional. It avoids outgoing packets always taking different paths than incoming packets, which might break somehow TCP. It also avoids many other bad things. Moreover, it allowed people to design a three-party scheme to perform Route Optimization with a higher level of security (when no sec infrastructure can be relied upon). > Can MNN such as VMN send the packets to CN using VMN's home address > as the source address and send it directly through the foreign link > which its attaching ? MN's home address can be filtered out by the foreign link because not being topologically correct. So, no, VMN should not use its HoA, but its CoA. > 2, What is the FA of the VMN which attaching to the mobile network? With Mobile IPv6, the FA concept of Mobile IPv4 is eliminated, in that the tunnel between MH and its HA finishes at MH (instead of FA, or "co-located CoA"), in that an address can be obtained from the RA of an AR, or in that a DHCPv6 server can exist anywhere in the visited domain (not necessarily in the FA). In other words, it is sufficient for MR to send RA's to the fixed link in the train, no need of FA. > 3, What is the solution(based on NEMO basic protocol) which should > clearly address the problem of double crossing over tunnel? Choose. Base your choice on the basic protocol, but without touching it too much. You have an idea? Alex GBU From exim@www1.ietf.org Fri Oct 3 14:30:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19480 for ; Fri, 3 Oct 2003 14:30:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Ugv-0003vk-4W for nemo-archive@odin.ietf.org; Fri, 03 Oct 2003 14:30:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93IUDeF015102 for nemo-archive@odin.ietf.org; Fri, 3 Oct 2003 14:30:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Ugu-0003vV-UC for nemo-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 14:30:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19440 for ; Fri, 3 Oct 2003 14:30:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Ugs-0004Yw-00 for nemo-web-archive@ietf.org; Fri, 03 Oct 2003 14:30:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Ugr-0004Ys-00 for nemo-web-archive@ietf.org; Fri, 03 Oct 2003 14:30:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Ugk-0003u4-RV; Fri, 03 Oct 2003 14:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Ufl-0003tA-Fx for nemo@optimus.ietf.org; Fri, 03 Oct 2003 14:29:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19393 for ; Fri, 3 Oct 2003 14:28:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Ufi-0004XX-00 for nemo@ietf.org; Fri, 03 Oct 2003 14:28:58 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1A5Ufh-0004XU-00 for nemo@ietf.org; Fri, 03 Oct 2003 14:28:58 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h93ISogV016116; Fri, 3 Oct 2003 11:28:51 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h93ISiwA010551; Fri, 3 Oct 2003 13:28:45 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id E13FC2EC95; Fri, 3 Oct 2003 20:23:45 +0200 (CEST) Message-ID: <3F7DBEAE.3090808@nal.motlabs.com> Date: Fri, 03 Oct 2003 20:23:42 +0200 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: KAI CHEONG WONG Cc: nemo@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: some inquiries Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit KAI CHEONG WONG wrote: > I am an university student in australia. Iam doing a research on the > problem of NEMO basic potocol whch is the drawback of double crossing > over tunnel. It happens when LFN decides to communicate with VMN in > the same subnetwork such as in the train. It is because the LFN dont > know the VMN is on the same link, that means LFN will send packets to > the MR which forwards packets to its HA crossing the tunnel. After > the HA received the packets, it will send back to the MR crossing the > same tunnel again. It leads to the inefficiency. This inefficiency is indeed not very good. However, if one considers that a MN that visits the train performs classical Mobile IPv6-based RO with the CN that resides fixed in that train, then the inefficiency of double encapsulation happens only before the RO procedure is performed. After RO, MN and CN talk directly, no tunnels. In addition to this, SAS (source address selection) employed correctly between MN and CN could help towards not needing RO at all; (of course this has the drawback that CN can not talk to MN's Home Address). I would also add that, when I read the generic train description you provide, I can't see that the tunnels involved (between MN and its HA, and between MR and its HA) would "cross over" each other, they are encapsulated one into the other. Two tunnels "cross" each other when one (and only one) endpoint of one tunnel is in the IP path formed by the the two endpoints of the other tunnel. This is a definition I'm trying, my oppinion only, feel free to invent other definitions. In your scenario, tunnels would "cross" each other only if the train moving network could be at home when inside the VMN, which is unrealistic of course. But in other scenarios, this problem _could_ be realistic: Assume that a car contains a mobile network and an MR to connect to the Internet via GPRS and WLAN hotspots only. Inside this car, there is another mobile network, that has another smaller MR that connects with Bluetooth to the car bigger mobile network, and that offers WLAN access to its LFN. This smaller mobile network is served by a HA deployed in the car. This grouping of mobile networks can move freely wherever GPRS or WLAN coverage exists. The smaller mobile network can separate, get out of the car and connect to a train, or go inside driver's house. All entities can connect to the Internet and be reached at their permanent home addresses, if the current nemo base solution is used. But, move the car to an area where is no GPRS nor WLAN coverage, such as a remote montaineous location, driver's cottage connected to the Internet with a satellite dish. There is only a Bluetooth AP in this small hose. In this case, the only way to connect everything to the Internet, is to first connect the smaller mobile network via Bluetooth to the house Bluetooth AP (instead of the car's BT AP) and the car bigger mobile network to the small mobile network with WLAN (instead of to a hotspot area AP). This can be done and all entities in both mobile networks can be connected to the Internet but, with current solution, they can not be reached at their permanent home address. (wondering about comercialization of this scenario, look at Carey doing GPRS outside and WLAN inside the luxury sedan). > However, i have read the draft-ietf, it seems doesnt mention about > that problem. I'm not sure that the current network mobility solution as described by the draft should treat this problem. Maybe this can be solved by other means, RO, SAS and other tools can be employed. At most this could be mentioned as an acknowledged limitation related to a particular scenario of deployment. But then again, maybe this is more related to "usages" or potential scenarios, or more to an applicability statement. One simple solution draft can not solve everything to everybody. It already does a good job for most scenarios, I believe. > 1, Why there exist the bi-directional tunnel between the MR and its > HA insteads of uni-directional tunnel? Bidirectional is better than uni-directional. It avoids outgoing packets always taking different paths than incoming packets, which might break somehow TCP. It also avoids many other bad things. Moreover, it allowed people to design a three-party scheme to perform Route Optimization with a higher level of security (when no sec infrastructure can be relied upon). > Can MNN such as VMN send the packets to CN using VMN's home address > as the source address and send it directly through the foreign link > which its attaching ? MN's home address can be filtered out by the foreign link because not being topologically correct. So, no, VMN should not use its HoA, but its CoA. > 2, What is the FA of the VMN which attaching to the mobile network? With Mobile IPv6, the FA concept of Mobile IPv4 is eliminated, in that the tunnel between MH and its HA finishes at MH (instead of FA, or "co-located CoA"), in that an address can be obtained from the RA of an AR, or in that a DHCPv6 server can exist anywhere in the visited domain (not necessarily in the FA). In other words, it is sufficient for MR to send RA's to the fixed link in the train, no need of FA. > 3, What is the solution(based on NEMO basic protocol) which should > clearly address the problem of double crossing over tunnel? Choose. Base your choice on the basic protocol, but without touching it too much. You have an idea? Alex GBU From nemo-admin@ietf.org Fri Oct 3 23:32:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09556 for ; Fri, 3 Oct 2003 23:32:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5d9G-0002Hm-KB; Fri, 03 Oct 2003 23:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5d7h-0002FI-38 for nemo@optimus.ietf.org; Fri, 03 Oct 2003 23:31:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09498 for ; Fri, 3 Oct 2003 23:30:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5d7e-0002fn-00 for nemo@ietf.org; Fri, 03 Oct 2003 23:30:22 -0400 Received: from [129.254.114.50] (helo=pec.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1A5d7d-0002fX-00 for nemo@ietf.org; Fri, 03 Oct 2003 23:30:21 -0400 Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.12.9/8.12.9) with SMTP id h943hBV6005908; Sat, 4 Oct 2003 12:43:11 +0900 (KST) Message-ID: <016c01c38a27$99a1eef0$c470fe81@etri.re.kr> From: "Jaehoon Paul Jeong" To: "Pascal Thubert \(pthubert\)" Cc: , "autonet" References: Subject: Re: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-01.txt Date: Sat, 4 Oct 2003 12:27:40 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgUGFzY2FsLA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBhc2Nh bCBUaHViZXJ0IChwdGh1YmVydCkiIDxwdGh1YmVydEBjaXNjby5jb20+DQo+DQo+SGkgUGF1bDoN Cj4NCj5JIHJlYWQgeW91ciBkcmFmdCB3aXRoIGdyZWF0IGludGVyZXN0LCBhbmQgaXQgc2VlbXMg ZmFpciB0byBkaXNjdXNzIFJPDQo+bm93IHRoYXQgYmFzaWMgbmVtbyBoYXMgcHJvZ3Jlc3NlZCBh IGxvdC4gSSBmb3VuZCB0aGUgc29sdXRpb24NCj5hdHRyYWN0aXZlIGFuZCB2ZXJ5IGNsZXZlci4g SXQgaGFzIGEgY2xvc2UgYWx0ZXJuYXRlIHdpdGggTVIgZG9pbmcNCj50cmFuc3BhcmVudCBicmlk Z2luZywgd2hlcmUgeW91J2QgdXNlIGZsb29kaW5nIGRvd24gdGhlIG5lc3RlZCB0cmVlDQo+KHVz ZWQgYXMgYSBzcGFubmluZyB0cmVlKSB0byBsb2NhdGUgYSBDYXJlT0YgYW5kIHNldCB0aGUgc3Rh dGVzLiANCj4NCj5Gb3IgYm90aCBhcHByb2FjaGVzLCBJIHdvbmRlciBob3cgdGhlIG1vYmlsaXR5 IG9mIGEgc3VidHJlZSB3b3JrcywNCj5iZWNhdXNlIGl0J3MgYWxsIHN0YXRlcyBpbiB0aGUgaW50 ZXJtZWRpYXRlIHJvdXRlcnMgdGhhdCBuZWVkIHRvIGJlDQo+bWFpbnRhaW5lZC4gVGhpcyBpcyBC VFcgdGhlIHJlYXNvbiB3aHkgd2UgZW11bGF0ZWQgc291cmNlIHJvdXRlIGJyaWRnaW5nDQo+KHdp dGggUlJIKSBhcyBvcHBvc2VkIHRvIHRyYW5zcGFyZW50LCB0aG91Z2ggdHJhbnNwYXJlbnQgbG9v a2VkIG1vcmUNCj5hdHRyYWN0aXZlIGZvciBvdGhlciByZWFzb25zLCBpbmNsdWRpbmcgdGhlIEhB IHNpZGUuDQo+DQoNCkkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGUgY29uc2lkZXJhdGlvbiBvZiBz dWJ0cmVlJ3MgbW9iaWxpdHkgaXMgaW1wb3J0YW50Lg0KSXQgc2VlbXMgdG8gYmUgcmVsYXRlZCB0 byB0aGUgc21vb3RoIGhhbmRvdmVyIGluIE1JUHY2IGFuZCBuZWlnaGJvciBjYWNoZSBtYW5hZ2Vt ZW50IGluIE5ELg0KSW4gbXkgY3VycmVudCBkcmFmdCwgSSB0aGluaywgbWFueSBwYWNrZXQgbG9z c2VzIGNhbiBoYXBwZW4gd2hlbiBNTiBtb3ZlcyBmYXN0DQp3aXRoaW4gb3RoZXIgbGlua3Mgb2Yg YSBtb2JpbGUgbmV0d29yayBvciBvdGhlciBtb2JpbGUgbmV0d29ya3MuDQpJJ20gY29uc2lkZXJp bmcgdGhpcyBwcm9ibGVtIGFuZCBob3cgdG8gc29ydCBvdXQgaXQgaW4gbmV4dCB2ZXJzaW9uLiA6 LSkNCkknbGwgYXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnRzLg0KVGhhbmtzLg0KDQovUGF1bA0KDQo+ V2hhdCBkbyB5b3UgdGhpbms/DQo+DQo+UGFzY2FsDQoNCg== From exim@www1.ietf.org Fri Oct 3 23:34:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09594 for ; Fri, 3 Oct 2003 23:34:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5dAo-0002Nd-9V for nemo-archive@odin.ietf.org; Fri, 03 Oct 2003 23:34:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h943XcwH009148 for nemo-archive@odin.ietf.org; Fri, 3 Oct 2003 23:33:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5d9S-0002Ih-V1 for nemo-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 23:33:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09554 for ; Fri, 3 Oct 2003 23:32:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5d9Q-0002gv-00 for nemo-web-archive@ietf.org; Fri, 03 Oct 2003 23:32:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5d9Q-0002gr-00 for nemo-web-archive@ietf.org; Fri, 03 Oct 2003 23:32:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5d9G-0002Hm-KB; Fri, 03 Oct 2003 23:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5d7h-0002FI-38 for nemo@optimus.ietf.org; Fri, 03 Oct 2003 23:31:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09498 for ; Fri, 3 Oct 2003 23:30:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5d7e-0002fn-00 for nemo@ietf.org; Fri, 03 Oct 2003 23:30:22 -0400 Received: from [129.254.114.50] (helo=pec.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1A5d7d-0002fX-00 for nemo@ietf.org; Fri, 03 Oct 2003 23:30:21 -0400 Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.12.9/8.12.9) with SMTP id h943hBV6005908; Sat, 4 Oct 2003 12:43:11 +0900 (KST) Message-ID: <016c01c38a27$99a1eef0$c470fe81@etri.re.kr> From: "Jaehoon Paul Jeong" To: "Pascal Thubert \(pthubert\)" Cc: , "autonet" References: Subject: Re: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-01.txt Date: Sat, 4 Oct 2003 12:27:40 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgUGFzY2FsLA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBhc2Nh bCBUaHViZXJ0IChwdGh1YmVydCkiIDxwdGh1YmVydEBjaXNjby5jb20+DQo+DQo+SGkgUGF1bDoN Cj4NCj5JIHJlYWQgeW91ciBkcmFmdCB3aXRoIGdyZWF0IGludGVyZXN0LCBhbmQgaXQgc2VlbXMg ZmFpciB0byBkaXNjdXNzIFJPDQo+bm93IHRoYXQgYmFzaWMgbmVtbyBoYXMgcHJvZ3Jlc3NlZCBh IGxvdC4gSSBmb3VuZCB0aGUgc29sdXRpb24NCj5hdHRyYWN0aXZlIGFuZCB2ZXJ5IGNsZXZlci4g SXQgaGFzIGEgY2xvc2UgYWx0ZXJuYXRlIHdpdGggTVIgZG9pbmcNCj50cmFuc3BhcmVudCBicmlk Z2luZywgd2hlcmUgeW91J2QgdXNlIGZsb29kaW5nIGRvd24gdGhlIG5lc3RlZCB0cmVlDQo+KHVz ZWQgYXMgYSBzcGFubmluZyB0cmVlKSB0byBsb2NhdGUgYSBDYXJlT0YgYW5kIHNldCB0aGUgc3Rh dGVzLiANCj4NCj5Gb3IgYm90aCBhcHByb2FjaGVzLCBJIHdvbmRlciBob3cgdGhlIG1vYmlsaXR5 IG9mIGEgc3VidHJlZSB3b3JrcywNCj5iZWNhdXNlIGl0J3MgYWxsIHN0YXRlcyBpbiB0aGUgaW50 ZXJtZWRpYXRlIHJvdXRlcnMgdGhhdCBuZWVkIHRvIGJlDQo+bWFpbnRhaW5lZC4gVGhpcyBpcyBC VFcgdGhlIHJlYXNvbiB3aHkgd2UgZW11bGF0ZWQgc291cmNlIHJvdXRlIGJyaWRnaW5nDQo+KHdp dGggUlJIKSBhcyBvcHBvc2VkIHRvIHRyYW5zcGFyZW50LCB0aG91Z2ggdHJhbnNwYXJlbnQgbG9v a2VkIG1vcmUNCj5hdHRyYWN0aXZlIGZvciBvdGhlciByZWFzb25zLCBpbmNsdWRpbmcgdGhlIEhB IHNpZGUuDQo+DQoNCkkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGUgY29uc2lkZXJhdGlvbiBvZiBz dWJ0cmVlJ3MgbW9iaWxpdHkgaXMgaW1wb3J0YW50Lg0KSXQgc2VlbXMgdG8gYmUgcmVsYXRlZCB0 byB0aGUgc21vb3RoIGhhbmRvdmVyIGluIE1JUHY2IGFuZCBuZWlnaGJvciBjYWNoZSBtYW5hZ2Vt ZW50IGluIE5ELg0KSW4gbXkgY3VycmVudCBkcmFmdCwgSSB0aGluaywgbWFueSBwYWNrZXQgbG9z c2VzIGNhbiBoYXBwZW4gd2hlbiBNTiBtb3ZlcyBmYXN0DQp3aXRoaW4gb3RoZXIgbGlua3Mgb2Yg YSBtb2JpbGUgbmV0d29yayBvciBvdGhlciBtb2JpbGUgbmV0d29ya3MuDQpJJ20gY29uc2lkZXJp bmcgdGhpcyBwcm9ibGVtIGFuZCBob3cgdG8gc29ydCBvdXQgaXQgaW4gbmV4dCB2ZXJzaW9uLiA6 LSkNCkknbGwgYXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnRzLg0KVGhhbmtzLg0KDQovUGF1bA0KDQo+ V2hhdCBkbyB5b3UgdGhpbms/DQo+DQo+UGFzY2FsDQoNCg== From nemo-admin@ietf.org Fri Oct 3 23:43:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09823 for ; Fri, 3 Oct 2003 23:43:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5dJu-0002np-UT; Fri, 03 Oct 2003 23:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5dIM-0002mg-C6 for nemo@optimus.ietf.org; Fri, 03 Oct 2003 23:42:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09793 for ; Fri, 3 Oct 2003 23:41:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5dIJ-0002kN-00 for nemo@ietf.org; Fri, 03 Oct 2003 23:41:23 -0400 Received: from [129.254.114.50] (helo=pec.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1A5dII-0002kK-00 for nemo@ietf.org; Fri, 03 Oct 2003 23:41:22 -0400 Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.12.9/8.12.9) with SMTP id h943s1V6005952; Sat, 4 Oct 2003 12:54:01 +0900 (KST) Message-ID: <016f01c38a29$1d0dc600$c470fe81@etri.re.kr> From: "Jaehoon Paul Jeong" To: "Mattias Pettersson" , "Pascal Thubert \(pthubert\)" Cc: , "autonet" References: <3F7D2C01.9080406@ericsson.com> Subject: Re: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-01.txt Date: Sat, 4 Oct 2003 12:37:35 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgTWF0dGlhcywNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJNYXR0 aWFzIFBldHRlcnNzb24iIDxtYXR0aWFzLmwucGV0dGVyc3NvbkBlcmljc3Nvbi5jb20+DQo+DQo+ IEkgdGhpbmsgdGhpcyBhcHByb2FjaCBpcyBhdHRyYWN0aXZlIGluIHRoZSBzZW5zZSB0aGF0IGl0 IGRvZXNuJ3QgcmVxdWlyZSANCj4gYW55IHRydXN0IHJlYXRpb25zaGlwIGJldHdlZW4gdGhlIE1S IGFuZCB0aGUgTU5Ocy4gQW5kIHRydXN0IGlzIHByb2JhYmx5IA0KPiBhIGh1Z2UgcHJvYmxlbSBm b3Igb3RoZXIgc29sdXRpb25zIG9mIFJPIGluIE5FTU8uDQo+IA0KPiBPbiB0aGUgb3RoZXIgaGFu ZCwgZXZlcnkgTU5OIGhhdmUgdG8gc2lnbmFsIHRoZWlyIG1vYmlsaXR5IA0KPiBpbmRlcGVuZGVu dGx5LCB3aGljaCBtYXkgY2F1c2UgYSBCVSBzdG9ybSB3aGVuIHRoZSBuZXR3b3JrIG1vdmVzLiBB bHNvLCANCg0KRXZlcnkgbW9iaWxlIG5vZGUgbmVlZCBub3QgcGVyZm9ybSBhIEJVIGZvciBSTyBh bmQgDQpvbmx5IG1vYmlsZSBub2RlIHdoZXJlIFJPIGlzIGltcG9ydGFudCBkb2VzIHNvLg0KDQo+ IGl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIGtub3cgc29tZXRoaW5nIGFib3V0IGhvdyBxdWlj a2x5IG1vdmVtZW50IG9uIA0KPiB0aGUgZWdyZXNzIHNpZGUgb2YgdGhlIHJvb3QgTVIgd2lsbCBi ZSBwcm9wYWdhdGVkIGRvd24gdG8gYWxsIHN1Yi1ORU1PcyANCj4gYW5kIHRoZWlyIE1OTnMuIE1O TnMgd2lsbCBzdWZmZXIgZnJvbSBsb3N0IHBhY2tldHMgdW50aWwgdGhlIFJBcyBoYXZlIA0KPiBi ZWVuIHByb3BhZ2F0ZWQgZG93biwgY3JlYXRlZCBDb0FzIGFuZCBzZW50IEJVcy4gUkEgbWVjaGFu aXNtIGlzIA0KPiB1bmZvcnR1bmF0ZWx5IHVucmVsaWFibGUsIHNvIGl0IGlzIGRpZmZpY3VsdCB0 byB2ZXJpZnkgdGhhdCBhbGwgTU5OcyANCj4gaGF2ZSBsZWFybnQgdGhhdCB0aGUgbmV0d29yayBo YXMgbW92ZWQuDQo+IA0KDQpJIGNvbXBsZXRlbHkgYWdyZWUgd2l0aCB5b3UgaW4gZGVlcCBtb2Jp bGUgbmV0d29yay4NCkFjdHVhbGx5LCBteSB0YXJnZXQgYXBwbGljYXRpb24gaXMgdG8gc3VwcG9y dCBSTyBmb3Igc2hhbGxvdyBtb2JpbGUgbmV0d29yaywgDQpzdWNoIGFzIGNhciBhbmQgYnVzLg0K VGhhbmtzLg0KDQovUGF1bA0KDQo+IENvbmNsdXNpb246IHRoZSBhcHByb2FjaCBpcyB2ZXJ5IHVz ZWZ1bCBpZiB0aGUgbmV0d29yayBtb3ZlcyANCj4gb2NjYXNpb25hbGx5LCBidXQgbm90IHRvIHJl Y29tbWVuZCBpZiBpdCBtb3ZlcyBvZnRlbi4NCj4gDQo+IC9NYXR0aWFz From exim@www1.ietf.org Fri Oct 3 23:45:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09921 for ; Fri, 3 Oct 2003 23:45:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5dLb-0002uj-Lp for nemo-archive@odin.ietf.org; Fri, 03 Oct 2003 23:45:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h943ilKp011202 for nemo-archive@odin.ietf.org; Fri, 3 Oct 2003 23:44:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5dKG-0002sG-8L for nemo-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 23:44:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09819 for ; Fri, 3 Oct 2003 23:43:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5dK1-0002lX-00 for nemo-web-archive@ietf.org; Fri, 03 Oct 2003 23:43:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5dK1-0002lU-00 for nemo-web-archive@ietf.org; Fri, 03 Oct 2003 23:43:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5dJu-0002np-UT; Fri, 03 Oct 2003 23:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5dIM-0002mg-C6 for nemo@optimus.ietf.org; Fri, 03 Oct 2003 23:42:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09793 for ; Fri, 3 Oct 2003 23:41:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5dIJ-0002kN-00 for nemo@ietf.org; Fri, 03 Oct 2003 23:41:23 -0400 Received: from [129.254.114.50] (helo=pec.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1A5dII-0002kK-00 for nemo@ietf.org; Fri, 03 Oct 2003 23:41:22 -0400 Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.12.9/8.12.9) with SMTP id h943s1V6005952; Sat, 4 Oct 2003 12:54:01 +0900 (KST) Message-ID: <016f01c38a29$1d0dc600$c470fe81@etri.re.kr> From: "Jaehoon Paul Jeong" To: "Mattias Pettersson" , "Pascal Thubert \(pthubert\)" Cc: , "autonet" References: <3F7D2C01.9080406@ericsson.com> Subject: Re: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-01.txt Date: Sat, 4 Oct 2003 12:37:35 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgTWF0dGlhcywNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJNYXR0 aWFzIFBldHRlcnNzb24iIDxtYXR0aWFzLmwucGV0dGVyc3NvbkBlcmljc3Nvbi5jb20+DQo+DQo+ IEkgdGhpbmsgdGhpcyBhcHByb2FjaCBpcyBhdHRyYWN0aXZlIGluIHRoZSBzZW5zZSB0aGF0IGl0 IGRvZXNuJ3QgcmVxdWlyZSANCj4gYW55IHRydXN0IHJlYXRpb25zaGlwIGJldHdlZW4gdGhlIE1S IGFuZCB0aGUgTU5Ocy4gQW5kIHRydXN0IGlzIHByb2JhYmx5IA0KPiBhIGh1Z2UgcHJvYmxlbSBm b3Igb3RoZXIgc29sdXRpb25zIG9mIFJPIGluIE5FTU8uDQo+IA0KPiBPbiB0aGUgb3RoZXIgaGFu ZCwgZXZlcnkgTU5OIGhhdmUgdG8gc2lnbmFsIHRoZWlyIG1vYmlsaXR5IA0KPiBpbmRlcGVuZGVu dGx5LCB3aGljaCBtYXkgY2F1c2UgYSBCVSBzdG9ybSB3aGVuIHRoZSBuZXR3b3JrIG1vdmVzLiBB bHNvLCANCg0KRXZlcnkgbW9iaWxlIG5vZGUgbmVlZCBub3QgcGVyZm9ybSBhIEJVIGZvciBSTyBh bmQgDQpvbmx5IG1vYmlsZSBub2RlIHdoZXJlIFJPIGlzIGltcG9ydGFudCBkb2VzIHNvLg0KDQo+ IGl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIGtub3cgc29tZXRoaW5nIGFib3V0IGhvdyBxdWlj a2x5IG1vdmVtZW50IG9uIA0KPiB0aGUgZWdyZXNzIHNpZGUgb2YgdGhlIHJvb3QgTVIgd2lsbCBi ZSBwcm9wYWdhdGVkIGRvd24gdG8gYWxsIHN1Yi1ORU1PcyANCj4gYW5kIHRoZWlyIE1OTnMuIE1O TnMgd2lsbCBzdWZmZXIgZnJvbSBsb3N0IHBhY2tldHMgdW50aWwgdGhlIFJBcyBoYXZlIA0KPiBi ZWVuIHByb3BhZ2F0ZWQgZG93biwgY3JlYXRlZCBDb0FzIGFuZCBzZW50IEJVcy4gUkEgbWVjaGFu aXNtIGlzIA0KPiB1bmZvcnR1bmF0ZWx5IHVucmVsaWFibGUsIHNvIGl0IGlzIGRpZmZpY3VsdCB0 byB2ZXJpZnkgdGhhdCBhbGwgTU5OcyANCj4gaGF2ZSBsZWFybnQgdGhhdCB0aGUgbmV0d29yayBo YXMgbW92ZWQuDQo+IA0KDQpJIGNvbXBsZXRlbHkgYWdyZWUgd2l0aCB5b3UgaW4gZGVlcCBtb2Jp bGUgbmV0d29yay4NCkFjdHVhbGx5LCBteSB0YXJnZXQgYXBwbGljYXRpb24gaXMgdG8gc3VwcG9y dCBSTyBmb3Igc2hhbGxvdyBtb2JpbGUgbmV0d29yaywgDQpzdWNoIGFzIGNhciBhbmQgYnVzLg0K VGhhbmtzLg0KDQovUGF1bA0KDQo+IENvbmNsdXNpb246IHRoZSBhcHByb2FjaCBpcyB2ZXJ5IHVz ZWZ1bCBpZiB0aGUgbmV0d29yayBtb3ZlcyANCj4gb2NjYXNpb25hbGx5LCBidXQgbm90IHRvIHJl Y29tbWVuZCBpZiBpdCBtb3ZlcyBvZnRlbi4NCj4gDQo+IC9NYXR0aWFz From nemo-admin@ietf.org Mon Oct 6 00:37:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05215 for ; Mon, 6 Oct 2003 00:37:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6N7E-0002I0-Hw; Mon, 06 Oct 2003 00:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6N6x-0002HX-T7 for nemo@optimus.ietf.org; Mon, 06 Oct 2003 00:36:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05192 for ; Mon, 6 Oct 2003 00:36:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6N6u-0000hN-00 for nemo@ietf.org; Mon, 06 Oct 2003 00:36:41 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1A6N6u-0000hI-00 for nemo@ietf.org; Mon, 06 Oct 2003 00:36:40 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HMB00G01JG0YM@mailout1.samsung.com> for nemo@ietf.org; Mon, 06 Oct 2003 13:36:00 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HMB009PTJFZ2I@mailout1.samsung.com> for nemo@ietf.org; Mon, 06 Oct 2003 13:36:00 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HMB00FOYJFZ04@mmp1.samsung.com> for nemo@ietf.org; Mon, 06 Oct 2003 13:35:59 +0900 (KST) Date: Mon, 06 Oct 2003 13:36:11 +0900 From: Soohong Daniel Park To: nemo@ietf.org Message-id: <006401c38bc3$5eb28ff0$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [nemo] [test mail] please ignore... Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT TEST From exim@www1.ietf.org Mon Oct 6 00:37:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05230 for ; Mon, 6 Oct 2003 00:37:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6N7P-0002Ln-Dn for nemo-archive@odin.ietf.org; Mon, 06 Oct 2003 00:37:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h964bAQi009011 for nemo-archive@odin.ietf.org; Mon, 6 Oct 2003 00:37:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6N7O-0002L8-AZ for nemo-web-archive@optimus.ietf.org; Mon, 06 Oct 2003 00:37:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05210 for ; Mon, 6 Oct 2003 00:37:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6N7L-0000hv-00 for nemo-web-archive@ietf.org; Mon, 06 Oct 2003 00:37:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6N7L-0000hr-00 for nemo-web-archive@ietf.org; Mon, 06 Oct 2003 00:37:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6N7E-0002I0-Hw; Mon, 06 Oct 2003 00:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6N6x-0002HX-T7 for nemo@optimus.ietf.org; Mon, 06 Oct 2003 00:36:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05192 for ; Mon, 6 Oct 2003 00:36:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6N6u-0000hN-00 for nemo@ietf.org; Mon, 06 Oct 2003 00:36:41 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1A6N6u-0000hI-00 for nemo@ietf.org; Mon, 06 Oct 2003 00:36:40 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HMB00G01JG0YM@mailout1.samsung.com> for nemo@ietf.org; Mon, 06 Oct 2003 13:36:00 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HMB009PTJFZ2I@mailout1.samsung.com> for nemo@ietf.org; Mon, 06 Oct 2003 13:36:00 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HMB00FOYJFZ04@mmp1.samsung.com> for nemo@ietf.org; Mon, 06 Oct 2003 13:35:59 +0900 (KST) Date: Mon, 06 Oct 2003 13:36:11 +0900 From: Soohong Daniel Park To: nemo@ietf.org Message-id: <006401c38bc3$5eb28ff0$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [nemo] [test mail] please ignore... Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT TEST From nemo-admin@ietf.org Tue Oct 7 02:49:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21129 for ; Tue, 7 Oct 2003 02:49:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6leY-0000cA-Fh; Tue, 07 Oct 2003 02:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6ldl-0000b3-BE for nemo@optimus.ietf.org; Tue, 07 Oct 2003 02:48:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21098; Tue, 7 Oct 2003 02:48:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6ldh-0001r2-00; Tue, 07 Oct 2003 02:48:09 -0400 Received: from [129.254.114.50] (helo=pec.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1A6ldg-0001qm-00; Tue, 07 Oct 2003 02:48:08 -0400 Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.12.9/8.12.9) with SMTP id h97723U3015661; Tue, 7 Oct 2003 16:02:03 +0900 (KST) Message-ID: <016701c38c9e$bee0c9b0$c470fe81@etri.re.kr> From: "Jaehoon Paul Jeong" To: "MANET WG" , "NEMO WG" , "DNSOP WG" Cc: , "Pekka Savola" , "autonet" Date: Tue, 7 Oct 2003 15:46:28 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0164_01C38CEA.2C050BF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [nemo] Applicability of RA-based DNS Discovery (revision) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0164_01C38CEA.2C050BF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpGWUksIEknZCBsaWtlIHRvIGluZm9ybSB5b3Ugb2YgdHdvIG5ldyBkcmFmdHMg cmVsYXRlZCB0byBSQS1iYXNlZCBETlMgZGlzY292ZXJ5Lg0KT25lIGlzIG1pbmUgYW5kIHRoZSBv dGhlciBEYW5pZWwncy4NCg0KMS4gTkQtUHJveHkgYmFzZWQgUm91dGUgYW5kIEROUyBPcHRpbWl6 YXRpb25zIGZvciBNb2JpbGUgTm9kZXMgaW4gTW9iaWxlIE5ldHdvcmsNCiAgICBodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qZW9uZy1uZW1vLXJvLW5kcHJveHktMDEu dHh0DQoNCjIuIEROUyBEaXNjb3ZlcnkgZm9yIGdsb2JhbCBjb25uZWN0aXZpdHkgaW4gSVB2NiBN b2JpbGUgQWQgSG9jIE5ldHdvcmtzIA0KICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LXBhcmstbWFuZXQtZG5zLWRpc2NvdmVyeS1nbG9iYWx2Ni0wMC50eHQNCg0K SW4gdGhlc2UgZHJhZnRzLCBSQS1iYXNlZCBETlMgZGlzY292ZXJ5IGNhbiBmaW5kIGl0cyBhcHBs aWNhYmlsaXR5Lg0KSSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgdGhlIGNvbW1lbnRzIGZyb20gYm90 aCBORU1PIHdnIGFuZCBNQU5FVCB3ZyANCmFzIHdlbGwgYXMgRE5TT1Agd2cuDQoNClRoZSBiYXNl IGRyYWZ0IGZvciB0aGVzZSBpcyAiSVB2NiBETlMgRGlzY292ZXJ5IGJhc2VkIG9uIFJvdXRlciBB ZHZlcnRpc2VtZW50IjsNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWplb25nLWRuc29wLWlwdjYtZG5zLWRpc2NvdmVyeS0wMC50eHQNCg0KVGhhbmtzLg0KDQpSZWdh cmRzLA0KUGF1bA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpKYWVob29uIFBhdWwgSmVvbmcgKFJlc2VhcmNoZXIpDQpURUwuICs4Mi00Mi04 NjAtMTY2NA0KMTYxIEdhamVvbmctRG9uZywgWXVzZW9uZy1HdSwgRGFlamVvbiwgMzA1LTM1MCwg S09SRUENCk5HSSBTdGFuZGFyZCBSZXNlYXJjaCBUZWFtL1BFQy9FVFJJDQpIb21lcGFnZTogaHR0 cDovL3d3dy5hZGhvYy42YW50cy5uZXQvfnBhdWwNCg== ------=_NextPart_000_0164_01C38CEA.2C050BF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI4MDAuMTI2NCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+SGkgYWxsLDxCUj48QlI+RllJLCBJJ2QgbGlr ZSB0byZuYnNwO2luZm9ybSB5b3Ugb2YgdHdvIG5ldyBkcmFmdHMgcmVsYXRlZCANCnRvIFJBLWJh c2VkIEROUyBkaXNjb3ZlcnkuPEJSPk9uZSBpcyBtaW5lIGFuZCB0aGUgb3RoZXIgRGFuaWVsJ3Mu PEJSPjxCUj4xLiANCk5ELVByb3h5IGJhc2VkIFJvdXRlIGFuZCBETlMgT3B0aW1pemF0aW9ucyBm b3IgTW9iaWxlIE5vZGVzIGluIE1vYmlsZSANCk5ldHdvcms8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxBIA0KaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamVv bmctbmVtby1yby1uZHByb3h5LTAxLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtamVvbmctbmVtby1yby1uZHByb3h5LTAxLnR4dDwvQT48QlI+PEJSPjIuIA0K RE5TIERpc2NvdmVyeSBmb3IgZ2xvYmFsIGNvbm5lY3Rpdml0eSBpbiBJUHY2IE1vYmlsZSBBZCBI b2MgTmV0d29ya3MgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxBIA0KaHJlZj0iaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcGFyay1tYW5ldC1kbnMtZGlzY292ZXJ5 LWdsb2JhbHY2LTAwLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtcGFyay1tYW5ldC1kbnMtZGlzY292ZXJ5LWdsb2JhbHY2LTAwLnR4dDwvQT48QlI+PEJSPklu IA0KdGhlc2UgZHJhZnRzLCBSQS1iYXNlZCBETlMgZGlzY292ZXJ5IGNhbiBmaW5kIGl0cyBhcHBs aWNhYmlsaXR5LjxCUj5JIHdvdWxkIGxpa2UgDQp0byByZXF1ZXN0IHRoZSBjb21tZW50cyBmcm9t IGJvdGggTkVNTyB3ZyBhbmQgTUFORVQgd2cgPEJSPmFzIHdlbGwgYXMgRE5TT1AgDQp3Zy48L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlRoZSBiYXNlIGRyYWZ0IGZvciB0aGVzZSBpcyAi SVB2NiBETlMgRGlzY292ZXJ5IGJhc2VkIG9uIFJvdXRlciANCkFkdmVydGlzZW1lbnQiOzwvRElW Pg0KPERJVj48QSANCmhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWplb25nLWRuc29wLWlwdjYtZG5zLWRpc2NvdmVyeS0wMC50eHQiPmh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWplb25nLWRuc29wLWlwdjYtZG5zLWRpc2NvdmVy eS0wMC50eHQ8L0E+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U96rW066a8IA0Kc2l6ZT0yPjwvRk9O VD48QlI+VGhhbmtzLjxCUj48QlI+UmVnYXJkcyw8QlI+UGF1bDxCUj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+SmFlaG9vbiANClBhdWwg SmVvbmcgKFJlc2VhcmNoZXIpPEJSPlRFTC4gKzgyLTQyLTg2MC0xNjY0PEJSPjE2MSBHYWplb25n LURvbmcsIFl1c2VvbmctR3UsIA0KRGFlamVvbiwgMzA1LTM1MCwgS09SRUE8QlI+TkdJIFN0YW5k YXJkIFJlc2VhcmNoIFRlYW0vUEVDL0VUUkk8QlI+SG9tZXBhZ2U6IDxBIA0KaHJlZj0iaHR0cDov L3d3dy5hZGhvYy42YW50cy5uZXQvfnBhdWwiPmh0dHA6Ly93d3cuYWRob2MuNmFudHMubmV0L35w YXVsPC9BPjxCUj48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0164_01C38CEA.2C050BF0-- From exim@www1.ietf.org Tue Oct 7 02:49:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21144 for ; Tue, 7 Oct 2003 02:49:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6led-0000dB-UE for nemo-archive@odin.ietf.org; Tue, 07 Oct 2003 02:49:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h976n7XC002425 for nemo-archive@odin.ietf.org; Tue, 7 Oct 2003 02:49:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6led-0000d2-4B for nemo-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 02:49:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21113 for ; Tue, 7 Oct 2003 02:48:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6leZ-0001rS-00 for nemo-web-archive@ietf.org; Tue, 07 Oct 2003 02:49:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6leY-0001rO-00 for nemo-web-archive@ietf.org; Tue, 07 Oct 2003 02:49:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6leY-0000cA-Fh; Tue, 07 Oct 2003 02:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6ldl-0000b3-BE for nemo@optimus.ietf.org; Tue, 07 Oct 2003 02:48:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21098; Tue, 7 Oct 2003 02:48:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6ldh-0001r2-00; Tue, 07 Oct 2003 02:48:09 -0400 Received: from [129.254.114.50] (helo=pec.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1A6ldg-0001qm-00; Tue, 07 Oct 2003 02:48:08 -0400 Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.12.9/8.12.9) with SMTP id h97723U3015661; Tue, 7 Oct 2003 16:02:03 +0900 (KST) Message-ID: <016701c38c9e$bee0c9b0$c470fe81@etri.re.kr> From: "Jaehoon Paul Jeong" To: "MANET WG" , "NEMO WG" , "DNSOP WG" Cc: , "Pekka Savola" , "autonet" Date: Tue, 7 Oct 2003 15:46:28 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0164_01C38CEA.2C050BF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [nemo] Applicability of RA-based DNS Discovery (revision) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0164_01C38CEA.2C050BF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpGWUksIEknZCBsaWtlIHRvIGluZm9ybSB5b3Ugb2YgdHdvIG5ldyBkcmFmdHMg cmVsYXRlZCB0byBSQS1iYXNlZCBETlMgZGlzY292ZXJ5Lg0KT25lIGlzIG1pbmUgYW5kIHRoZSBv dGhlciBEYW5pZWwncy4NCg0KMS4gTkQtUHJveHkgYmFzZWQgUm91dGUgYW5kIEROUyBPcHRpbWl6 YXRpb25zIGZvciBNb2JpbGUgTm9kZXMgaW4gTW9iaWxlIE5ldHdvcmsNCiAgICBodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qZW9uZy1uZW1vLXJvLW5kcHJveHktMDEu dHh0DQoNCjIuIEROUyBEaXNjb3ZlcnkgZm9yIGdsb2JhbCBjb25uZWN0aXZpdHkgaW4gSVB2NiBN b2JpbGUgQWQgSG9jIE5ldHdvcmtzIA0KICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LXBhcmstbWFuZXQtZG5zLWRpc2NvdmVyeS1nbG9iYWx2Ni0wMC50eHQNCg0K SW4gdGhlc2UgZHJhZnRzLCBSQS1iYXNlZCBETlMgZGlzY292ZXJ5IGNhbiBmaW5kIGl0cyBhcHBs aWNhYmlsaXR5Lg0KSSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgdGhlIGNvbW1lbnRzIGZyb20gYm90 aCBORU1PIHdnIGFuZCBNQU5FVCB3ZyANCmFzIHdlbGwgYXMgRE5TT1Agd2cuDQoNClRoZSBiYXNl IGRyYWZ0IGZvciB0aGVzZSBpcyAiSVB2NiBETlMgRGlzY292ZXJ5IGJhc2VkIG9uIFJvdXRlciBB ZHZlcnRpc2VtZW50IjsNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWplb25nLWRuc29wLWlwdjYtZG5zLWRpc2NvdmVyeS0wMC50eHQNCg0KVGhhbmtzLg0KDQpSZWdh cmRzLA0KUGF1bA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpKYWVob29uIFBhdWwgSmVvbmcgKFJlc2VhcmNoZXIpDQpURUwuICs4Mi00Mi04 NjAtMTY2NA0KMTYxIEdhamVvbmctRG9uZywgWXVzZW9uZy1HdSwgRGFlamVvbiwgMzA1LTM1MCwg S09SRUENCk5HSSBTdGFuZGFyZCBSZXNlYXJjaCBUZWFtL1BFQy9FVFJJDQpIb21lcGFnZTogaHR0 cDovL3d3dy5hZGhvYy42YW50cy5uZXQvfnBhdWwNCg== ------=_NextPart_000_0164_01C38CEA.2C050BF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI4MDAuMTI2NCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+SGkgYWxsLDxCUj48QlI+RllJLCBJJ2QgbGlr ZSB0byZuYnNwO2luZm9ybSB5b3Ugb2YgdHdvIG5ldyBkcmFmdHMgcmVsYXRlZCANCnRvIFJBLWJh c2VkIEROUyBkaXNjb3ZlcnkuPEJSPk9uZSBpcyBtaW5lIGFuZCB0aGUgb3RoZXIgRGFuaWVsJ3Mu PEJSPjxCUj4xLiANCk5ELVByb3h5IGJhc2VkIFJvdXRlIGFuZCBETlMgT3B0aW1pemF0aW9ucyBm b3IgTW9iaWxlIE5vZGVzIGluIE1vYmlsZSANCk5ldHdvcms8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxBIA0KaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamVv bmctbmVtby1yby1uZHByb3h5LTAxLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtamVvbmctbmVtby1yby1uZHByb3h5LTAxLnR4dDwvQT48QlI+PEJSPjIuIA0K RE5TIERpc2NvdmVyeSBmb3IgZ2xvYmFsIGNvbm5lY3Rpdml0eSBpbiBJUHY2IE1vYmlsZSBBZCBI b2MgTmV0d29ya3MgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxBIA0KaHJlZj0iaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcGFyay1tYW5ldC1kbnMtZGlzY292ZXJ5 LWdsb2JhbHY2LTAwLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtcGFyay1tYW5ldC1kbnMtZGlzY292ZXJ5LWdsb2JhbHY2LTAwLnR4dDwvQT48QlI+PEJSPklu IA0KdGhlc2UgZHJhZnRzLCBSQS1iYXNlZCBETlMgZGlzY292ZXJ5IGNhbiBmaW5kIGl0cyBhcHBs aWNhYmlsaXR5LjxCUj5JIHdvdWxkIGxpa2UgDQp0byByZXF1ZXN0IHRoZSBjb21tZW50cyBmcm9t IGJvdGggTkVNTyB3ZyBhbmQgTUFORVQgd2cgPEJSPmFzIHdlbGwgYXMgRE5TT1AgDQp3Zy48L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlRoZSBiYXNlIGRyYWZ0IGZvciB0aGVzZSBpcyAi SVB2NiBETlMgRGlzY292ZXJ5IGJhc2VkIG9uIFJvdXRlciANCkFkdmVydGlzZW1lbnQiOzwvRElW Pg0KPERJVj48QSANCmhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWplb25nLWRuc29wLWlwdjYtZG5zLWRpc2NvdmVyeS0wMC50eHQiPmh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWplb25nLWRuc29wLWlwdjYtZG5zLWRpc2NvdmVy eS0wMC50eHQ8L0E+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U96rW066a8IA0Kc2l6ZT0yPjwvRk9O VD48QlI+VGhhbmtzLjxCUj48QlI+UmVnYXJkcyw8QlI+UGF1bDxCUj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+SmFlaG9vbiANClBhdWwg SmVvbmcgKFJlc2VhcmNoZXIpPEJSPlRFTC4gKzgyLTQyLTg2MC0xNjY0PEJSPjE2MSBHYWplb25n LURvbmcsIFl1c2VvbmctR3UsIA0KRGFlamVvbiwgMzA1LTM1MCwgS09SRUE8QlI+TkdJIFN0YW5k YXJkIFJlc2VhcmNoIFRlYW0vUEVDL0VUUkk8QlI+SG9tZXBhZ2U6IDxBIA0KaHJlZj0iaHR0cDov L3d3dy5hZGhvYy42YW50cy5uZXQvfnBhdWwiPmh0dHA6Ly93d3cuYWRob2MuNmFudHMubmV0L35w YXVsPC9BPjxCUj48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0164_01C38CEA.2C050BF0-- From nemo-admin@ietf.org Wed Oct 8 05:19:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07252 for ; Wed, 8 Oct 2003 05:19:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ATH-0001BF-Jm; Wed, 08 Oct 2003 05:19:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7AT2-00018a-Sd for nemo@optimus.ietf.org; Wed, 08 Oct 2003 05:18:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07195; Wed, 8 Oct 2003 05:18:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ASz-0002WO-00; Wed, 08 Oct 2003 05:18:45 -0400 Received: from [211.91.220.4] (helo=ds20.nudt.edu.cn) by ietf-mx with esmtp (Exim 4.12) id 1A7ASy-0002WJ-00; Wed, 08 Oct 2003 05:18:44 -0400 Received: by ds20.nudt.edu.cn (Postfix, from userid 506) id B4D355BD17; Wed, 8 Oct 2003 17:25:06 +0800 (HKT) From: Wanrong Yu To: nemo@ietf.org, manet@ietf.org Reply-To: Wanrong Yu MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: YH WebMail Program Version 1.5 X-Originating-IP: 172.31.100.22 Message-Id: <20031008092506.B4D355BD17@ds20.nudt.edu.cn> Date: Wed, 8 Oct 2003 17:25:06 +0800 (HKT) Content-Transfer-Encoding: 8bit Subject: [nemo] =?gb2312?B?TkVNTyBvciBNQU5FVD8=?= Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi,all I have read some drafts of NEMO and MANET, but I have some doubts. If there are several mobile networks, each has one or more MRs(we can imagine several cars), these cars meet and want to communication with each other, if the fixed infrastructure is unsable for some reasons, does the communication possible? and how? From the aspect of NEMO, we can loose the restrict of the existence of fixed infrastructure, from the aspect of MANET, we can extend the single node in the ad hoc to a subnet, both will point to the scenario above. I think this maybe a new scenario neithor NEMO or MANET has covered, and there are new issues arise such as routing and security. Does there any researchs on this scenario, or some current technology have solve the problem perfectly? Any comments or advices are welcomed, thanks a lot! Wanrong Yu From exim@www1.ietf.org Wed Oct 8 05:19:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07267 for ; Wed, 8 Oct 2003 05:19:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ATX-0001KR-To for nemo-archive@odin.ietf.org; Wed, 08 Oct 2003 05:19:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h989JJuq005101 for nemo-archive@odin.ietf.org; Wed, 8 Oct 2003 05:19:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ATX-0001KC-OW for nemo-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 05:19:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07218 for ; Wed, 8 Oct 2003 05:19:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ATU-0002Wx-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 05:19:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7ATT-0002Wt-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 05:19:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ATH-0001BF-Jm; Wed, 08 Oct 2003 05:19:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7AT2-00018a-Sd for nemo@optimus.ietf.org; Wed, 08 Oct 2003 05:18:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07195; Wed, 8 Oct 2003 05:18:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ASz-0002WO-00; Wed, 08 Oct 2003 05:18:45 -0400 Received: from [211.91.220.4] (helo=ds20.nudt.edu.cn) by ietf-mx with esmtp (Exim 4.12) id 1A7ASy-0002WJ-00; Wed, 08 Oct 2003 05:18:44 -0400 Received: by ds20.nudt.edu.cn (Postfix, from userid 506) id B4D355BD17; Wed, 8 Oct 2003 17:25:06 +0800 (HKT) From: Wanrong Yu To: nemo@ietf.org, manet@ietf.org Reply-To: Wanrong Yu MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: YH WebMail Program Version 1.5 X-Originating-IP: 172.31.100.22 Message-Id: <20031008092506.B4D355BD17@ds20.nudt.edu.cn> Date: Wed, 8 Oct 2003 17:25:06 +0800 (HKT) Content-Transfer-Encoding: 8bit Subject: [nemo] =?gb2312?B?TkVNTyBvciBNQU5FVD8=?= Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi,all I have read some drafts of NEMO and MANET, but I have some doubts. If there are several mobile networks, each has one or more MRs(we can imagine several cars), these cars meet and want to communication with each other, if the fixed infrastructure is unsable for some reasons, does the communication possible? and how? From the aspect of NEMO, we can loose the restrict of the existence of fixed infrastructure, from the aspect of MANET, we can extend the single node in the ad hoc to a subnet, both will point to the scenario above. I think this maybe a new scenario neithor NEMO or MANET has covered, and there are new issues arise such as routing and security. Does there any researchs on this scenario, or some current technology have solve the problem perfectly? Any comments or advices are welcomed, thanks a lot! Wanrong Yu From nemo-admin@ietf.org Wed Oct 8 05:44:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07952 for ; Wed, 8 Oct 2003 05:44:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ArR-0002wh-OA; Wed, 08 Oct 2003 05:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Aqv-0002wD-Jm for nemo@optimus.ietf.org; Wed, 08 Oct 2003 05:43:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07939; Wed, 8 Oct 2003 05:43:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Aqr-0002p5-00; Wed, 08 Oct 2003 05:43:25 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A7Aqr-0002o9-00; Wed, 08 Oct 2003 05:43:25 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2003 11:41:15 +0200 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h989gpB3015011; Wed, 8 Oct 2003 11:42:51 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Oct 2003 10:42:55 +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" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] NEMO or MANET? Date: Wed, 8 Oct 2003 10:42:54 +0100 Message-ID: Thread-Topic: [nemo] NEMO or MANET? Thread-Index: AcONfWSTLNUVCXvyQISBkdYaN9xinwAAT6Gg From: "Pascal Thubert (pthubert)" To: "Wanrong Yu" , , X-OriginalArrivalTime: 08 Oct 2003 09:42:55.0645 (UTC) FILETIME=[8CF124D0:01C38D80] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi: I like your summary, and agree with most of it. From the Nemo standpoint, you need the HA in the picture to set the initial pointers, and then RO can take over, even if you loose connectivity to the HA. Also, if you build an engineered structure with the relevant HAs in place -you may have a hierarchical pyramid of HAs-, you can move the structure independently of the global infrastructure and preserve inner connectivity.=20 But more than that seems to me out of the scope of Nemo. Pascal > -----Original Message----- > From: Wanrong Yu [mailto:wlyu@nudt.edu.cn] > Sent: mercredi 8 octobre 2003 11:25 > To: nemo@ietf.org; manet@ietf.org > Subject: [nemo] NEMO or MANET? >=20 > Hi,all > I have read some drafts of NEMO and MANET, but I > have some doubts. If there are several mobile networks, > each has one or more MRs(we can imagine several cars), > these cars meet and want to communication with each > other, if the fixed infrastructure is unsable for some > reasons, does the communication possible? and how? > From the aspect of NEMO, we can loose the restrict > of the existence of fixed infrastructure, from the > aspect of MANET, we can extend the single node in the > ad hoc to a subnet, both will point to the scenario > above. I think this maybe a new scenario neithor NEMO > or MANET has covered, and there are new issues arise > such as routing and security. > Does there any researchs on this scenario, or some > current technology have solve the problem perfectly? > Any comments or advices are welcomed, thanks a lot! >=20 > Wanrong Yu From exim@www1.ietf.org Wed Oct 8 05:44:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07970 for ; Wed, 8 Oct 2003 05:44:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ArU-0002xj-LK for nemo-archive@odin.ietf.org; Wed, 08 Oct 2003 05:44:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h989i4ow011381 for nemo-archive@odin.ietf.org; Wed, 8 Oct 2003 05:44:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ArU-0002xU-G2 for nemo-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 05:44:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07949 for ; Wed, 8 Oct 2003 05:43:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ArQ-0002pN-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 05:44:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7ArQ-0002pK-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 05:44:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ArR-0002wh-OA; Wed, 08 Oct 2003 05:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Aqv-0002wD-Jm for nemo@optimus.ietf.org; Wed, 08 Oct 2003 05:43:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07939; Wed, 8 Oct 2003 05:43:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Aqr-0002p5-00; Wed, 08 Oct 2003 05:43:25 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A7Aqr-0002o9-00; Wed, 08 Oct 2003 05:43:25 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2003 11:41:15 +0200 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h989gpB3015011; Wed, 8 Oct 2003 11:42:51 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Oct 2003 10:42:55 +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" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] NEMO or MANET? Date: Wed, 8 Oct 2003 10:42:54 +0100 Message-ID: Thread-Topic: [nemo] NEMO or MANET? Thread-Index: AcONfWSTLNUVCXvyQISBkdYaN9xinwAAT6Gg From: "Pascal Thubert (pthubert)" To: "Wanrong Yu" , , X-OriginalArrivalTime: 08 Oct 2003 09:42:55.0645 (UTC) FILETIME=[8CF124D0:01C38D80] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi: I like your summary, and agree with most of it. From the Nemo standpoint, you need the HA in the picture to set the initial pointers, and then RO can take over, even if you loose connectivity to the HA. Also, if you build an engineered structure with the relevant HAs in place -you may have a hierarchical pyramid of HAs-, you can move the structure independently of the global infrastructure and preserve inner connectivity.=20 But more than that seems to me out of the scope of Nemo. Pascal > -----Original Message----- > From: Wanrong Yu [mailto:wlyu@nudt.edu.cn] > Sent: mercredi 8 octobre 2003 11:25 > To: nemo@ietf.org; manet@ietf.org > Subject: [nemo] NEMO or MANET? >=20 > Hi,all > I have read some drafts of NEMO and MANET, but I > have some doubts. If there are several mobile networks, > each has one or more MRs(we can imagine several cars), > these cars meet and want to communication with each > other, if the fixed infrastructure is unsable for some > reasons, does the communication possible? and how? > From the aspect of NEMO, we can loose the restrict > of the existence of fixed infrastructure, from the > aspect of MANET, we can extend the single node in the > ad hoc to a subnet, both will point to the scenario > above. I think this maybe a new scenario neithor NEMO > or MANET has covered, and there are new issues arise > such as routing and security. > Does there any researchs on this scenario, or some > current technology have solve the problem perfectly? > Any comments or advices are welcomed, thanks a lot! >=20 > Wanrong Yu From nemo-admin@ietf.org Wed Oct 8 06:45:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09104 for ; Wed, 8 Oct 2003 06:45:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7BoT-0005SA-GM; Wed, 08 Oct 2003 06:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Bnx-0005RH-48 for nemo@optimus.ietf.org; Wed, 08 Oct 2003 06:44:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09065 for ; Wed, 8 Oct 2003 06:44:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Bns-0003Gg-00 for nemo@ietf.org; Wed, 08 Oct 2003 06:44:24 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1A7Bns-0003Gd-00 for nemo@ietf.org; Wed, 08 Oct 2003 06:44:24 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id h98Ahx3Q014565; Wed, 8 Oct 2003 03:43:59 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h98AhcJ1013708; Wed, 8 Oct 2003 05:43:39 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id CD3262EC95; Wed, 8 Oct 2003 12:44:13 +0200 (CEST) Message-ID: <3F83EA7D.40901@nal.motlabs.com> Date: Wed, 08 Oct 2003 12:44:13 +0200 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: Wanrong Yu Cc: nemo@ietf.org Subject: Re: [nemo] NEMO or MANET? References: <20031008092506.B4D355BD17@ds20.nudt.edu.cn> In-Reply-To: <20031008092506.B4D355BD17@ds20.nudt.edu.cn> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Wanrong Yu wrote: > Hi,all I have read some drafts of NEMO and MANET, but I have some > doubts. If there are several mobile networks, each has one or more > MRs(we can imagine several cars), these cars meet and want to > communication with each other, if the fixed infrastructure is unsable > for some reasons, does the communication possible? and how? I assume from your description that there is one moving network per vehicle, the vehicles are close by and are stationary, and that there is no fixed infrastructure to which the vehicles' MRs would connect. In this case, one MR of one vehicle could attach to the moving network of the other vehicle, such as to form a sort of "nested moving network". Assume that the receving moving network (or the top-level moving network, or the parent network) has a set of IPv6 addresses that it could delegate (by DHCP prefix delegation mechanisms) to the moving network that visits it. Communication is thus possible between all entities of the nested aggregation (all devices in both vehicles communicate to each other). The top-level moving network becomes the home of the network that is attached under it. This might work ok, because there is no infrastructure available. Once the infrastructure becomes available, both moving networks should try to contact their respective home links, and the inter-vehicle comm scenario would be different (no DHCP prefix delegation, but use RO). > From the aspect of NEMO, we can loose the restrict of the existence > of fixed infrastructure, Ok, for the purpose of obtaining what? > from the aspect of MANET, we can extend the single node in the ad hoc > to a subnet, both will point to the scenario above. I think this > maybe a new scenario neithor NEMO or MANET has covered, and there are > new issues arise such as routing and security. Does there any > researchs on this scenario, or some current technology have solve the > problem perfectly? Any comments or advices are welcomed, thanks a > lot! You sure are aware of the MANET WG and ANS RG. The MANET Gateways. I've heard of a Deutsche (German) project looking at using manet networks for inter-vehicle communication, I think it's named FleetNet. There is also InternetCAR in Japan and others. Alex GBU From exim@www1.ietf.org Wed Oct 8 06:45:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09119 for ; Wed, 8 Oct 2003 06:45:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7BoZ-0005TA-OS for nemo-archive@odin.ietf.org; Wed, 08 Oct 2003 06:45:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Aj7xD021021 for nemo-archive@odin.ietf.org; Wed, 8 Oct 2003 06:45:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7BoZ-0005Sx-Jl for nemo-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 06:45:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09096 for ; Wed, 8 Oct 2003 06:44:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7BoV-0003H4-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 06:45:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7BoV-0003H1-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 06:45:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7BoT-0005SA-GM; Wed, 08 Oct 2003 06:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Bnx-0005RH-48 for nemo@optimus.ietf.org; Wed, 08 Oct 2003 06:44:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09065 for ; Wed, 8 Oct 2003 06:44:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Bns-0003Gg-00 for nemo@ietf.org; Wed, 08 Oct 2003 06:44:24 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1A7Bns-0003Gd-00 for nemo@ietf.org; Wed, 08 Oct 2003 06:44:24 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id h98Ahx3Q014565; Wed, 8 Oct 2003 03:43:59 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h98AhcJ1013708; Wed, 8 Oct 2003 05:43:39 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id CD3262EC95; Wed, 8 Oct 2003 12:44:13 +0200 (CEST) Message-ID: <3F83EA7D.40901@nal.motlabs.com> Date: Wed, 08 Oct 2003 12:44:13 +0200 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: Wanrong Yu Cc: nemo@ietf.org Subject: Re: [nemo] NEMO or MANET? References: <20031008092506.B4D355BD17@ds20.nudt.edu.cn> In-Reply-To: <20031008092506.B4D355BD17@ds20.nudt.edu.cn> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Wanrong Yu wrote: > Hi,all I have read some drafts of NEMO and MANET, but I have some > doubts. If there are several mobile networks, each has one or more > MRs(we can imagine several cars), these cars meet and want to > communication with each other, if the fixed infrastructure is unsable > for some reasons, does the communication possible? and how? I assume from your description that there is one moving network per vehicle, the vehicles are close by and are stationary, and that there is no fixed infrastructure to which the vehicles' MRs would connect. In this case, one MR of one vehicle could attach to the moving network of the other vehicle, such as to form a sort of "nested moving network". Assume that the receving moving network (or the top-level moving network, or the parent network) has a set of IPv6 addresses that it could delegate (by DHCP prefix delegation mechanisms) to the moving network that visits it. Communication is thus possible between all entities of the nested aggregation (all devices in both vehicles communicate to each other). The top-level moving network becomes the home of the network that is attached under it. This might work ok, because there is no infrastructure available. Once the infrastructure becomes available, both moving networks should try to contact their respective home links, and the inter-vehicle comm scenario would be different (no DHCP prefix delegation, but use RO). > From the aspect of NEMO, we can loose the restrict of the existence > of fixed infrastructure, Ok, for the purpose of obtaining what? > from the aspect of MANET, we can extend the single node in the ad hoc > to a subnet, both will point to the scenario above. I think this > maybe a new scenario neithor NEMO or MANET has covered, and there are > new issues arise such as routing and security. Does there any > researchs on this scenario, or some current technology have solve the > problem perfectly? Any comments or advices are welcomed, thanks a > lot! You sure are aware of the MANET WG and ANS RG. The MANET Gateways. I've heard of a Deutsche (German) project looking at using manet networks for inter-vehicle communication, I think it's named FleetNet. There is also InternetCAR in Japan and others. Alex GBU From nemo-admin@ietf.org Wed Oct 8 08:17:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11262 for ; Wed, 8 Oct 2003 08:17:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DFV-00015V-KF; Wed, 08 Oct 2003 08:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DA3-0000YW-7R for nemo@optimus.ietf.org; Wed, 08 Oct 2003 08:11:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11056; Wed, 8 Oct 2003 08:11:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7DA1-0003xv-00; Wed, 08 Oct 2003 08:11:22 -0400 Received: from emroute1.cind.ornl.gov ([160.91.4.119]) by ietf-mx with esmtp (Exim 4.12) id 1A7DA1-0003xm-00; Wed, 08 Oct 2003 08:11:21 -0400 Received: from emroute1.cind.ornl.gov (localhost [127.0.0.1]) by emroute1.cind.ornl.gov (PMDF V6.2-X17 #30669) with ESMTP id <0HMF00N1FTUP48@emroute1.cind.ornl.gov>; Wed, 08 Oct 2003 08:11:15 -0400 (EDT) Received: from exchange.ornl.gov (exchange1.ornl.gov [160.91.1.20]) by emroute1.cind.ornl.gov (PMDF V6.2-X17 #30669) with ESMTP id <0HMF0036ATUJBN@emroute1.cind.ornl.gov>; Wed, 08 Oct 2003 08:11:07 -0400 (EDT) Date: Wed, 08 Oct 2003 08:11:06 -0400 From: Lawrence MacIntyre In-reply-to: <20031008092506.B4D355BD17@ds20.nudt.edu.cn> To: Wanrong Yu Cc: nemo@ietf.org, manet@ietf.org Message-id: <1065615066.1341.102.camel@nautique> Organization: High Performance Information Infrastructure Group MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-KhVgr0J70tpIQKxPZ6BC" References: <20031008092506.B4D355BD17@ds20.nudt.edu.cn> Subject: [nemo] Re: [manet] NEMO or MANET? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --=-KhVgr0J70tpIQKxPZ6BC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable For MANET, this is no problem at all. The Mobile Routers (cars) will discover each other and communicate directly. There is no need for any fixed infrastructure. On Wed, 2003-10-08 at 05:25, Wanrong Yu wrote: > Hi,all > I have read some drafts of NEMO and MANET, but I=20 > have some doubts. If there are several mobile networks, > each has one or more MRs(we can imagine several cars),=20 > these cars meet and want to communication with each=20 > other, if the fixed infrastructure is unsable for some=20 > reasons, does the communication possible? and how? > From the aspect of NEMO, we can loose the restrict=20 > of the existence of fixed infrastructure, from the=20 > aspect of MANET, we can extend the single node in the=20 > ad hoc to a subnet, both will point to the scenario=20 > above. I think this maybe a new scenario neithor NEMO=20 > or MANET has covered, and there are new issues arise=20 > such as routing and security. > Does there any researchs on this scenario, or some=20 > current technology have solve the problem perfectly? > Any comments or advices are welcomed, thanks a lot! >=20 > Wanrong Yu >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet --=20 Lawrence MacIntyre 865.574.8696 lpz@ornl.gov Oak Ridge National Laboratory High Performance Information Infrastructure Technology Group --=-KhVgr0J70tpIQKxPZ6BC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA/g/7aCNjP8rawCW4RAgj8AJ9O/iDoj/P6kKUzr+HpBPweaRbfhQCePNzT aQH7HWgw+LwQYO3i6eDXbpU= =u9FZ -----END PGP SIGNATURE----- --=-KhVgr0J70tpIQKxPZ6BC-- From exim@www1.ietf.org Wed Oct 8 08:17:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11277 for ; Wed, 8 Oct 2003 08:17:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DFz-0001E5-2v for nemo-archive@odin.ietf.org; Wed, 08 Oct 2003 08:17:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98CHVOX004707 for nemo-archive@odin.ietf.org; Wed, 8 Oct 2003 08:17:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DFy-0001Dq-V0 for nemo-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 08:17:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11234 for ; Wed, 8 Oct 2003 08:17:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7DFx-00042k-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 08:17:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7DFx-00042h-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 08:17:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DFV-00015V-KF; Wed, 08 Oct 2003 08:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7DA3-0000YW-7R for nemo@optimus.ietf.org; Wed, 08 Oct 2003 08:11:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11056; Wed, 8 Oct 2003 08:11:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7DA1-0003xv-00; Wed, 08 Oct 2003 08:11:22 -0400 Received: from emroute1.cind.ornl.gov ([160.91.4.119]) by ietf-mx with esmtp (Exim 4.12) id 1A7DA1-0003xm-00; Wed, 08 Oct 2003 08:11:21 -0400 Received: from emroute1.cind.ornl.gov (localhost [127.0.0.1]) by emroute1.cind.ornl.gov (PMDF V6.2-X17 #30669) with ESMTP id <0HMF00N1FTUP48@emroute1.cind.ornl.gov>; Wed, 08 Oct 2003 08:11:15 -0400 (EDT) Received: from exchange.ornl.gov (exchange1.ornl.gov [160.91.1.20]) by emroute1.cind.ornl.gov (PMDF V6.2-X17 #30669) with ESMTP id <0HMF0036ATUJBN@emroute1.cind.ornl.gov>; Wed, 08 Oct 2003 08:11:07 -0400 (EDT) Date: Wed, 08 Oct 2003 08:11:06 -0400 From: Lawrence MacIntyre In-reply-to: <20031008092506.B4D355BD17@ds20.nudt.edu.cn> To: Wanrong Yu Cc: nemo@ietf.org, manet@ietf.org Message-id: <1065615066.1341.102.camel@nautique> Organization: High Performance Information Infrastructure Group MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-KhVgr0J70tpIQKxPZ6BC" References: <20031008092506.B4D355BD17@ds20.nudt.edu.cn> Subject: [nemo] Re: [manet] NEMO or MANET? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --=-KhVgr0J70tpIQKxPZ6BC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable For MANET, this is no problem at all. The Mobile Routers (cars) will discover each other and communicate directly. There is no need for any fixed infrastructure. On Wed, 2003-10-08 at 05:25, Wanrong Yu wrote: > Hi,all > I have read some drafts of NEMO and MANET, but I=20 > have some doubts. If there are several mobile networks, > each has one or more MRs(we can imagine several cars),=20 > these cars meet and want to communication with each=20 > other, if the fixed infrastructure is unsable for some=20 > reasons, does the communication possible? and how? > From the aspect of NEMO, we can loose the restrict=20 > of the existence of fixed infrastructure, from the=20 > aspect of MANET, we can extend the single node in the=20 > ad hoc to a subnet, both will point to the scenario=20 > above. I think this maybe a new scenario neithor NEMO=20 > or MANET has covered, and there are new issues arise=20 > such as routing and security. > Does there any researchs on this scenario, or some=20 > current technology have solve the problem perfectly? > Any comments or advices are welcomed, thanks a lot! >=20 > Wanrong Yu >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet --=20 Lawrence MacIntyre 865.574.8696 lpz@ornl.gov Oak Ridge National Laboratory High Performance Information Infrastructure Technology Group --=-KhVgr0J70tpIQKxPZ6BC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA/g/7aCNjP8rawCW4RAgj8AJ9O/iDoj/P6kKUzr+HpBPweaRbfhQCePNzT aQH7HWgw+LwQYO3i6eDXbpU= =u9FZ -----END PGP SIGNATURE----- --=-KhVgr0J70tpIQKxPZ6BC-- From nemo-admin@ietf.org Wed Oct 8 08:40:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11995 for ; Wed, 8 Oct 2003 08:40:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Dbo-0002w4-A6; Wed, 08 Oct 2003 08:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Dap-0002kp-Vf for nemo@optimus.ietf.org; Wed, 08 Oct 2003 08:39:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11914; Wed, 8 Oct 2003 08:38:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Dao-0004IM-00; Wed, 08 Oct 2003 08:39:02 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A7Dam-0004I2-00; Wed, 08 Oct 2003 08:39:02 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 08 Oct 2003 05:39:24 -0700 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h98CbpZ1002121; Wed, 8 Oct 2003 05:38:27 -0700 (PDT) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Oct 2003 13:38:24 +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" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [manet] NEMO or MANET? Date: Wed, 8 Oct 2003 13:38:23 +0100 Message-ID: Thread-Topic: [nemo] Re: [manet] NEMO or MANET? Thread-Index: AcONlmg/qjQ49or7QmGoUB3AqvdtUQAAbzvA From: "Pascal Thubert (pthubert)" To: "Lawrence MacIntyre" , "Wanrong Yu" Cc: , X-OriginalArrivalTime: 08 Oct 2003 12:38:24.0902 (UTC) FILETIME=[10DE4260:01C38D99] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Lawrence: I guess the question was not about the car address, but the prefix behind it. Like a MANET router with a bunch of non manet enabled nodes attached to it.=20 One way of seeing this is a lookup that resolved the "dumb" node prefix into a via manet router (this is a constant) and then resolves where the manet router is (say using a flooding). Another is to flood directly to the "dumb" node address but then the manet router has to terminate the protocol and respond itself. This is all the difference between MIP and Nemo, actually. I may be missing something but I'm not sure this is fully addressed in MANET either? Pascal=20 > -----Original Message----- > From: Lawrence MacIntyre [mailto:lpz@ornl.gov] > Sent: mercredi 8 octobre 2003 14:11 > To: Wanrong Yu > Cc: nemo@ietf.org; manet@ietf.org > Subject: [nemo] Re: [manet] NEMO or MANET? >=20 > For MANET, this is no problem at all. The Mobile Routers (cars) will > discover each other and communicate directly. There is no need for any > fixed infrastructure. >=20 > On Wed, 2003-10-08 at 05:25, Wanrong Yu wrote: > > Hi,all > > I have read some drafts of NEMO and MANET, but I > > have some doubts. If there are several mobile networks, > > each has one or more MRs(we can imagine several cars), > > these cars meet and want to communication with each > > other, if the fixed infrastructure is unsable for some > > reasons, does the communication possible? and how? > > From the aspect of NEMO, we can loose the restrict > > of the existence of fixed infrastructure, from the > > aspect of MANET, we can extend the single node in the > > ad hoc to a subnet, both will point to the scenario > > above. I think this maybe a new scenario neithor NEMO > > or MANET has covered, and there are new issues arise > > such as routing and security. > > Does there any researchs on this scenario, or some > > current technology have solve the problem perfectly? > > Any comments or advices are welcomed, thanks a lot! > > > > Wanrong Yu > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > -- > Lawrence MacIntyre 865.574.8696 lpz@ornl.gov > Oak Ridge National Laboratory > High Performance Information Infrastructure Technology Group From nemo-admin@ietf.org Wed Oct 8 10:56:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19748 for ; Wed, 8 Oct 2003 10:56:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7FjM-0002UV-AF; Wed, 08 Oct 2003 10:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Eu9-0007c8-Rh for nemo@optimus.ietf.org; Wed, 08 Oct 2003 10:03:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15238; Wed, 8 Oct 2003 10:02:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Eu7-0005J3-00; Wed, 08 Oct 2003 10:03:03 -0400 Received: from emroute1.cind.ornl.gov ([160.91.4.119]) by ietf-mx with esmtp (Exim 4.12) id 1A7Eu6-0005J0-00; Wed, 08 Oct 2003 10:03:03 -0400 Received: from emroute1.cind.ornl.gov (localhost [127.0.0.1]) by emroute1.cind.ornl.gov (PMDF V6.2-X17 #30669) with ESMTP id <0HMF00AR5Z0V3D@emroute1.cind.ornl.gov>; Wed, 08 Oct 2003 10:03:00 -0400 (EDT) Received: from exchange.ornl.gov (exchange1.ornl.gov [160.91.1.20]) by emroute1.cind.ornl.gov (PMDF V6.2-X17 #30669) with ESMTP id <0HMF00BL4Z0TUH@emroute1.cind.ornl.gov>; Wed, 08 Oct 2003 10:02:53 -0400 (EDT) Date: Wed, 08 Oct 2003 10:02:52 -0400 From: Lawrence MacIntyre Subject: RE: [nemo] Re: [manet] NEMO or MANET? In-reply-to: To: "Pascal Thubert (pthubert)" Cc: Lawrence MacIntyre , Wanrong Yu , nemo@ietf.org, manet@ietf.org Message-id: <1065621772.1341.167.camel@nautique> Organization: High Performance Information Infrastructure Group MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-GknvmLy/+24zBU3ZnSF3" References: Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --=-GknvmLy/+24zBU3ZnSF3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'm not sure I understand your comment (or was it a question?). If you have a reason to communicate with a node, you need to know its address.=20 In the case of a non-routing node behind a MANET router, it would ideally share the network address of that router, just as nodes behind a standard IP router share the network address of their router. MANETs are just like infrastructured networks in that respect. The only difference is that the interconnectivity is not fixed. The routing protocol is designed to discover and utilize connectivity. To communicate with a node, you must have a way to learn its address, but that is not part of the routing protocol. On Wed, 2003-10-08 at 08:38, Pascal Thubert (pthubert) wrote: > Hi Lawrence: >=20 > I guess the question was not about the car address, but the prefix > behind it. Like a MANET router with a bunch of non manet enabled nodes > attached to it.=20 >=20 > One way of seeing this is a lookup that resolved the "dumb" node prefix > into a via manet router (this is a constant) and then resolves where the > manet router is (say using a flooding). Another is to flood directly to > the "dumb" node address but then the manet router has to terminate the > protocol and respond itself. >=20 > This is all the difference between MIP and Nemo, actually. I may be > missing something but I'm not sure this is fully addressed in MANET > either? >=20 > Pascal=20 >=20 > > -----Original Message----- > > From: Lawrence MacIntyre [mailto:lpz@ornl.gov] > > Sent: mercredi 8 octobre 2003 14:11 > > To: Wanrong Yu > > Cc: nemo@ietf.org; manet@ietf.org > > Subject: [nemo] Re: [manet] NEMO or MANET? > >=20 > > For MANET, this is no problem at all. The Mobile Routers (cars) will > > discover each other and communicate directly. There is no need for > any > > fixed infrastructure. > >=20 > > On Wed, 2003-10-08 at 05:25, Wanrong Yu wrote: > > > Hi,all > > > I have read some drafts of NEMO and MANET, but I > > > have some doubts. If there are several mobile networks, > > > each has one or more MRs(we can imagine several cars), > > > these cars meet and want to communication with each > > > other, if the fixed infrastructure is unsable for some > > > reasons, does the communication possible? and how? > > > From the aspect of NEMO, we can loose the restrict > > > of the existence of fixed infrastructure, from the > > > aspect of MANET, we can extend the single node in the > > > ad hoc to a subnet, both will point to the scenario > > > above. I think this maybe a new scenario neithor NEMO > > > or MANET has covered, and there are new issues arise > > > such as routing and security. > > > Does there any researchs on this scenario, or some > > > current technology have solve the problem perfectly? > > > Any comments or advices are welcomed, thanks a lot! > > > > > > Wanrong Yu > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > -- > > Lawrence MacIntyre 865.574.8696 lpz@ornl.gov > > Oak Ridge National Laboratory > > High Performance Information Infrastructure Technology Group --=20 Lawrence MacIntyre 865.574.8696 lpz@ornl.gov Oak Ridge National Laboratory High Performance Information Infrastructure Technology Group --=-GknvmLy/+24zBU3ZnSF3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA/hBkMCNjP8rawCW4RAnHEAKCMCEazUcWQSGSRMGX1sVzXrgorEQCeKjw6 HGccg0e2+gaNFhFpqwODv3w= =UY0V -----END PGP SIGNATURE----- --=-GknvmLy/+24zBU3ZnSF3-- From exim@www1.ietf.org Wed Oct 8 10:56:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19764 for ; Wed, 8 Oct 2003 10:56:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Fja-0002X0-Kg for nemo-archive@odin.ietf.org; Wed, 08 Oct 2003 10:56:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98EuEgR009724 for nemo-archive@odin.ietf.org; Wed, 8 Oct 2003 10:56:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Fja-0002Wl-F4 for nemo-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 10:56:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19695 for ; Wed, 8 Oct 2003 10:56:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7FjX-0006Iz-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 10:56:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7FjX-0006Iv-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 10:56:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7FjM-0002UV-AF; Wed, 08 Oct 2003 10:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Eu9-0007c8-Rh for nemo@optimus.ietf.org; Wed, 08 Oct 2003 10:03:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15238; Wed, 8 Oct 2003 10:02:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Eu7-0005J3-00; Wed, 08 Oct 2003 10:03:03 -0400 Received: from emroute1.cind.ornl.gov ([160.91.4.119]) by ietf-mx with esmtp (Exim 4.12) id 1A7Eu6-0005J0-00; Wed, 08 Oct 2003 10:03:03 -0400 Received: from emroute1.cind.ornl.gov (localhost [127.0.0.1]) by emroute1.cind.ornl.gov (PMDF V6.2-X17 #30669) with ESMTP id <0HMF00AR5Z0V3D@emroute1.cind.ornl.gov>; Wed, 08 Oct 2003 10:03:00 -0400 (EDT) Received: from exchange.ornl.gov (exchange1.ornl.gov [160.91.1.20]) by emroute1.cind.ornl.gov (PMDF V6.2-X17 #30669) with ESMTP id <0HMF00BL4Z0TUH@emroute1.cind.ornl.gov>; Wed, 08 Oct 2003 10:02:53 -0400 (EDT) Date: Wed, 08 Oct 2003 10:02:52 -0400 From: Lawrence MacIntyre Subject: RE: [nemo] Re: [manet] NEMO or MANET? In-reply-to: To: "Pascal Thubert (pthubert)" Cc: Lawrence MacIntyre , Wanrong Yu , nemo@ietf.org, manet@ietf.org Message-id: <1065621772.1341.167.camel@nautique> Organization: High Performance Information Infrastructure Group MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-GknvmLy/+24zBU3ZnSF3" References: Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --=-GknvmLy/+24zBU3ZnSF3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'm not sure I understand your comment (or was it a question?). If you have a reason to communicate with a node, you need to know its address.=20 In the case of a non-routing node behind a MANET router, it would ideally share the network address of that router, just as nodes behind a standard IP router share the network address of their router. MANETs are just like infrastructured networks in that respect. The only difference is that the interconnectivity is not fixed. The routing protocol is designed to discover and utilize connectivity. To communicate with a node, you must have a way to learn its address, but that is not part of the routing protocol. On Wed, 2003-10-08 at 08:38, Pascal Thubert (pthubert) wrote: > Hi Lawrence: >=20 > I guess the question was not about the car address, but the prefix > behind it. Like a MANET router with a bunch of non manet enabled nodes > attached to it.=20 >=20 > One way of seeing this is a lookup that resolved the "dumb" node prefix > into a via manet router (this is a constant) and then resolves where the > manet router is (say using a flooding). Another is to flood directly to > the "dumb" node address but then the manet router has to terminate the > protocol and respond itself. >=20 > This is all the difference between MIP and Nemo, actually. I may be > missing something but I'm not sure this is fully addressed in MANET > either? >=20 > Pascal=20 >=20 > > -----Original Message----- > > From: Lawrence MacIntyre [mailto:lpz@ornl.gov] > > Sent: mercredi 8 octobre 2003 14:11 > > To: Wanrong Yu > > Cc: nemo@ietf.org; manet@ietf.org > > Subject: [nemo] Re: [manet] NEMO or MANET? > >=20 > > For MANET, this is no problem at all. The Mobile Routers (cars) will > > discover each other and communicate directly. There is no need for > any > > fixed infrastructure. > >=20 > > On Wed, 2003-10-08 at 05:25, Wanrong Yu wrote: > > > Hi,all > > > I have read some drafts of NEMO and MANET, but I > > > have some doubts. If there are several mobile networks, > > > each has one or more MRs(we can imagine several cars), > > > these cars meet and want to communication with each > > > other, if the fixed infrastructure is unsable for some > > > reasons, does the communication possible? and how? > > > From the aspect of NEMO, we can loose the restrict > > > of the existence of fixed infrastructure, from the > > > aspect of MANET, we can extend the single node in the > > > ad hoc to a subnet, both will point to the scenario > > > above. I think this maybe a new scenario neithor NEMO > > > or MANET has covered, and there are new issues arise > > > such as routing and security. > > > Does there any researchs on this scenario, or some > > > current technology have solve the problem perfectly? > > > Any comments or advices are welcomed, thanks a lot! > > > > > > Wanrong Yu > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > -- > > Lawrence MacIntyre 865.574.8696 lpz@ornl.gov > > Oak Ridge National Laboratory > > High Performance Information Infrastructure Technology Group --=20 Lawrence MacIntyre 865.574.8696 lpz@ornl.gov Oak Ridge National Laboratory High Performance Information Infrastructure Technology Group --=-GknvmLy/+24zBU3ZnSF3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA/hBkMCNjP8rawCW4RAnHEAKCMCEazUcWQSGSRMGX1sVzXrgorEQCeKjw6 HGccg0e2+gaNFhFpqwODv3w= =UY0V -----END PGP SIGNATURE----- --=-GknvmLy/+24zBU3ZnSF3-- From nemo-admin@ietf.org Wed Oct 8 12:07:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25210 for ; Wed, 8 Oct 2003 12:07:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Gq7-00078Y-OX; Wed, 08 Oct 2003 12:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Gpo-00075d-VY for nemo@optimus.ietf.org; Wed, 08 Oct 2003 12:06:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25140; Wed, 8 Oct 2003 12:06:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Gpn-0000L9-00; Wed, 08 Oct 2003 12:06:43 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1A7Gpm-0000L6-00; Wed, 08 Oct 2003 12:06:42 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h98G6VC7012209; Wed, 8 Oct 2003 09:06:32 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h98G6RSt029803; Wed, 8 Oct 2003 11:06:29 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 3F0DF2ED4E; Wed, 8 Oct 2003 18:06:24 +0200 (CEST) Message-ID: <3F843600.50804@nal.motlabs.com> Date: Wed, 08 Oct 2003 18:06:24 +0200 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: Lawrence MacIntyre Cc: "Pascal Thubert (pthubert)" , Lawrence MacIntyre , Wanrong Yu , nemo@ietf.org, manet@ietf.org Subject: Re: [nemo] Re: [manet] NEMO or MANET? References: <1065621772.1341.167.camel@nautique> In-Reply-To: <1065621772.1341.167.camel@nautique> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Lawrence MacIntyre wrote: > The routing protocol is designed to discover and utilize > connectivity. To communicate with a node, you must have a way to > learn its address, but that is not part of the routing protocol. I agree with that. I agree there is no way for two manet islands completely unknown to each other, each one having its own addressing scheme and deployed addresses, to sort of "join" one another and for their routing tables to get updated accordingly. I mean, assume a manet1 made of two nodes with addresses m11 and m12 respectively, and another manet2 made of other two nodes m21 and m22. When the two manets are separated, communication is ok between m11 and m12, and between m21 and m22. Join them by drawing a link between m11 and m21. After the "join" phase, I don't think there is any manet technique/protocol that would allow m22 and m11 communicate directly. What happens if, by lack of chance, nodes in the two manet islands were initially assigned the same addresses (pairwise: m11 equals m21 and m12 equals m22, but still m11 different than m12 and m21 diff m22)? Communication inside manet1 is ok, and inside manet2 is also ok, but not across. A way of looking at those two networks is to consider that one of them has many available addresses. Distributes some of them to its own nodes by simple DHCP, and keeps a subset of addresses for distribution (by DHCP prefix delegation) to the other network that "visits" it. In this way address conflicts are avoided. The way the NEMO WG group looks at this (if I interpret it correctly) is that the DHCP prefix delegation can happen in this way only if infrastructure is not available (if available then DHCP prefix delegation happens between the home network and the moving network, not between the moving network and the fixed access system). I think this way of supporting two moving networks in two different vehicles that need to "join" (while infrastructure is not available) is viable. And, because the discussion was triggered with a vehicular background in mind, there are many potential scenarios related the way this is deployed, and what's the business need for it. If a manufacturer wants its cars to be able to talk to each other such as to automatically avoid collisions while in a bumper-to-bumper traffic jam, then it would assign unique addresses to all its vehicles, and a same unique manet protocol on all vehicles, then two cars of same model could easily talk to each other w/o infrastructure present. If on the other hand, manufacturer has a need to remotely update software deployed in a car, or garage remotely measures mileage and calls driver for periodic checkup, then this requires communication over the Internet, with the help of fixed infrastructure, so manet protocols are not needed at all (but Mobile IP for moving networks yes). Or again, if a fixed camera measures speed of bypassing vehicles and notifies driver about crossing limits and fines to pay, in a live manner, then again, infrastructure is needed, Mobile IP yes, and manet no. IMHO choosing between manet protocols and Mobile IP-based solution depends largely on the vehicular scenario involved; what's your scenario Wanrong? Alex GBU From exim@www1.ietf.org Wed Oct 8 12:07:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25243 for ; Wed, 8 Oct 2003 12:07:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7GqB-0007AT-3R for nemo-archive@odin.ietf.org; Wed, 08 Oct 2003 12:07:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98G76lo027545 for nemo-archive@odin.ietf.org; Wed, 8 Oct 2003 12:07:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7GqA-0007AC-8Z for nemo-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 12:07:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25180 for ; Wed, 8 Oct 2003 12:06:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Gq8-0000M8-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 12:07:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Gq8-0000M5-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 12:07:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Gq7-00078Y-OX; Wed, 08 Oct 2003 12:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Gpo-00075d-VY for nemo@optimus.ietf.org; Wed, 08 Oct 2003 12:06:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25140; Wed, 8 Oct 2003 12:06:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Gpn-0000L9-00; Wed, 08 Oct 2003 12:06:43 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1A7Gpm-0000L6-00; Wed, 08 Oct 2003 12:06:42 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h98G6VC7012209; Wed, 8 Oct 2003 09:06:32 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h98G6RSt029803; Wed, 8 Oct 2003 11:06:29 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 3F0DF2ED4E; Wed, 8 Oct 2003 18:06:24 +0200 (CEST) Message-ID: <3F843600.50804@nal.motlabs.com> Date: Wed, 08 Oct 2003 18:06:24 +0200 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: Lawrence MacIntyre Cc: "Pascal Thubert (pthubert)" , Lawrence MacIntyre , Wanrong Yu , nemo@ietf.org, manet@ietf.org Subject: Re: [nemo] Re: [manet] NEMO or MANET? References: <1065621772.1341.167.camel@nautique> In-Reply-To: <1065621772.1341.167.camel@nautique> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Lawrence MacIntyre wrote: > The routing protocol is designed to discover and utilize > connectivity. To communicate with a node, you must have a way to > learn its address, but that is not part of the routing protocol. I agree with that. I agree there is no way for two manet islands completely unknown to each other, each one having its own addressing scheme and deployed addresses, to sort of "join" one another and for their routing tables to get updated accordingly. I mean, assume a manet1 made of two nodes with addresses m11 and m12 respectively, and another manet2 made of other two nodes m21 and m22. When the two manets are separated, communication is ok between m11 and m12, and between m21 and m22. Join them by drawing a link between m11 and m21. After the "join" phase, I don't think there is any manet technique/protocol that would allow m22 and m11 communicate directly. What happens if, by lack of chance, nodes in the two manet islands were initially assigned the same addresses (pairwise: m11 equals m21 and m12 equals m22, but still m11 different than m12 and m21 diff m22)? Communication inside manet1 is ok, and inside manet2 is also ok, but not across. A way of looking at those two networks is to consider that one of them has many available addresses. Distributes some of them to its own nodes by simple DHCP, and keeps a subset of addresses for distribution (by DHCP prefix delegation) to the other network that "visits" it. In this way address conflicts are avoided. The way the NEMO WG group looks at this (if I interpret it correctly) is that the DHCP prefix delegation can happen in this way only if infrastructure is not available (if available then DHCP prefix delegation happens between the home network and the moving network, not between the moving network and the fixed access system). I think this way of supporting two moving networks in two different vehicles that need to "join" (while infrastructure is not available) is viable. And, because the discussion was triggered with a vehicular background in mind, there are many potential scenarios related the way this is deployed, and what's the business need for it. If a manufacturer wants its cars to be able to talk to each other such as to automatically avoid collisions while in a bumper-to-bumper traffic jam, then it would assign unique addresses to all its vehicles, and a same unique manet protocol on all vehicles, then two cars of same model could easily talk to each other w/o infrastructure present. If on the other hand, manufacturer has a need to remotely update software deployed in a car, or garage remotely measures mileage and calls driver for periodic checkup, then this requires communication over the Internet, with the help of fixed infrastructure, so manet protocols are not needed at all (but Mobile IP for moving networks yes). Or again, if a fixed camera measures speed of bypassing vehicles and notifies driver about crossing limits and fines to pay, in a live manner, then again, infrastructure is needed, Mobile IP yes, and manet no. IMHO choosing between manet protocols and Mobile IP-based solution depends largely on the vehicular scenario involved; what's your scenario Wanrong? Alex GBU From nemo-admin@ietf.org Wed Oct 8 13:36:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28754 for ; Wed, 8 Oct 2003 13:36:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IED-0005Bh-Gk; Wed, 08 Oct 2003 13:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Hv2-0003WR-16 for nemo@optimus.ietf.org; Wed, 08 Oct 2003 13:16:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28010; Wed, 8 Oct 2003 13:15:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Huy-0001MS-00; Wed, 08 Oct 2003 13:16:08 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A7Hux-0001Lw-00; Wed, 08 Oct 2003 13:16:08 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h98HFMn13016; Wed, 8 Oct 2003 10:15:22 -0700 X-mProtect: <200310081715> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6iojIM; Wed, 08 Oct 2003 10:15:21 PDT Message-ID: <3F844629.B544F895@iprg.nokia.com> Date: Wed, 08 Oct 2003 10:15:21 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@ietf.org, manet@ietf.org Subject: Re: [nemo] Re: [manet] NEMO or MANET? References: <1065621772.1341.167.camel@nautique> <3F843600.50804@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Alexandru, Alexandru Petrescu wrote: > ... there is no way for two manet islands completely unknown to each > other, each one having its own addressing scheme and deployed addresses, > to sort of "join" one another and for their routing tables to get > updated accordingly. I don't agree with this assessment. The scenario that you paint in a latter paragraph in your note has to do with duplicate address assignment. I agree that when there are duplicate addresses, things are troublesome, and there is the potential for failure. But: 1) Given existing constraints on the size of ad hoc networks, this should be a rare event in IPv4 2) For IPv6, it should be _extremely_ rare 3) In the absence of rare events, things work pretty well 4) There are ways around the problem if one can nominate an address arbitration entity or regime of operation What this means is that when two ad hoc networks join, there is the potential for trouble. But this has to be viewed with a reasonable tolerance for reality: - it's practically impossible to prevent in an absolute sense - there are other dangers, also impossible to prevent, that we don't even consider trying to prevent by protocol (e.g., nuclear strike, election of a spider mite for president of USA, collisions with asteroids, and currently not even malicious node operation). Whatever solution you may try to devise, please keep the following examples in mind: 1. Joining of two networks with 500 nodes each 2. Joining of two networks with 20 nodes each 3. Joining of two networks, one with 500 nodes, one with 20 nodes 4. Joining of two networks, one with 500 nodes, the other with 1 node 5. Joining of two networks, one with 20 nodes, the other with 1 node. 6. Joining of two networks, one with 1 node, the other with 1 node. If your solution requires, for the fourth example, that all 500 nodes start blasting away on some validation broadcast just because one more node joins their network, then I claim your solution is broken. I would also like to avoid mandating the existence of an address arbitration authority in every ad hoc network. That would be overkill. I can make one suggestion that hasn't been discussed very much. Perhaps we should assign a lifetime to all autoconfigured addresses in an ad hoc network. That way, it is less likely that two nodes would have the same address for any extended period of time. Of course, the lifetime requires periodic revalidation, not necessarily relinquishing an address that is currently configured, as long as the revalidation does not fail. Regards, Charlie P. PS. I am not on the [nemo] mailing list, so this may fail to appear there. From exim@www1.ietf.org Wed Oct 8 13:36:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28765 for ; Wed, 8 Oct 2003 13:36:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IEI-0005Cv-D2 for nemo-archive@odin.ietf.org; Wed, 08 Oct 2003 13:36:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Ha6ax020011 for nemo-archive@odin.ietf.org; Wed, 8 Oct 2003 13:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IEI-0005CV-7S for nemo-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 13:36:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28716 for ; Wed, 8 Oct 2003 13:35:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7IEG-0001bz-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 13:36:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7IEF-0001bw-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 13:36:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IED-0005Bh-Gk; Wed, 08 Oct 2003 13:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Hv2-0003WR-16 for nemo@optimus.ietf.org; Wed, 08 Oct 2003 13:16:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28010; Wed, 8 Oct 2003 13:15:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Huy-0001MS-00; Wed, 08 Oct 2003 13:16:08 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A7Hux-0001Lw-00; Wed, 08 Oct 2003 13:16:08 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h98HFMn13016; Wed, 8 Oct 2003 10:15:22 -0700 X-mProtect: <200310081715> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6iojIM; Wed, 08 Oct 2003 10:15:21 PDT Message-ID: <3F844629.B544F895@iprg.nokia.com> Date: Wed, 08 Oct 2003 10:15:21 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@ietf.org, manet@ietf.org Subject: Re: [nemo] Re: [manet] NEMO or MANET? References: <1065621772.1341.167.camel@nautique> <3F843600.50804@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Alexandru, Alexandru Petrescu wrote: > ... there is no way for two manet islands completely unknown to each > other, each one having its own addressing scheme and deployed addresses, > to sort of "join" one another and for their routing tables to get > updated accordingly. I don't agree with this assessment. The scenario that you paint in a latter paragraph in your note has to do with duplicate address assignment. I agree that when there are duplicate addresses, things are troublesome, and there is the potential for failure. But: 1) Given existing constraints on the size of ad hoc networks, this should be a rare event in IPv4 2) For IPv6, it should be _extremely_ rare 3) In the absence of rare events, things work pretty well 4) There are ways around the problem if one can nominate an address arbitration entity or regime of operation What this means is that when two ad hoc networks join, there is the potential for trouble. But this has to be viewed with a reasonable tolerance for reality: - it's practically impossible to prevent in an absolute sense - there are other dangers, also impossible to prevent, that we don't even consider trying to prevent by protocol (e.g., nuclear strike, election of a spider mite for president of USA, collisions with asteroids, and currently not even malicious node operation). Whatever solution you may try to devise, please keep the following examples in mind: 1. Joining of two networks with 500 nodes each 2. Joining of two networks with 20 nodes each 3. Joining of two networks, one with 500 nodes, one with 20 nodes 4. Joining of two networks, one with 500 nodes, the other with 1 node 5. Joining of two networks, one with 20 nodes, the other with 1 node. 6. Joining of two networks, one with 1 node, the other with 1 node. If your solution requires, for the fourth example, that all 500 nodes start blasting away on some validation broadcast just because one more node joins their network, then I claim your solution is broken. I would also like to avoid mandating the existence of an address arbitration authority in every ad hoc network. That would be overkill. I can make one suggestion that hasn't been discussed very much. Perhaps we should assign a lifetime to all autoconfigured addresses in an ad hoc network. That way, it is less likely that two nodes would have the same address for any extended period of time. Of course, the lifetime requires periodic revalidation, not necessarily relinquishing an address that is currently configured, as long as the revalidation does not fail. Regards, Charlie P. PS. I am not on the [nemo] mailing list, so this may fail to appear there. From nemo-admin@ietf.org Wed Oct 8 13:46:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29155 for ; Wed, 8 Oct 2003 13:46:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7INt-0005xV-9r; Wed, 08 Oct 2003 13:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IN8-0005vt-RU for nemo@optimus.ietf.org; Wed, 08 Oct 2003 13:45:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29078 for ; Wed, 8 Oct 2003 13:45:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7IN6-0001ia-00 for nemo@ietf.org; Wed, 08 Oct 2003 13:45:12 -0400 Received: from ebene.inrialpes.fr ([194.199.18.70]) by ietf-mx with esmtp (Exim 4.12) id 1A7IN5-0001i3-00 for nemo@ietf.org; Wed, 08 Oct 2003 13:45:11 -0400 Received: from inrialpes.fr (lalena.inrialpes.fr [194.199.24.114]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id h98HicI28631 for ; Wed, 8 Oct 2003 19:44:38 +0200 (MEST) Message-ID: <3F8451A1.6040901@inrialpes.fr> Date: Wed, 08 Oct 2003 20:04:17 +0200 From: Pars Mutaf User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: nemo@ietf.org References: <1065621772.1341.167.camel@nautique> <3F843600.50804@nal.motlabs.com> <3F844629.B544F895@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] side question on NEMO or MANET? discussion Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, I've a question that is related to the NEMO or MANET? discussion. I didn't want to interfere, hence the different subject.. I think everyone agrees that a mobile node should not switch to infrastructureless mode, if it has access to an infrastructure. How to ensure this in the presence of moving access points? For example, I'm walking on the street and I've an ongoing session using my phone. Then a car with an access point stops in front of me. My phone decides to "take the car", I mean it makes (or tries) an handover to the car's access point. My phone could not differentiate between the infrastructure access point and moving access point. As a consequence it may unnecessarily suffer from service degradation... This is an L2 problem I'm afraid. What do you think? Thank you! pars From exim@www1.ietf.org Wed Oct 8 13:46:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29170 for ; Wed, 8 Oct 2003 13:46:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7INu-0005yT-Tq for nemo-archive@odin.ietf.org; Wed, 08 Oct 2003 13:46:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Hk2kf022959 for nemo-archive@odin.ietf.org; Wed, 8 Oct 2003 13:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7INu-0005yE-Oy for nemo-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 13:46:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29121 for ; Wed, 8 Oct 2003 13:45:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7INs-0001jD-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 13:46:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7INs-0001jA-00 for nemo-web-archive@ietf.org; Wed, 08 Oct 2003 13:46:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7INt-0005xV-9r; Wed, 08 Oct 2003 13:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IN8-0005vt-RU for nemo@optimus.ietf.org; Wed, 08 Oct 2003 13:45:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29078 for ; Wed, 8 Oct 2003 13:45:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7IN6-0001ia-00 for nemo@ietf.org; Wed, 08 Oct 2003 13:45:12 -0400 Received: from ebene.inrialpes.fr ([194.199.18.70]) by ietf-mx with esmtp (Exim 4.12) id 1A7IN5-0001i3-00 for nemo@ietf.org; Wed, 08 Oct 2003 13:45:11 -0400 Received: from inrialpes.fr (lalena.inrialpes.fr [194.199.24.114]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id h98HicI28631 for ; Wed, 8 Oct 2003 19:44:38 +0200 (MEST) Message-ID: <3F8451A1.6040901@inrialpes.fr> Date: Wed, 08 Oct 2003 20:04:17 +0200 From: Pars Mutaf User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: nemo@ietf.org References: <1065621772.1341.167.camel@nautique> <3F843600.50804@nal.motlabs.com> <3F844629.B544F895@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] side question on NEMO or MANET? discussion Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I've a question that is related to the NEMO or MANET? discussion. I didn't want to interfere, hence the different subject.. I think everyone agrees that a mobile node should not switch to infrastructureless mode, if it has access to an infrastructure. How to ensure this in the presence of moving access points? For example, I'm walking on the street and I've an ongoing session using my phone. Then a car with an access point stops in front of me. My phone decides to "take the car", I mean it makes (or tries) an handover to the car's access point. My phone could not differentiate between the infrastructure access point and moving access point. As a consequence it may unnecessarily suffer from service degradation... This is an L2 problem I'm afraid. What do you think? Thank you! pars From nemo-admin@ietf.org Thu Oct 9 13:32:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00578 for ; Thu, 9 Oct 2003 13:32:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7eds-0002D0-TR; Thu, 09 Oct 2003 13:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7e3a-0008Ga-Hf for nemo@optimus.ietf.org; Thu, 09 Oct 2003 12:54:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29046; Thu, 9 Oct 2003 12:54:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7e3Y-0001Ha-00; Thu, 09 Oct 2003 12:54:28 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1A7e3X-0001HT-00; Thu, 09 Oct 2003 12:54:27 -0400 Received: from clarinet.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.6) with ESMTP id h99H49nu031505; Thu, 9 Oct 2003 19:04:10 +0200 Message-ID: <3F8592BA.1010608@clarinet.u-strasbg.fr> Date: Thu, 09 Oct 2003 18:54:18 +0200 From: montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030727 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org, mobile-ip@sunroof.eng.sun.com, nemo@ietf.org, multi6@ops.ietf.org Content-Type: multipart/mixed; boundary="------------030708080606030603080409" Subject: [nemo] New I-D on multi-homing Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------030708080606030603080409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, Just to inform you that we have submitted a new I-D on multihoming. Lot of people have already work on multihoming in individual submissions. We tried to write a problem statement for multihomed MN in this I-D and hope that this I-D will initiate some discussions on this topic. Here is the abstact of the I-D: Individual solutions have been proposed to extend Mobile IPv6 in order to allow mobile nodes to be multihomed, but all issues have not been addressed by a single document. In this document, we thus propose a taxonomy to classify the situations where a mobile node may be multihomed. This taxonomy is then used to describe all multihomed scenarios. Issues preventing mobile nodes to be multihomed while operating Mobile IPv6 are highlighted. This document doesn't aim at proposing solutions, however, it is expected to raise discussion in order to make sure forthcoming solutions will address all the issues. Nicolas --------------030708080606030603080409 Content-Type: text/plain; name="draft-montavont-mobileip-multihoming-pb-statement-00.txt" Content-Disposition: inline; filename="draft-montavont-mobileip-multihoming-pb-statement-00.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by dpt-info.u-strasbg.fr id h99H49nu031505 Content-Transfer-Encoding: quoted-printable IETF Mobile IP Working Group N. Montavont Internet-Draft LSIIT Expires: April 9, 2004 R. Wakikawa T. Ernst WIDE at Keio University T. Noel LSIIT October 10, 2003 Problem Statement for multihomed Mobile Nodes draft-montavont-mobileip-multihoming-pb-statement-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 9, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Individual solutions have been proposed to extend Mobile IPv6 in order to allow mobile nodes to be multihomed, but all issues have not been addressed by a single document. In this document, we thus propose a taxonomy to classify the situations where a mobile node may be multihomed. This taxonomy is then used to describe all multihomed scenarios. Issues preventing mobile nodes to be multihomed while operating Mobile IPv6 are highlighted. This document doesn't aim at Montavont, et al. Expires April 9, 2004 [Page 1] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 proposing solutions, however, it is expected to raise discussion in order to make sure forthcoming solutions will address all the issues. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Multihoming Scenarios . . . . . . . . . . . . . . . . . . . . 6 4.1 Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3 MN connected to home link . . . . . . . . . . . . . . . . . . 8 5. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Montavont, et al. Expires April 9, 2004 [Page 2] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 1. Introduction New mobile nodes often integrate several wireless technologies. The main purpose of this integration is to federate all means of communications in order to have an ubiquitous mobile node which can be used to access to the Internet everywhere and at any time. Permanent Internet connectivity is required by some applications while a mobile node moves across several access networks (i.e. ISPs, hotspots, etc). For example, it is desirable to maintain the Internet connectivity while an automobile running on a freeway receives voice or video streaming data from different access networks. Unfortunately, there is no network interfaces assuring global scale connectivity. Therefore, a mobile node should use various type of network interfaces to obtain wide area network connectivity [11]. In addition, each network interface has different cost, performance, bandwidth, access range, and reliability. Users should thus be able to select the most appropriate set of network interface(s) depending on a visiting network environment, since wireless networks are mutable and less reliable than wired networks. Users should also be able to select the most appropriate interface per communication type. For example, TCP communication is best transmitted over wireless interface, while UDP communication is sent over a wired interface to avoid disturbing TCP connections. Mobile IPv6 [1] is being designed to allow a mobile node to maintain its IPv6 communications while moving between IPv6 subnets. However, the current specification does not give any hints nor requirements to deal with mobile nodes with several points of attachement, i.e. a multihomed mobile node. We propose to evaluate the behavior of standard Mobile IPv6 on a multihomed mobile node, and we will try to identify if modifications or enhancements are required in the specification. This document has two goals. The first goal is to define a taxonomy which helps to represent the different cases of multihoming. Then we describe scenarios where mobile nodes are multihomed. These scenarios show the configuration a mobile node may have (number of interfaces, number of home addresses or number of careof addresses). We also give a concrete illustration for each scenario. The second goal of this document is to define the requirements needed to manage multihomed mobile nodes. Different issues will be raised in order to provide full support of multihomed mobile nodes in MIPv6. The potentially needed solutions to support new features will be described in a separate document. Montavont, et al. Expires April 9, 2004 [Page 3] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 2. Terminology In this section we define the terms needed to analyse mobile node with mulitple points of attachment. Some definition are taken from [1], while other are completed or only defined in this document. Interface (from [7]) A node's attachment to a link Multihomed mobile node A mobile node is said multihomed when it has several IPv6 addresses to choose between. A mobile node has several IPv6 addresses to choose between in the following cases: multi-prefixed: multiple prefixes are advertised on the link(s) the mobile node is connected to. multi-interfaced: multiple interfaces to choose between, on the same link or not. multi-linked: multiple links to choose between (just like multi-interfaced but all interfaces are NOT connected to the same link) multi-sited: when using IPv6 site-local address and attached to different sites Montavont, et al. Expires April 9, 2004 [Page 4] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 3. Benefits Several benefits of multihoming can be envisioned: o Ubiquitous Computing: to provide an extended coverage area. Multiple interfaces bound to distinct technologies can then be used to ensure a permanent connectivity is offered. o Redundancy: to act upon failure of one point of attachment. o Load Balancing: to balance load between multiple point of attachments (simultaneously active or not). o Preference settings: to provide the user or the application the ability to choose the prefered transmission technology or access network for reasons of cost, politics, bandwidth requirement, delay, etc. Montavont, et al. Expires April 9, 2004 [Page 5] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 4. Multihoming Scenarios Different scenarios may lead to the fact that a mobile node may be multihomed. In this section are listed all the configurations where a mobile node may have multiple points of attachment. 4.1 Taxonomy To help to refer to a specific scenario, we define the following scheme: Scenario (x,y,z) where o x =3D number of home addresses (HoAs) o y =3D number of careof addresses (CoAs) o z =3D number of active interfaces The value of each identifier can be 1 if there is only one parameter, or n if there are several. The value n does not specify any number, but indicate that there are more than one parameters. An illustration of this taxonomy is given in Figure 1. Mobile Node HoA1 HoA2 ... HoAn --> Mobile IP layer (x) | | | +-----+--------+ | | | | | | | CoA1 +--CoA2 +---CoA3 ... CoAn --> IP layer (y) | | | | Link1 Link2 Link3 ... Linkn --> IPv6 Link (n/a *) | | | | +-----+----+ | | | | | IF1 IF2 ... IFn --> Physical layer (z) (z =3D the number of active i= nterface) HoA1 ::=3D {CoA1, 2, 3} [IF1 and IF2] HoA2 ::=3D {CoA3} [IF2] Mobile Node(x =3D 2, y =3D 3, z =3D 2) Figure 1. Illustration of the chosen taxonomy Montavont, et al. Expires April 9, 2004 [Page 6] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 * because number of IPv6 link is equal to the number of CoAs, equal to y The variable x indicates the number of HoAs allocated to a MN. A MN may have multiple HoAs (x=3Dn) when either: o The MN has only one home link, and all its HoAs are based on the same IPv6 prefix (e.g. the MN may have multiple interfaces). o The MN has only one home link, and several home addresses with distinct prefixes because there are several IPv6 prefixes advertised on the home link. o The MN has several home links, and thus has at least two HoAs with different IPv6 prefixes. 4.2 scenario 1. One HoA, one CoA, one interface (1,1,1) The MN is not multihomed. The MN has only one interface, with one HoA and is currently away from its home link. 2. Several HoAs, one CoA, one interface (n,1,1) The MN is multihomed, since it has several home addresses. Once the MN is connected to a visited IPv6 subnet, it gets one CoA and remains simulteneously reachable through all its HoAs. 3. Several HoAs, several CoAs, one interface (n,n,1) The MN is multihomed, since it has multiple addresses to choose between. In this case, the MN can be either connected to different IPv6 links at the same time, with the same interface, or it can be attached to a single link where several IPv6 prefixes are advertised. In the latter case, it configures a CoA for each prefix. Then, it may register several of them with distant nodes to benefit from its multihoming properties. 4. Several HoAs, several CoAs, several interfaces (n,n,n) The MN is multihomed. Many scenarios may lead to this case. For example, consider a MN with three interfaces, two of them connected to their home link(two different home addresses) and the last one connected to a visited link where two IPv6 prefixes are advertised. Montavont, et al. Expires April 9, 2004 [Page 7] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 5. One HoA, several CoAs, one interface (1,n,1) The MN is multihomed (several CoAs). The case (1,n,1) occurs when a MN is connected to different IPv6 links with the same interface: either there are several IPv6 prefixes advertised on the link, or the interface allows the MN to be connected to different access point in different IPv6 subnets. 6. One HoA, several CoAs, several interfaces (1,n,n) The MN is multihomed: the MN has several addresses to choose between. For example, assume a MN with several interfaces, each connected to an IPv6 network (the same or not). Then at least one IPv6 address is configured on each interface. The MN has only one home link, and only one home agent. 7. One HoA, one CoA, several interfaces (1,1,n) The MN may be multihomed: if the MN has two interfaces, one connected to its home link (using its home address) and the other connected to a visted link (using a careof address), the MN is multihomed. If the MN is connected to a visited link with one interface and has no IPv6 connectivity with the other interfaces (not in the range of an access point or no IPv6 prefix forwarded on a Layer 2 link), the MN is not multihomed. 4.3 MN connected to home link When a MN is multihomed, some of its interfaces may be connected to its home link(s), at any point of time. In all multihoming scenarii listed in the previous subsection, the MN may be directly connected to a home link. Sometimes, when a MN is connected to a home link, it may have an impact on the multihoming management. For example, in the case (n,n,n), a MN may be connected to its home link(s) with some interface(s). If we consider the case where a MN has three interfaces, three HoAs and two CoAs (connected to two visited IPv6 subnets), the CoAs can not be registered with the home agent serving to MN on the home link it is connected to. This case has to be considered when defining the management of multihoming. Otherwise, the case (n,n,n) can translate into either case (n,1,n) or (n,0,n) according to the way the MN is connected to the Internet. Case (n,1,n) only happens when the MN is connected to a visited link with only one interface and obtain only one CoA. Other interfaces are connected to the home link(s). Montavont, et al. Expires April 9, 2004 [Page 8] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 In the case (n,0,n), i.e. several HoAs, no CoA, and several interfaces, all interfaces of the MN is connected to a home link. If home links have different prefixes, a HoA can be a CoA regarding another HoA. Such considerations must be taken into account in a document which presents a solution for multihomed MN since some MIPv6 features can not be used when the MN is connected to the same link as its home agent (e.g. home registration). So the fact that a multihomed MN is connected to a home link must be considered. Montavont, et al. Expires April 9, 2004 [Page 9] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 5. Open issues In this section we highlight different points which have to be taken into account to handle a multihomed MN using Mobile IPv6. These items constitute the requirements for a Mobile IPv6 node to benefit from its multihomed configuration in an optimized fashion. Some of them do not require more processing than those defined in [1] but management operation, while other requires changes in [1]. Only the needed requirements are given in this document, the solutions to meet these requirements will be defined in a separate document. Issues related to the Mobile IPv6 protocol are the following: 1. How to define a relation between HoAs and CoAs. When a MN has several HoAs and obtain a new CoA, to which HoA the new CoA will be bound to ? Moreover, a HoA may be considered as CoA regarding another home link of the MN. 2. How to identify an entry in the Binding Cache: several CoAs can be simultaneously used by a mobile node when it has multiple points of attachments. These CoAs can be bound to the same HoA on any distant node, such as the home agent whih manages this mobile node for this particular HoA. Therefore both distant node and the mobile node need a way to identify an entry in the Binding Cache. 3. How to manage multiple CoAs bound to a single HoA: a multihomed MN may have multiple Care-of addresses. The MN must be able to register all CoAs with a single HoA on a distant node (Correspondant node or HA). Issues non-related to the Mobile IPv6 protocol are the following: 1. How to allow a mobile node to simultaneously use several interfaces: this will be the global purpose of such a solution to support multiple interfaces on a mobile node. The solution should bring support to allow a MN, or even a fixed multihomed MN to simultaneously use several interfaces, whatever the number of HoAs, of CoAs the mobile node may have and whatever the network configuration the mobile node is connected to. 2. How to manage multiple HoAs: a mobile node may have several HoAs. As the taxonomy suggests, the fact that the mobile node has several HoAs is independant from the fact that the mobile has multiple interfaces. By the way, the fact that the mobile node has multiple interfaces does not imply that it has multiple HoAs and vice-versa. A mechanism should thus be defined to detail how to bind HoAs to a MN. Montavont, et al. Expires April 9, 2004 [Page 10] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 3. How a mobile node may redirect flows from one interface to another, in the different scenarios presented in section 3: this functionality would allow a mobile node to pursue any communication began on an interface while this interface becomes down and another one is available. 4. When a MN has several interfaces, it may want to use each interface differently. According to some policies and preferences, a multihomed MN may want to independantly manage each flow, in order to define which flow would be mapped to which interface and/or which flow can not use a determined interface. In order to optimize the global connectivity of a multihomed MN, a solution may be defined to allow multihomed MN to set filters on flow on distant nodes, such as mechanisms proposed by [10], [5] and [4]. Montavont, et al. Expires April 9, 2004 [Page 11] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 References [1] Perkins, C. and J. Arko, "Mobility Support in IPv6", I-D draft-ietf-mobileip-ipv6-24.txt, June 2003. [2] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to protect Mobile IPv6 signaling between Mobile Nodes and Home Agents", I-D draft-ietf-mobileip-mipv6-ha-ipsec-06.txt, June 2003. [3] Montavont, N., Noel, T. and M. Kassi, "MIPv6 for Multiple Interfaces", I-D draft-montavont-mobileip-mmi-01.txt, October 2003. [4] Koojana, K., Fikouras, N., Koensgen, A. and C. Goerg, "Filters for Mobile IPv6 Bindings (NOMADv6)", I-D draft-nomadv6-mobileip-filters-00.txt, July 2003. [5] Montavont, N. and T. Noel, "Home Agent Filtering For Mobile IPv6", I-D draft-montavont-mobileip-ha-filtering-v6-00.txt, July 2003. [6] Wakikawa, R., Uehara, K., Ernst, T. and K. Nagami, "Multiple careof Address Registration on Mobile IPv6", I-D draft-wakikawa-mobileip-multiplecoa-02.txt, September 2003. [7] Manner, J. and M. Kojo, "Mobility Related Terminology", I-D draft-ietf-seamoby-mobility-terminology-04.txt, April 2003. [8] Fikouras, N., Udugama, A., Koensgen, A., Goerg, C., Zirwas, W. and J. Eichinger, "Filters for Mobile IPv6 Bindings (NOMADv6)", I-D draft-nomad-mobileip-v6-filters-00.txt, July 2003. [9] Ernst, T., "Network Mobility Support Terminology", I-D draft-ietf-nemo-terminology-00.txt, May 2003. [10] Soliman, H., Elmalki, K. and C. Castelluccia, "Flow Movement in Mobile IPv6", I-D draft-soliman-mobileip-flow-move-03.txt, June 2003. [11] Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay Networks", Journal Mobile Networks and Applications, vol. 3, number 4, pages 335-350, 1998. Montavont, et al. Expires April 9, 2004 [Page 12] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 Authors' Addresses Nicolas Montavont LSIIT - Univerity Louis Pasteur Ple API, bureau C444 Boulevard Sebastien Brant Illkirch 67400 FRANCE Phone: (33) 3 90 24 45 87 EMail: montavont@dpt-info.u-strasbg.fr URI: http://www-r2.u-strasbg.fr/~montavont/ Ryuji Wakikawa Jun Murai Lab., Keio University 5322 Endo Fujiwasa Kanagawa 252-8520 Japan Phone: +81-466-49-1394 EMail: ryuji@sfc.wide.ad.jp URI: http://www.mobileip.jp/ Thierry Ernst Jun Murai Lab. Keio University K2 Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki Kanagawa 212-0054 Japan Phone: +81-44-580-1600 EMail: ernst@sfc.wide.ad.jp URI: htpp://www.sfc.wide.ad.jp/~ernst Thomas Noel LSIIT - Univerity Louis Pasteur Ple API, bureau C444 Boulevard S=E9bastien Brant Illkirch 67400 FRANCE Phone: (33) 3 90 24 45 92 EMail: noel@dpt-info.u-strasbg.fr URI: http://www-r2.u-strasbg.fr/~noel/ Montavont, et al. Expires April 9, 2004 [Page 13] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Montavont, et al. Expires April 9, 2004 [Page 14] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Montavont, et al. Expires April 9, 2004 [Page 15] =0C --------------030708080606030603080409-- From exim@www1.ietf.org Thu Oct 9 13:32:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00594 for ; Thu, 9 Oct 2003 13:32:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ee1-0002Ds-Lg for nemo-archive@odin.ietf.org; Thu, 09 Oct 2003 13:32:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99HW9CE008543 for nemo-archive@odin.ietf.org; Thu, 9 Oct 2003 13:32:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ee1-0002Di-Fq for nemo-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 13:32:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00570 for ; Thu, 9 Oct 2003 13:32:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7edz-0001lG-00 for nemo-web-archive@ietf.org; Thu, 09 Oct 2003 13:32:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7edy-0001lC-00 for nemo-web-archive@ietf.org; Thu, 09 Oct 2003 13:32:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7eds-0002D0-TR; Thu, 09 Oct 2003 13:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7e3a-0008Ga-Hf for nemo@optimus.ietf.org; Thu, 09 Oct 2003 12:54:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29046; Thu, 9 Oct 2003 12:54:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7e3Y-0001Ha-00; Thu, 09 Oct 2003 12:54:28 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1A7e3X-0001HT-00; Thu, 09 Oct 2003 12:54:27 -0400 Received: from clarinet.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.6) with ESMTP id h99H49nu031505; Thu, 9 Oct 2003 19:04:10 +0200 Message-ID: <3F8592BA.1010608@clarinet.u-strasbg.fr> Date: Thu, 09 Oct 2003 18:54:18 +0200 From: montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030727 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org, mobile-ip@sunroof.eng.sun.com, nemo@ietf.org, multi6@ops.ietf.org Content-Type: multipart/mixed; boundary="------------030708080606030603080409" Subject: [nemo] New I-D on multi-homing Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------030708080606030603080409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, Just to inform you that we have submitted a new I-D on multihoming. Lot of people have already work on multihoming in individual submissions. We tried to write a problem statement for multihomed MN in this I-D and hope that this I-D will initiate some discussions on this topic. Here is the abstact of the I-D: Individual solutions have been proposed to extend Mobile IPv6 in order to allow mobile nodes to be multihomed, but all issues have not been addressed by a single document. In this document, we thus propose a taxonomy to classify the situations where a mobile node may be multihomed. This taxonomy is then used to describe all multihomed scenarios. Issues preventing mobile nodes to be multihomed while operating Mobile IPv6 are highlighted. This document doesn't aim at proposing solutions, however, it is expected to raise discussion in order to make sure forthcoming solutions will address all the issues. Nicolas --------------030708080606030603080409 Content-Type: text/plain; name="draft-montavont-mobileip-multihoming-pb-statement-00.txt" Content-Disposition: inline; filename="draft-montavont-mobileip-multihoming-pb-statement-00.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by dpt-info.u-strasbg.fr id h99H49nu031505 Content-Transfer-Encoding: quoted-printable IETF Mobile IP Working Group N. Montavont Internet-Draft LSIIT Expires: April 9, 2004 R. Wakikawa T. Ernst WIDE at Keio University T. Noel LSIIT October 10, 2003 Problem Statement for multihomed Mobile Nodes draft-montavont-mobileip-multihoming-pb-statement-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 9, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Individual solutions have been proposed to extend Mobile IPv6 in order to allow mobile nodes to be multihomed, but all issues have not been addressed by a single document. In this document, we thus propose a taxonomy to classify the situations where a mobile node may be multihomed. This taxonomy is then used to describe all multihomed scenarios. Issues preventing mobile nodes to be multihomed while operating Mobile IPv6 are highlighted. This document doesn't aim at Montavont, et al. Expires April 9, 2004 [Page 1] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 proposing solutions, however, it is expected to raise discussion in order to make sure forthcoming solutions will address all the issues. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Multihoming Scenarios . . . . . . . . . . . . . . . . . . . . 6 4.1 Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3 MN connected to home link . . . . . . . . . . . . . . . . . . 8 5. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Montavont, et al. Expires April 9, 2004 [Page 2] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 1. Introduction New mobile nodes often integrate several wireless technologies. The main purpose of this integration is to federate all means of communications in order to have an ubiquitous mobile node which can be used to access to the Internet everywhere and at any time. Permanent Internet connectivity is required by some applications while a mobile node moves across several access networks (i.e. ISPs, hotspots, etc). For example, it is desirable to maintain the Internet connectivity while an automobile running on a freeway receives voice or video streaming data from different access networks. Unfortunately, there is no network interfaces assuring global scale connectivity. Therefore, a mobile node should use various type of network interfaces to obtain wide area network connectivity [11]. In addition, each network interface has different cost, performance, bandwidth, access range, and reliability. Users should thus be able to select the most appropriate set of network interface(s) depending on a visiting network environment, since wireless networks are mutable and less reliable than wired networks. Users should also be able to select the most appropriate interface per communication type. For example, TCP communication is best transmitted over wireless interface, while UDP communication is sent over a wired interface to avoid disturbing TCP connections. Mobile IPv6 [1] is being designed to allow a mobile node to maintain its IPv6 communications while moving between IPv6 subnets. However, the current specification does not give any hints nor requirements to deal with mobile nodes with several points of attachement, i.e. a multihomed mobile node. We propose to evaluate the behavior of standard Mobile IPv6 on a multihomed mobile node, and we will try to identify if modifications or enhancements are required in the specification. This document has two goals. The first goal is to define a taxonomy which helps to represent the different cases of multihoming. Then we describe scenarios where mobile nodes are multihomed. These scenarios show the configuration a mobile node may have (number of interfaces, number of home addresses or number of careof addresses). We also give a concrete illustration for each scenario. The second goal of this document is to define the requirements needed to manage multihomed mobile nodes. Different issues will be raised in order to provide full support of multihomed mobile nodes in MIPv6. The potentially needed solutions to support new features will be described in a separate document. Montavont, et al. Expires April 9, 2004 [Page 3] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 2. Terminology In this section we define the terms needed to analyse mobile node with mulitple points of attachment. Some definition are taken from [1], while other are completed or only defined in this document. Interface (from [7]) A node's attachment to a link Multihomed mobile node A mobile node is said multihomed when it has several IPv6 addresses to choose between. A mobile node has several IPv6 addresses to choose between in the following cases: multi-prefixed: multiple prefixes are advertised on the link(s) the mobile node is connected to. multi-interfaced: multiple interfaces to choose between, on the same link or not. multi-linked: multiple links to choose between (just like multi-interfaced but all interfaces are NOT connected to the same link) multi-sited: when using IPv6 site-local address and attached to different sites Montavont, et al. Expires April 9, 2004 [Page 4] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 3. Benefits Several benefits of multihoming can be envisioned: o Ubiquitous Computing: to provide an extended coverage area. Multiple interfaces bound to distinct technologies can then be used to ensure a permanent connectivity is offered. o Redundancy: to act upon failure of one point of attachment. o Load Balancing: to balance load between multiple point of attachments (simultaneously active or not). o Preference settings: to provide the user or the application the ability to choose the prefered transmission technology or access network for reasons of cost, politics, bandwidth requirement, delay, etc. Montavont, et al. Expires April 9, 2004 [Page 5] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 4. Multihoming Scenarios Different scenarios may lead to the fact that a mobile node may be multihomed. In this section are listed all the configurations where a mobile node may have multiple points of attachment. 4.1 Taxonomy To help to refer to a specific scenario, we define the following scheme: Scenario (x,y,z) where o x =3D number of home addresses (HoAs) o y =3D number of careof addresses (CoAs) o z =3D number of active interfaces The value of each identifier can be 1 if there is only one parameter, or n if there are several. The value n does not specify any number, but indicate that there are more than one parameters. An illustration of this taxonomy is given in Figure 1. Mobile Node HoA1 HoA2 ... HoAn --> Mobile IP layer (x) | | | +-----+--------+ | | | | | | | CoA1 +--CoA2 +---CoA3 ... CoAn --> IP layer (y) | | | | Link1 Link2 Link3 ... Linkn --> IPv6 Link (n/a *) | | | | +-----+----+ | | | | | IF1 IF2 ... IFn --> Physical layer (z) (z =3D the number of active i= nterface) HoA1 ::=3D {CoA1, 2, 3} [IF1 and IF2] HoA2 ::=3D {CoA3} [IF2] Mobile Node(x =3D 2, y =3D 3, z =3D 2) Figure 1. Illustration of the chosen taxonomy Montavont, et al. Expires April 9, 2004 [Page 6] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 * because number of IPv6 link is equal to the number of CoAs, equal to y The variable x indicates the number of HoAs allocated to a MN. A MN may have multiple HoAs (x=3Dn) when either: o The MN has only one home link, and all its HoAs are based on the same IPv6 prefix (e.g. the MN may have multiple interfaces). o The MN has only one home link, and several home addresses with distinct prefixes because there are several IPv6 prefixes advertised on the home link. o The MN has several home links, and thus has at least two HoAs with different IPv6 prefixes. 4.2 scenario 1. One HoA, one CoA, one interface (1,1,1) The MN is not multihomed. The MN has only one interface, with one HoA and is currently away from its home link. 2. Several HoAs, one CoA, one interface (n,1,1) The MN is multihomed, since it has several home addresses. Once the MN is connected to a visited IPv6 subnet, it gets one CoA and remains simulteneously reachable through all its HoAs. 3. Several HoAs, several CoAs, one interface (n,n,1) The MN is multihomed, since it has multiple addresses to choose between. In this case, the MN can be either connected to different IPv6 links at the same time, with the same interface, or it can be attached to a single link where several IPv6 prefixes are advertised. In the latter case, it configures a CoA for each prefix. Then, it may register several of them with distant nodes to benefit from its multihoming properties. 4. Several HoAs, several CoAs, several interfaces (n,n,n) The MN is multihomed. Many scenarios may lead to this case. For example, consider a MN with three interfaces, two of them connected to their home link(two different home addresses) and the last one connected to a visited link where two IPv6 prefixes are advertised. Montavont, et al. Expires April 9, 2004 [Page 7] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 5. One HoA, several CoAs, one interface (1,n,1) The MN is multihomed (several CoAs). The case (1,n,1) occurs when a MN is connected to different IPv6 links with the same interface: either there are several IPv6 prefixes advertised on the link, or the interface allows the MN to be connected to different access point in different IPv6 subnets. 6. One HoA, several CoAs, several interfaces (1,n,n) The MN is multihomed: the MN has several addresses to choose between. For example, assume a MN with several interfaces, each connected to an IPv6 network (the same or not). Then at least one IPv6 address is configured on each interface. The MN has only one home link, and only one home agent. 7. One HoA, one CoA, several interfaces (1,1,n) The MN may be multihomed: if the MN has two interfaces, one connected to its home link (using its home address) and the other connected to a visted link (using a careof address), the MN is multihomed. If the MN is connected to a visited link with one interface and has no IPv6 connectivity with the other interfaces (not in the range of an access point or no IPv6 prefix forwarded on a Layer 2 link), the MN is not multihomed. 4.3 MN connected to home link When a MN is multihomed, some of its interfaces may be connected to its home link(s), at any point of time. In all multihoming scenarii listed in the previous subsection, the MN may be directly connected to a home link. Sometimes, when a MN is connected to a home link, it may have an impact on the multihoming management. For example, in the case (n,n,n), a MN may be connected to its home link(s) with some interface(s). If we consider the case where a MN has three interfaces, three HoAs and two CoAs (connected to two visited IPv6 subnets), the CoAs can not be registered with the home agent serving to MN on the home link it is connected to. This case has to be considered when defining the management of multihoming. Otherwise, the case (n,n,n) can translate into either case (n,1,n) or (n,0,n) according to the way the MN is connected to the Internet. Case (n,1,n) only happens when the MN is connected to a visited link with only one interface and obtain only one CoA. Other interfaces are connected to the home link(s). Montavont, et al. Expires April 9, 2004 [Page 8] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 In the case (n,0,n), i.e. several HoAs, no CoA, and several interfaces, all interfaces of the MN is connected to a home link. If home links have different prefixes, a HoA can be a CoA regarding another HoA. Such considerations must be taken into account in a document which presents a solution for multihomed MN since some MIPv6 features can not be used when the MN is connected to the same link as its home agent (e.g. home registration). So the fact that a multihomed MN is connected to a home link must be considered. Montavont, et al. Expires April 9, 2004 [Page 9] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 5. Open issues In this section we highlight different points which have to be taken into account to handle a multihomed MN using Mobile IPv6. These items constitute the requirements for a Mobile IPv6 node to benefit from its multihomed configuration in an optimized fashion. Some of them do not require more processing than those defined in [1] but management operation, while other requires changes in [1]. Only the needed requirements are given in this document, the solutions to meet these requirements will be defined in a separate document. Issues related to the Mobile IPv6 protocol are the following: 1. How to define a relation between HoAs and CoAs. When a MN has several HoAs and obtain a new CoA, to which HoA the new CoA will be bound to ? Moreover, a HoA may be considered as CoA regarding another home link of the MN. 2. How to identify an entry in the Binding Cache: several CoAs can be simultaneously used by a mobile node when it has multiple points of attachments. These CoAs can be bound to the same HoA on any distant node, such as the home agent whih manages this mobile node for this particular HoA. Therefore both distant node and the mobile node need a way to identify an entry in the Binding Cache. 3. How to manage multiple CoAs bound to a single HoA: a multihomed MN may have multiple Care-of addresses. The MN must be able to register all CoAs with a single HoA on a distant node (Correspondant node or HA). Issues non-related to the Mobile IPv6 protocol are the following: 1. How to allow a mobile node to simultaneously use several interfaces: this will be the global purpose of such a solution to support multiple interfaces on a mobile node. The solution should bring support to allow a MN, or even a fixed multihomed MN to simultaneously use several interfaces, whatever the number of HoAs, of CoAs the mobile node may have and whatever the network configuration the mobile node is connected to. 2. How to manage multiple HoAs: a mobile node may have several HoAs. As the taxonomy suggests, the fact that the mobile node has several HoAs is independant from the fact that the mobile has multiple interfaces. By the way, the fact that the mobile node has multiple interfaces does not imply that it has multiple HoAs and vice-versa. A mechanism should thus be defined to detail how to bind HoAs to a MN. Montavont, et al. Expires April 9, 2004 [Page 10] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 3. How a mobile node may redirect flows from one interface to another, in the different scenarios presented in section 3: this functionality would allow a mobile node to pursue any communication began on an interface while this interface becomes down and another one is available. 4. When a MN has several interfaces, it may want to use each interface differently. According to some policies and preferences, a multihomed MN may want to independantly manage each flow, in order to define which flow would be mapped to which interface and/or which flow can not use a determined interface. In order to optimize the global connectivity of a multihomed MN, a solution may be defined to allow multihomed MN to set filters on flow on distant nodes, such as mechanisms proposed by [10], [5] and [4]. Montavont, et al. Expires April 9, 2004 [Page 11] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 References [1] Perkins, C. and J. Arko, "Mobility Support in IPv6", I-D draft-ietf-mobileip-ipv6-24.txt, June 2003. [2] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to protect Mobile IPv6 signaling between Mobile Nodes and Home Agents", I-D draft-ietf-mobileip-mipv6-ha-ipsec-06.txt, June 2003. [3] Montavont, N., Noel, T. and M. Kassi, "MIPv6 for Multiple Interfaces", I-D draft-montavont-mobileip-mmi-01.txt, October 2003. [4] Koojana, K., Fikouras, N., Koensgen, A. and C. Goerg, "Filters for Mobile IPv6 Bindings (NOMADv6)", I-D draft-nomadv6-mobileip-filters-00.txt, July 2003. [5] Montavont, N. and T. Noel, "Home Agent Filtering For Mobile IPv6", I-D draft-montavont-mobileip-ha-filtering-v6-00.txt, July 2003. [6] Wakikawa, R., Uehara, K., Ernst, T. and K. Nagami, "Multiple careof Address Registration on Mobile IPv6", I-D draft-wakikawa-mobileip-multiplecoa-02.txt, September 2003. [7] Manner, J. and M. Kojo, "Mobility Related Terminology", I-D draft-ietf-seamoby-mobility-terminology-04.txt, April 2003. [8] Fikouras, N., Udugama, A., Koensgen, A., Goerg, C., Zirwas, W. and J. Eichinger, "Filters for Mobile IPv6 Bindings (NOMADv6)", I-D draft-nomad-mobileip-v6-filters-00.txt, July 2003. [9] Ernst, T., "Network Mobility Support Terminology", I-D draft-ietf-nemo-terminology-00.txt, May 2003. [10] Soliman, H., Elmalki, K. and C. Castelluccia, "Flow Movement in Mobile IPv6", I-D draft-soliman-mobileip-flow-move-03.txt, June 2003. [11] Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay Networks", Journal Mobile Networks and Applications, vol. 3, number 4, pages 335-350, 1998. Montavont, et al. Expires April 9, 2004 [Page 12] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 Authors' Addresses Nicolas Montavont LSIIT - Univerity Louis Pasteur Ple API, bureau C444 Boulevard Sebastien Brant Illkirch 67400 FRANCE Phone: (33) 3 90 24 45 87 EMail: montavont@dpt-info.u-strasbg.fr URI: http://www-r2.u-strasbg.fr/~montavont/ Ryuji Wakikawa Jun Murai Lab., Keio University 5322 Endo Fujiwasa Kanagawa 252-8520 Japan Phone: +81-466-49-1394 EMail: ryuji@sfc.wide.ad.jp URI: http://www.mobileip.jp/ Thierry Ernst Jun Murai Lab. Keio University K2 Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki Kanagawa 212-0054 Japan Phone: +81-44-580-1600 EMail: ernst@sfc.wide.ad.jp URI: htpp://www.sfc.wide.ad.jp/~ernst Thomas Noel LSIIT - Univerity Louis Pasteur Ple API, bureau C444 Boulevard S=E9bastien Brant Illkirch 67400 FRANCE Phone: (33) 3 90 24 45 92 EMail: noel@dpt-info.u-strasbg.fr URI: http://www-r2.u-strasbg.fr/~noel/ Montavont, et al. Expires April 9, 2004 [Page 13] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Montavont, et al. Expires April 9, 2004 [Page 14] =0C Internet-Draft Problem statement for multihomed Mobile Nodes Octo= ber 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Montavont, et al. Expires April 9, 2004 [Page 15] =0C --------------030708080606030603080409-- From nemo-admin@ietf.org Thu Oct 9 20:28:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18692 for ; Thu, 9 Oct 2003 20:28:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7l8U-00036j-R4; Thu, 09 Oct 2003 20:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7l7g-00035V-Cu for nemo@optimus.ietf.org; Thu, 09 Oct 2003 20:27:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18667; Thu, 9 Oct 2003 20:27:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7l7d-0006nJ-00; Thu, 09 Oct 2003 20:27:09 -0400 Received: from [129.254.16.14] (helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1A7l7c-0006mN-00; Thu, 09 Oct 2003 20:27:08 -0400 Received: from jafywinxp (pd412h.etri.re.kr [129.254.112.174]) by cms4.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 4B3XLMDF; Fri, 10 Oct 2003 09:24:11 +0900 Reply-To: From: "HyunWook Cha" To: "'Alexandru Petrescu'" Cc: , Subject: RE: [nemo] Re: [manet] NEMO or MANET? Date: Fri, 10 Oct 2003 09:26:41 +0900 Message-ID: <003c01c38ec5$2d0b1b70$ae70fe81@jafywinxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3F843600.50804@nal.motlabs.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Alex, In your previous NEMO post, you mean that an NEMO solution using prefix delegation through DHCP is enough to support this issue or scenario. But, I think this kind of solution is useful under infrastructured condition or very short time session. If one mobile network is visiting other mobile network attached to wired Internet, prefix delegation approach has benefit that it can reduce one level tunneling between a MN in visiting node and its CN. However, let's consider what happens if no access points(routers) are available and three mobile networks(cars) are connected temporarily as following. A<-B<-C ( a <- b means a is parent of b or b visiting a) A delegates a prefix (a:b) to B. B delegates a prefix (b:c) to C. In this case, if a node with prefix a in A want to communicate a node with prefix (b:c) in C, how can it be possible without any routing protocol including MANET? Next, what happens if above topology is changed into following one while a node called 'a' in A is communicating with a node 'b' with prefix a:b in B? A<-C<-B In this case, C delegates prefix c:b for B, but it does not help since network A does not provide HA for delegated prefix (a:b) and moreover, mobile router of A can not know route information for prefix (c:b) without support of routing protocols including MANET. From MANET proint of view, this scenario is only usual one and can be solved in very natural manner. If you points to duplicate address problem, several solutions including "weak DAD" can be helpful. I think that for mobile networks, these schemes can be applicable for resolving duplicate prefix problem. What do you think of this? Regards, HyunWook Cha > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On > Behalf Of Alexandru Petrescu > Sent: Thursday, October 09, 2003 1:06 AM > To: Lawrence MacIntyre > Cc: Pascal Thubert (pthubert); Lawrence MacIntyre; Wanrong > Yu; nemo@ietf.org; manet@ietf.org > Subject: Re: [nemo] Re: [manet] NEMO or MANET? > > > > Lawrence MacIntyre wrote: > > The routing protocol is designed to discover and utilize > > connectivity. To communicate with a node, you must have a way to > > learn its address, but that is not part of the routing protocol. > > I agree with that. > > I agree there is no way for two manet islands completely > unknown to each other, each one having its own addressing > scheme and deployed addresses, to sort of "join" one another > and for their routing tables to get updated accordingly. > > I mean, assume a manet1 made of two nodes with addresses m11 > and m12 respectively, and another manet2 made of other two > nodes m21 and m22. When the two manets are separated, > communication is ok between m11 and m12, and between m21 and > m22. Join them by drawing a link between m11 and m21. After > the "join" phase, I don't think there is any manet > technique/protocol that would allow m22 and m11 communicate directly. > > What happens if, by lack of chance, nodes in the two manet > islands were initially assigned the same addresses (pairwise: > m11 equals m21 and m12 equals m22, but still m11 different > than m12 and m21 diff m22)? Communication inside manet1 is > ok, and inside manet2 is also ok, but not across. > > A way of looking at those two networks is to consider that > one of them has many available addresses. Distributes some > of them to its own nodes by simple DHCP, and keeps a subset > of addresses for distribution (by DHCP prefix delegation) to > the other network that "visits" it. In this way address > conflicts are avoided. The way the NEMO WG group looks at > this (if I interpret it correctly) is that the DHCP prefix > delegation can happen in this way only if infrastructure is > not available (if available then DHCP prefix delegation > happens between the home network and the moving network, not > between the moving network and the fixed access system). > > I think this way of supporting two moving networks in two > different vehicles that need to "join" (while infrastructure > is not available) is viable. > > And, because the discussion was triggered with a vehicular > background in mind, there are many potential scenarios > related the way this is deployed, and what's the business > need for it. If a manufacturer wants its cars to be able to > talk to each other such as to automatically avoid collisions > while in a bumper-to-bumper traffic jam, then it would assign > unique addresses to all its vehicles, and a same unique manet > protocol on all vehicles, then two cars of same model could > easily talk to each other w/o infrastructure present. > > If on the other hand, manufacturer has a need to remotely > update software deployed in a car, or garage remotely > measures mileage and calls driver for periodic checkup, then > this requires communication over the Internet, with the help > of fixed infrastructure, so manet protocols are not needed at > all (but Mobile IP for moving networks yes). > > Or again, if a fixed camera measures speed of bypassing > vehicles and notifies driver about crossing limits and fines > to pay, in a live manner, then again, infrastructure is > needed, Mobile IP yes, and manet no. > > IMHO choosing between manet protocols and Mobile IP-based > solution depends largely on the vehicular scenario involved; > what's your scenario Wanrong? > > Alex > GBU > From exim@www1.ietf.org Thu Oct 9 20:28:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18707 for ; Thu, 9 Oct 2003 20:28:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7l8a-00037d-Gl for nemo-archive@odin.ietf.org; Thu, 09 Oct 2003 20:28:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A0S8rY011998 for nemo-archive@odin.ietf.org; Thu, 9 Oct 2003 20:28:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7l8a-00037R-An for nemo-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 20:28:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18682 for ; Thu, 9 Oct 2003 20:28:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7l8Y-0006nn-00 for nemo-web-archive@ietf.org; Thu, 09 Oct 2003 20:28:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7l8X-0006nk-00 for nemo-web-archive@ietf.org; Thu, 09 Oct 2003 20:28:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7l8U-00036j-R4; Thu, 09 Oct 2003 20:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7l7g-00035V-Cu for nemo@optimus.ietf.org; Thu, 09 Oct 2003 20:27:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18667; Thu, 9 Oct 2003 20:27:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7l7d-0006nJ-00; Thu, 09 Oct 2003 20:27:09 -0400 Received: from [129.254.16.14] (helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1A7l7c-0006mN-00; Thu, 09 Oct 2003 20:27:08 -0400 Received: from jafywinxp (pd412h.etri.re.kr [129.254.112.174]) by cms4.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 4B3XLMDF; Fri, 10 Oct 2003 09:24:11 +0900 Reply-To: From: "HyunWook Cha" To: "'Alexandru Petrescu'" Cc: , Subject: RE: [nemo] Re: [manet] NEMO or MANET? Date: Fri, 10 Oct 2003 09:26:41 +0900 Message-ID: <003c01c38ec5$2d0b1b70$ae70fe81@jafywinxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3F843600.50804@nal.motlabs.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Alex, In your previous NEMO post, you mean that an NEMO solution using prefix delegation through DHCP is enough to support this issue or scenario. But, I think this kind of solution is useful under infrastructured condition or very short time session. If one mobile network is visiting other mobile network attached to wired Internet, prefix delegation approach has benefit that it can reduce one level tunneling between a MN in visiting node and its CN. However, let's consider what happens if no access points(routers) are available and three mobile networks(cars) are connected temporarily as following. A<-B<-C ( a <- b means a is parent of b or b visiting a) A delegates a prefix (a:b) to B. B delegates a prefix (b:c) to C. In this case, if a node with prefix a in A want to communicate a node with prefix (b:c) in C, how can it be possible without any routing protocol including MANET? Next, what happens if above topology is changed into following one while a node called 'a' in A is communicating with a node 'b' with prefix a:b in B? A<-C<-B In this case, C delegates prefix c:b for B, but it does not help since network A does not provide HA for delegated prefix (a:b) and moreover, mobile router of A can not know route information for prefix (c:b) without support of routing protocols including MANET. From MANET proint of view, this scenario is only usual one and can be solved in very natural manner. If you points to duplicate address problem, several solutions including "weak DAD" can be helpful. I think that for mobile networks, these schemes can be applicable for resolving duplicate prefix problem. What do you think of this? Regards, HyunWook Cha > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On > Behalf Of Alexandru Petrescu > Sent: Thursday, October 09, 2003 1:06 AM > To: Lawrence MacIntyre > Cc: Pascal Thubert (pthubert); Lawrence MacIntyre; Wanrong > Yu; nemo@ietf.org; manet@ietf.org > Subject: Re: [nemo] Re: [manet] NEMO or MANET? > > > > Lawrence MacIntyre wrote: > > The routing protocol is designed to discover and utilize > > connectivity. To communicate with a node, you must have a way to > > learn its address, but that is not part of the routing protocol. > > I agree with that. > > I agree there is no way for two manet islands completely > unknown to each other, each one having its own addressing > scheme and deployed addresses, to sort of "join" one another > and for their routing tables to get updated accordingly. > > I mean, assume a manet1 made of two nodes with addresses m11 > and m12 respectively, and another manet2 made of other two > nodes m21 and m22. When the two manets are separated, > communication is ok between m11 and m12, and between m21 and > m22. Join them by drawing a link between m11 and m21. After > the "join" phase, I don't think there is any manet > technique/protocol that would allow m22 and m11 communicate directly. > > What happens if, by lack of chance, nodes in the two manet > islands were initially assigned the same addresses (pairwise: > m11 equals m21 and m12 equals m22, but still m11 different > than m12 and m21 diff m22)? Communication inside manet1 is > ok, and inside manet2 is also ok, but not across. > > A way of looking at those two networks is to consider that > one of them has many available addresses. Distributes some > of them to its own nodes by simple DHCP, and keeps a subset > of addresses for distribution (by DHCP prefix delegation) to > the other network that "visits" it. In this way address > conflicts are avoided. The way the NEMO WG group looks at > this (if I interpret it correctly) is that the DHCP prefix > delegation can happen in this way only if infrastructure is > not available (if available then DHCP prefix delegation > happens between the home network and the moving network, not > between the moving network and the fixed access system). > > I think this way of supporting two moving networks in two > different vehicles that need to "join" (while infrastructure > is not available) is viable. > > And, because the discussion was triggered with a vehicular > background in mind, there are many potential scenarios > related the way this is deployed, and what's the business > need for it. If a manufacturer wants its cars to be able to > talk to each other such as to automatically avoid collisions > while in a bumper-to-bumper traffic jam, then it would assign > unique addresses to all its vehicles, and a same unique manet > protocol on all vehicles, then two cars of same model could > easily talk to each other w/o infrastructure present. > > If on the other hand, manufacturer has a need to remotely > update software deployed in a car, or garage remotely > measures mileage and calls driver for periodic checkup, then > this requires communication over the Internet, with the help > of fixed infrastructure, so manet protocols are not needed at > all (but Mobile IP for moving networks yes). > > Or again, if a fixed camera measures speed of bypassing > vehicles and notifies driver about crossing limits and fines > to pay, in a live manner, then again, infrastructure is > needed, Mobile IP yes, and manet no. > > IMHO choosing between manet protocols and Mobile IP-based > solution depends largely on the vehicular scenario involved; > what's your scenario Wanrong? > > Alex > GBU > From nemo-admin@ietf.org Fri Oct 10 08:50:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25734 for ; Fri, 10 Oct 2003 08:50:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wiX-0000cv-Um; Fri, 10 Oct 2003 08:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7w7G-0006C9-3q for nemo@optimus.ietf.org; Fri, 10 Oct 2003 08:11:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23215 for ; Fri, 10 Oct 2003 08:11:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7w7F-0001yJ-00 for nemo@ietf.org; Fri, 10 Oct 2003 08:11:29 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1A7w7E-0001x8-00 for nemo@ietf.org; Fri, 10 Oct 2003 08:11:28 -0400 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 18C4B689C6 for ; Fri, 10 Oct 2003 08:10:57 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.9) with ESMTP id h9ACAuGZ019492; Fri, 10 Oct 2003 08:10:56 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.9) with ESMTP id h9ACAqHr027722; Fri, 10 Oct 2003 08:10:55 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031010080359.021ffcc0@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 10 Oct 2003 08:10:36 -0400 To: Pars Mutaf From: William D Ivancic Subject: Re: [nemo] side question on NEMO or MANET? discussion Cc: nemo@ietf.org In-Reply-To: <3F8451A1.6040901@inrialpes.fr> References: <1065621772.1341.167.camel@nautique> <3F843600.50804@nal.motlabs.com> <3F844629.B544F895@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , pars, I have systems that do this every day. My systems are currently deployed with Cisco's mobile network IOS for IPv4. This is the solution the Cisco has developed that works pretty well in the scenarios I have been able to test in. I the Cisco IOS there is a concept of preferred path. The idea is that the engineer understands (to the extent possible) what the best RF connections are likely to be and prioritizes those connections (multi-homed mobile router). For instance, if I have and 802.11 link a 1xRTT CDMA link and a satellite link, I would likely set the priorities in that order due to cost, bandwidth, etc... . The may be better ways, but this is one that has worked in practice. Will At 08:04 PM 10/8/2003 +0200, Pars Mutaf wrote: >... >I'm walking on the street and >I've an ongoing session using my phone. Then >a car with an access point stops in front >of me. My phone decides to "take the car", I >mean it makes (or tries) an handover to the >car's access point. My phone could not >differentiate between the infrastructure access >point and moving access point. As a consequence >it may unnecessarily suffer from service >degradation... >This is an L2 problem I'm afraid. > >What do you think? > >Thank you! >pars > ======================================= Will Ivancic NASA Glenn Research Center 21000 Brookpark Road MS 54-5 Cleveland, Ohio 44135 Phone +1 (216)433-3494 Fax +1 (216) 433-8705 Yahoo Instant Messenger ID: ivancic http://roland.grc.nasa.gov/~ivancic From exim@www1.ietf.org Fri Oct 10 08:50:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25755 for ; Fri, 10 Oct 2003 08:50:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wih-0000eG-OP for nemo-archive@odin.ietf.org; Fri, 10 Oct 2003 08:50:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ACoBqx002488 for nemo-archive@odin.ietf.org; Fri, 10 Oct 2003 08:50:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wih-0000e3-KH for nemo-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 08:50:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25694 for ; Fri, 10 Oct 2003 08:50:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7wig-0002ta-00 for nemo-web-archive@ietf.org; Fri, 10 Oct 2003 08:50:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7wif-0002tX-00 for nemo-web-archive@ietf.org; Fri, 10 Oct 2003 08:50:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wiX-0000cv-Um; Fri, 10 Oct 2003 08:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7w7G-0006C9-3q for nemo@optimus.ietf.org; Fri, 10 Oct 2003 08:11:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23215 for ; Fri, 10 Oct 2003 08:11:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7w7F-0001yJ-00 for nemo@ietf.org; Fri, 10 Oct 2003 08:11:29 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1A7w7E-0001x8-00 for nemo@ietf.org; Fri, 10 Oct 2003 08:11:28 -0400 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 18C4B689C6 for ; Fri, 10 Oct 2003 08:10:57 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.9) with ESMTP id h9ACAuGZ019492; Fri, 10 Oct 2003 08:10:56 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.9) with ESMTP id h9ACAqHr027722; Fri, 10 Oct 2003 08:10:55 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031010080359.021ffcc0@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 10 Oct 2003 08:10:36 -0400 To: Pars Mutaf From: William D Ivancic Subject: Re: [nemo] side question on NEMO or MANET? discussion Cc: nemo@ietf.org In-Reply-To: <3F8451A1.6040901@inrialpes.fr> References: <1065621772.1341.167.camel@nautique> <3F843600.50804@nal.motlabs.com> <3F844629.B544F895@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , pars, I have systems that do this every day. My systems are currently deployed with Cisco's mobile network IOS for IPv4. This is the solution the Cisco has developed that works pretty well in the scenarios I have been able to test in. I the Cisco IOS there is a concept of preferred path. The idea is that the engineer understands (to the extent possible) what the best RF connections are likely to be and prioritizes those connections (multi-homed mobile router). For instance, if I have and 802.11 link a 1xRTT CDMA link and a satellite link, I would likely set the priorities in that order due to cost, bandwidth, etc... . The may be better ways, but this is one that has worked in practice. Will At 08:04 PM 10/8/2003 +0200, Pars Mutaf wrote: >... >I'm walking on the street and >I've an ongoing session using my phone. Then >a car with an access point stops in front >of me. My phone decides to "take the car", I >mean it makes (or tries) an handover to the >car's access point. My phone could not >differentiate between the infrastructure access >point and moving access point. As a consequence >it may unnecessarily suffer from service >degradation... >This is an L2 problem I'm afraid. > >What do you think? > >Thank you! >pars > ======================================= Will Ivancic NASA Glenn Research Center 21000 Brookpark Road MS 54-5 Cleveland, Ohio 44135 Phone +1 (216)433-3494 Fax +1 (216) 433-8705 Yahoo Instant Messenger ID: ivancic http://roland.grc.nasa.gov/~ivancic From nemo-admin@ietf.org Mon Oct 13 06:42:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29668 for ; Mon, 13 Oct 2003 06:42:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A909K-0002Yn-J4; Mon, 13 Oct 2003 06:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9090-0002Y6-6M for nemo@optimus.ietf.org; Mon, 13 Oct 2003 06:41:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29641; Mon, 13 Oct 2003 06:41:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A908v-0001Kk-00; Mon, 13 Oct 2003 06:41:37 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1A908v-0001Kh-00; Mon, 13 Oct 2003 06:41:37 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h9DAfWNK007160; Mon, 13 Oct 2003 03:41:33 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h9DAfR1k013016; Mon, 13 Oct 2003 05:41:29 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id DE0B72EC95; Mon, 13 Oct 2003 12:41:27 +0200 (CEST) Message-ID: <3F8A8156.4090409@nal.motlabs.com> Date: Mon, 13 Oct 2003 12:41:26 +0200 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: jafy@etri.re.kr Cc: nemo@ietf.org, manet@ietf.org References: <003c01c38ec5$2d0b1b70$ae70fe81@jafywinxp> In-Reply-To: <003c01c38ec5$2d0b1b70$ae70fe81@jafywinxp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: NEMO or MANET? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit HyunWook Cha wrote: > ...NEMO solution using prefix delegation through DHCP is enough to > support this issue or scenario. But, I think this kind of solution is > useful under infrastructured condition or very short time session. Yes, if infrastructure is available and only short time communication is needed, using DHCP prefix delegation to nodes in the mobile network can help. But of course providing reachability at a permanent home address is not feasible if _only_ prefix delegation is used. > If one mobile network is visiting other mobile network attached to > wired Internet, prefix delegation approach has benefit that it can > reduce one level tunneling between a MN in visiting node and its CN. Richtig. > However, let's consider what happens if no access points(routers) are > available and three mobile networks(cars) are connected temporarily > as following. A<-B<-C ( a <- b means a is parent of b or b visiting > a) A delegates a prefix (a:b) to B. B delegates a prefix (b:c) to C. > In this case, if a node with prefix a in A want to communicate a node > with prefix (b:c) in C, how can it be possible without any routing > protocol including MANET? A delegates a prefix to B implies that both A and B add entries in their respective routing tables in order to make forwarding work. Similar when B delegates to C. In this way routes are added where needed, and without a routing protocol involved. Moreover, DHCP also distributes defaults routes to be installed in routing tables. > Next, what happens if above topology is changed into following one > while a node called 'a' in A is communicating with a node 'b' with > prefix a:b in B? A<-C<-B Ok. If the topology changes from A-B-C to A-C-B then indeed this is no longer as static as might have been wished for by NEMO. This is definitely something to be dealt with by manet protocols. Do you have an analytical (if practical even better) example of behaviour of a manet routing protocol when topology changes from A-B-C to A-C-B? > If you points to duplicate address problem, several solutions > including "weak DAD" can be helpful. I think that for mobile > networks, these schemes can be applicable for resolving duplicate > prefix problem. I was not pointing to a duplicate address assignment problem, mainly because that equates to other cataclysms that might happen. I was pointing to the fact that using manet exclusively does not provide universal reachability at a permanent home address when the nodes move anywhere at the edges of the Internet. Alex GBU From exim@www1.ietf.org Mon Oct 13 06:42:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29683 for ; Mon, 13 Oct 2003 06:42:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A909Q-0002Zk-PF for nemo-archive@odin.ietf.org; Mon, 13 Oct 2003 06:42:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DAg85f009896 for nemo-archive@odin.ietf.org; Mon, 13 Oct 2003 06:42:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A909Q-0002ZX-L7 for nemo-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 06:42:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29651 for ; Mon, 13 Oct 2003 06:41:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A909M-0001Kw-00 for nemo-web-archive@ietf.org; Mon, 13 Oct 2003 06:42:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A909M-0001Ks-00 for nemo-web-archive@ietf.org; Mon, 13 Oct 2003 06:42:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A909K-0002Yn-J4; Mon, 13 Oct 2003 06:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9090-0002Y6-6M for nemo@optimus.ietf.org; Mon, 13 Oct 2003 06:41:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29641; Mon, 13 Oct 2003 06:41:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A908v-0001Kk-00; Mon, 13 Oct 2003 06:41:37 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1A908v-0001Kh-00; Mon, 13 Oct 2003 06:41:37 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h9DAfWNK007160; Mon, 13 Oct 2003 03:41:33 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h9DAfR1k013016; Mon, 13 Oct 2003 05:41:29 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id DE0B72EC95; Mon, 13 Oct 2003 12:41:27 +0200 (CEST) Message-ID: <3F8A8156.4090409@nal.motlabs.com> Date: Mon, 13 Oct 2003 12:41:26 +0200 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: jafy@etri.re.kr Cc: nemo@ietf.org, manet@ietf.org References: <003c01c38ec5$2d0b1b70$ae70fe81@jafywinxp> In-Reply-To: <003c01c38ec5$2d0b1b70$ae70fe81@jafywinxp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: NEMO or MANET? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit HyunWook Cha wrote: > ...NEMO solution using prefix delegation through DHCP is enough to > support this issue or scenario. But, I think this kind of solution is > useful under infrastructured condition or very short time session. Yes, if infrastructure is available and only short time communication is needed, using DHCP prefix delegation to nodes in the mobile network can help. But of course providing reachability at a permanent home address is not feasible if _only_ prefix delegation is used. > If one mobile network is visiting other mobile network attached to > wired Internet, prefix delegation approach has benefit that it can > reduce one level tunneling between a MN in visiting node and its CN. Richtig. > However, let's consider what happens if no access points(routers) are > available and three mobile networks(cars) are connected temporarily > as following. A<-B<-C ( a <- b means a is parent of b or b visiting > a) A delegates a prefix (a:b) to B. B delegates a prefix (b:c) to C. > In this case, if a node with prefix a in A want to communicate a node > with prefix (b:c) in C, how can it be possible without any routing > protocol including MANET? A delegates a prefix to B implies that both A and B add entries in their respective routing tables in order to make forwarding work. Similar when B delegates to C. In this way routes are added where needed, and without a routing protocol involved. Moreover, DHCP also distributes defaults routes to be installed in routing tables. > Next, what happens if above topology is changed into following one > while a node called 'a' in A is communicating with a node 'b' with > prefix a:b in B? A<-C<-B Ok. If the topology changes from A-B-C to A-C-B then indeed this is no longer as static as might have been wished for by NEMO. This is definitely something to be dealt with by manet protocols. Do you have an analytical (if practical even better) example of behaviour of a manet routing protocol when topology changes from A-B-C to A-C-B? > If you points to duplicate address problem, several solutions > including "weak DAD" can be helpful. I think that for mobile > networks, these schemes can be applicable for resolving duplicate > prefix problem. I was not pointing to a duplicate address assignment problem, mainly because that equates to other cataclysms that might happen. I was pointing to the fact that using manet exclusively does not provide universal reachability at a permanent home address when the nodes move anywhere at the edges of the Internet. Alex GBU From nemo-admin@ietf.org Mon Oct 13 10:11:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06470 for ; Mon, 13 Oct 2003 10:11:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A93Pa-0003mq-Er; Mon, 13 Oct 2003 10:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A93Ol-0003lE-VQ for nemo@optimus.ietf.org; Mon, 13 Oct 2003 10:10:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06321; Mon, 13 Oct 2003 10:10:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A93Oi-00033A-00; Mon, 13 Oct 2003 10:10:08 -0400 Received: from [211.91.220.4] (helo=ds20.nudt.edu.cn) by ietf-mx with esmtp (Exim 4.12) id 1A93Oh-00032u-00; Mon, 13 Oct 2003 10:10:08 -0400 Received: by ds20.nudt.edu.cn (Postfix, from userid 506) id A2F735B904; Mon, 13 Oct 2003 22:16:28 +0800 (HKT) From: Wanrong Yu To: Alexandru Petrescu Reply-To: Wanrong Yu Cc: nemo@ietf.org, manet@ietf.org References: <003c01c38ec5$2d0b1b70$ae70fe81@jafywinxp> <3F8A8156.4090409@nal.motlabs.com> In-Reply-To: <3F8A8156.4090409@nal.motlabs.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: YH WebMail Program Version 1.5 X-Originating-IP: 172.26.20.16 Message-Id: <20031013141628.A2F735B904@ds20.nudt.edu.cn> Date: Mon, 13 Oct 2003 22:16:28 +0800 (HKT) Content-Transfer-Encoding: 8bit Subject: [nemo] =?gb2312?B?UmU6IFtuZW1vXSBSZTogTkVNTyBvciBNQU5FVD8=?= Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi,Alex Sorry for reply so later;-) >> From the aspect of NEMO, we can loose the restrict of the existence >> of fixed infrastructure, >Ok, for the purpose of obtaining what? >IMHO choosing between manet protocols and Mobile IP- based solution >depends largely on the vehicular scenario involved; what's your scenario >Wanrong? I mean this is a possible scenario and we should be able to deal with the unavailable of fixed infrastructure no matter what's the reason for its unavailable. I am a postgraduate student and just "think out" this problem when reading NEMO and MANET drafts. I just want to know weather this is a deserved research topic. I will do more work on this and will submit any results to the two WGs. > Ok. If the topology changes from A-B-C to A-C-B then indeed this is no > longer as static as might have been wished for by NEMO. This is > definitely something to be dealt with by manet protocols. Agree! This is what I mean, current NEMO WG may not focus on this and current MANET protocol "may" be not enough to fit this condition. Wanrong Yu From exim@www1.ietf.org Mon Oct 13 10:11:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06500 for ; Mon, 13 Oct 2003 10:11:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A93Pe-0003ns-T2 for nemo-archive@odin.ietf.org; Mon, 13 Oct 2003 10:11:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DEB6sc014616 for nemo-archive@odin.ietf.org; Mon, 13 Oct 2003 10:11:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A93Pe-0003nf-Nd for nemo-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 10:11:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06403 for ; Mon, 13 Oct 2003 10:10:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A93Pc-00033t-00 for nemo-web-archive@ietf.org; Mon, 13 Oct 2003 10:11:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A93Pc-00033q-00 for nemo-web-archive@ietf.org; Mon, 13 Oct 2003 10:11:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A93Pa-0003mq-Er; Mon, 13 Oct 2003 10:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A93Ol-0003lE-VQ for nemo@optimus.ietf.org; Mon, 13 Oct 2003 10:10:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06321; Mon, 13 Oct 2003 10:10:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A93Oi-00033A-00; Mon, 13 Oct 2003 10:10:08 -0400 Received: from [211.91.220.4] (helo=ds20.nudt.edu.cn) by ietf-mx with esmtp (Exim 4.12) id 1A93Oh-00032u-00; Mon, 13 Oct 2003 10:10:08 -0400 Received: by ds20.nudt.edu.cn (Postfix, from userid 506) id A2F735B904; Mon, 13 Oct 2003 22:16:28 +0800 (HKT) From: Wanrong Yu To: Alexandru Petrescu Reply-To: Wanrong Yu Cc: nemo@ietf.org, manet@ietf.org References: <003c01c38ec5$2d0b1b70$ae70fe81@jafywinxp> <3F8A8156.4090409@nal.motlabs.com> In-Reply-To: <3F8A8156.4090409@nal.motlabs.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: YH WebMail Program Version 1.5 X-Originating-IP: 172.26.20.16 Message-Id: <20031013141628.A2F735B904@ds20.nudt.edu.cn> Date: Mon, 13 Oct 2003 22:16:28 +0800 (HKT) Content-Transfer-Encoding: 8bit Subject: [nemo] =?gb2312?B?UmU6IFtuZW1vXSBSZTogTkVNTyBvciBNQU5FVD8=?= Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi,Alex Sorry for reply so later;-) >> From the aspect of NEMO, we can loose the restrict of the existence >> of fixed infrastructure, >Ok, for the purpose of obtaining what? >IMHO choosing between manet protocols and Mobile IP- based solution >depends largely on the vehicular scenario involved; what's your scenario >Wanrong? I mean this is a possible scenario and we should be able to deal with the unavailable of fixed infrastructure no matter what's the reason for its unavailable. I am a postgraduate student and just "think out" this problem when reading NEMO and MANET drafts. I just want to know weather this is a deserved research topic. I will do more work on this and will submit any results to the two WGs. > Ok. If the topology changes from A-B-C to A-C-B then indeed this is no > longer as static as might have been wished for by NEMO. This is > definitely something to be dealt with by manet protocols. Agree! This is what I mean, current NEMO WG may not focus on this and current MANET protocol "may" be not enough to fit this condition. Wanrong Yu From nemo-admin@ietf.org Mon Oct 13 12:18:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13630 for ; Mon, 13 Oct 2003 12:18:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95OT-0002G2-PP; Mon, 13 Oct 2003 12:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95OJ-0002FS-Rh for nemo@optimus.ietf.org; Mon, 13 Oct 2003 12:17:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13587 for ; Mon, 13 Oct 2003 12:17:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A95OI-0004xr-00 for nemo@ietf.org; Mon, 13 Oct 2003 12:17:50 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1A95OH-0004xo-00 for nemo@ietf.org; Mon, 13 Oct 2003 12:17:49 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h9DGHjHR007488; Mon, 13 Oct 2003 09:17:46 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h9DGHQhA015920; Mon, 13 Oct 2003 11:17:27 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 500EA2EC95; Mon, 13 Oct 2003 18:17:40 +0200 (CEST) Message-ID: <3F8AD024.50101@nal.motlabs.com> Date: Mon, 13 Oct 2003 18:17:40 +0200 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: Wanrong Yu Cc: nemo@ietf.org Subject: Re: [nemo] Re: [nemo] Re: NEMO or MANET? References: <003c01c38ec5$2d0b1b70$ae70fe81@jafywinxp> <3F8A8156.4090409@nal.motlabs.com> <20031013141628.A2F735B904@ds20.nudt.edu.cn> In-Reply-To: <20031013141628.A2F735B904@ds20.nudt.edu.cn> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Wanrong Yu wrote: > I am a postgraduate student and just "think out" this problem when > reading NEMO and MANET drafts. I just want to know weather this is a > deserved research topic. I think that transforming A-B-C into A-C-B such as nodes to be reachable with IP does not qualify for a research topic per se. An interesting research problem is posed within the ANS Research Group where the scalability of such networks is studied and where a more generic problem is being defined. I think it is good to come with problems raised by practical experiments that directly relate to real scenarios. For example, in NEMO WG they came up with the problem of connecting a set of devices (in a vehicle) to the Internet by their mobile router, to different access systems, such as they're reachable at their home address and do not have mobility implementations themselves (MR has) and their apps are uninterrupted. Lack of Mobile IP support for this was noticed in practice and an obvious scenario (many laptops in a train) was looking like a good market opportunity, especially knowing that many market players exist in this space. Should be also acknolwedged that the many-laptops-in-a-train scenario does not need to use Mobile IP on MR as long as MR connects to only one access link (like sattelite). Should also be acknowledged that connecting a vehicle to the Internet as such is an old topic, maybe as old as the Internet itself. So, going back to A-B-C A-C-B there should be a need for this somewhere by some vehicles. Otherwise it looks too much like an analytical problem that might never appear in practice; or, if it is provoked in lab experiments, it might never relate to real cases appearing when considering specific usage. > I will do more work on this and will submit any results to the two > WGs. Looking forward to see it. Alex GBU From exim@www1.ietf.org Mon Oct 13 12:18:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13646 for ; Mon, 13 Oct 2003 12:18:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95OZ-0002Iu-SR for nemo-archive@odin.ietf.org; Mon, 13 Oct 2003 12:18:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DGI78s008818 for nemo-archive@odin.ietf.org; Mon, 13 Oct 2003 12:18:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95OZ-0002Gy-In for nemo-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 12:18:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13605 for ; Mon, 13 Oct 2003 12:17:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A95OX-0004yS-00 for nemo-web-archive@ietf.org; Mon, 13 Oct 2003 12:18:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A95OX-0004yP-00 for nemo-web-archive@ietf.org; Mon, 13 Oct 2003 12:18:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95OT-0002G2-PP; Mon, 13 Oct 2003 12:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A95OJ-0002FS-Rh for nemo@optimus.ietf.org; Mon, 13 Oct 2003 12:17:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13587 for ; Mon, 13 Oct 2003 12:17:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A95OI-0004xr-00 for nemo@ietf.org; Mon, 13 Oct 2003 12:17:50 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1A95OH-0004xo-00 for nemo@ietf.org; Mon, 13 Oct 2003 12:17:49 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h9DGHjHR007488; Mon, 13 Oct 2003 09:17:46 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h9DGHQhA015920; Mon, 13 Oct 2003 11:17:27 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 500EA2EC95; Mon, 13 Oct 2003 18:17:40 +0200 (CEST) Message-ID: <3F8AD024.50101@nal.motlabs.com> Date: Mon, 13 Oct 2003 18:17:40 +0200 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: Wanrong Yu Cc: nemo@ietf.org Subject: Re: [nemo] Re: [nemo] Re: NEMO or MANET? References: <003c01c38ec5$2d0b1b70$ae70fe81@jafywinxp> <3F8A8156.4090409@nal.motlabs.com> <20031013141628.A2F735B904@ds20.nudt.edu.cn> In-Reply-To: <20031013141628.A2F735B904@ds20.nudt.edu.cn> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Wanrong Yu wrote: > I am a postgraduate student and just "think out" this problem when > reading NEMO and MANET drafts. I just want to know weather this is a > deserved research topic. I think that transforming A-B-C into A-C-B such as nodes to be reachable with IP does not qualify for a research topic per se. An interesting research problem is posed within the ANS Research Group where the scalability of such networks is studied and where a more generic problem is being defined. I think it is good to come with problems raised by practical experiments that directly relate to real scenarios. For example, in NEMO WG they came up with the problem of connecting a set of devices (in a vehicle) to the Internet by their mobile router, to different access systems, such as they're reachable at their home address and do not have mobility implementations themselves (MR has) and their apps are uninterrupted. Lack of Mobile IP support for this was noticed in practice and an obvious scenario (many laptops in a train) was looking like a good market opportunity, especially knowing that many market players exist in this space. Should be also acknolwedged that the many-laptops-in-a-train scenario does not need to use Mobile IP on MR as long as MR connects to only one access link (like sattelite). Should also be acknowledged that connecting a vehicle to the Internet as such is an old topic, maybe as old as the Internet itself. So, going back to A-B-C A-C-B there should be a need for this somewhere by some vehicles. Otherwise it looks too much like an analytical problem that might never appear in practice; or, if it is provoked in lab experiments, it might never relate to real cases appearing when considering specific usage. > I will do more work on this and will submit any results to the two > WGs. Looking forward to see it. Alex GBU From nemo-admin@ietf.org Mon Oct 13 20:57:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07726 for ; Mon, 13 Oct 2003 20:57:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9DUk-0002LJ-GN; Mon, 13 Oct 2003 20:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9DUO-0002Ke-Rj for nemo@optimus.ietf.org; Mon, 13 Oct 2003 20:56:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07707; Mon, 13 Oct 2003 20:56:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9DUL-0003t6-00; Mon, 13 Oct 2003 20:56:37 -0400 Received: from [129.254.16.14] (helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1A9DUK-0003sy-00; Mon, 13 Oct 2003 20:56:37 -0400 Received: from jafywinxp (pd412h.etri.re.kr [129.254.112.174]) by cms4.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 4Z7CZYX6; Tue, 14 Oct 2003 09:53:27 +0900 Reply-To: From: "HyunWook Cha" To: "'Alexandru Petrescu'" Cc: , Date: Tue, 14 Oct 2003 09:56:06 +0900 Message-ID: <000001c391ed$f311c2d0$ae70fe81@jafywinxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <3F8A8156.4090409@nal.motlabs.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [nemo] RE: NEMO or MANET? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Alex. Thank you for your reply. Please see inline comments. > -----Original Message----- > From: Alexandru Petrescu [mailto:petrescu@nal.motlabs.com] > Sent: Monday, October 13, 2003 7:41 PM > To: jafy@etri.re.kr > Cc: nemo@ietf.org; manet@ietf.org > Subject: Re: NEMO or MANET? > > > > HyunWook Cha wrote: > > ...NEMO solution using prefix delegation through DHCP is enough to > > support this issue or scenario. But, I think this kind of > solution is > > useful under infrastructured condition or very short time session. > > Yes, if infrastructure is available and only short time > communication is needed, using DHCP prefix delegation to > nodes in the mobile network can help. But of course > providing reachability at a permanent home address is not > feasible if _only_ prefix delegation is used. > If infrastructure is not available, I think that delegator in visited mobile network can not delegate its prefix any more. > > > However, let's consider what happens if no access > points(routers) are > > available and three mobile networks(cars) are connected > temporarily as > > following. A<-B<-C ( a <- b means a is parent of b or b visiting > > a) A delegates a prefix (a:b) to B. B delegates a prefix (b:c) to C. > > In this case, if a node with prefix a in A want to > communicate a node > > with prefix (b:c) in C, how can it be possible without any routing > > protocol including MANET? > > A delegates a prefix to B implies that both A and B add > entries in their respective routing tables in order to make > forwarding work. Similar when B delegates to C. In this way > routes are added where needed, and without a routing protocol > involved. Moreover, DHCP also distributes defaults routes to > be installed in routing tables. > I understand that new corresponding routing entry is inserted after a prefix is delegated to visiting mobile network and default route entry of visiting network is set to delegator. But this seems to be insufficient for my question. If sender in A want to send its packets to destination in C, default route of MR_A should be set to MR_B. Can you explain how it works more specifically? > Do you have an analytical (if practical even better) example > of behaviour of a manet routing protocol when topology > changes from A-B-C to A-C-B? > As for reactive routing protocol AODV, MR_A altready knows route information(next_hop : MR_B) for network C through route discovery before topological change. After topology changes into A-C-B, MR_A tries to forward packets(destined to a node in C) of sender in A to MR_B and finds out link between MR_A and MR_B is broken. Then, MR_A reinitiates route discovery for C. At this time, MR_C replies to RREQ of MR_A and MR_A obtains fresh route information for C by receiving RREP by MR_C. As for proactive routing protocol, each MR sends its routing message to disseminate its reachability info after it finds out that any link to neighbors change. > I was not pointing to a duplicate address assignment problem, > mainly because that equates to other cataclysms that might > happen. I was pointing to the fact that using manet > exclusively does not provide universal reachability at a > permanent home address when the nodes move anywhere at the > edges of the Internet. I agree. MIP, NEMO are tackling this subject. I think manet routing protocols are useful for inter mobile network routing when networks are nested whether they are attached to Internet or not. In addition, they can be used for RO in netsted mobile network using manet internet gateway. Regards, HyunWook Cha > > Alex > GBU > From exim@www1.ietf.org Mon Oct 13 20:57:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07741 for ; Mon, 13 Oct 2003 20:57:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9DUn-0002Lx-Qe for nemo-archive@odin.ietf.org; Mon, 13 Oct 2003 20:57:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E0v5Uo009044 for nemo-archive@odin.ietf.org; Mon, 13 Oct 2003 20:57:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9DUn-0002Ln-ID for nemo-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 20:57:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07715 for ; Mon, 13 Oct 2003 20:56:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9DUl-0003tC-00 for nemo-web-archive@ietf.org; Mon, 13 Oct 2003 20:57:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9DUk-0003t9-00 for nemo-web-archive@ietf.org; Mon, 13 Oct 2003 20:57:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9DUk-0002LJ-GN; Mon, 13 Oct 2003 20:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9DUO-0002Ke-Rj for nemo@optimus.ietf.org; Mon, 13 Oct 2003 20:56:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07707; Mon, 13 Oct 2003 20:56:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9DUL-0003t6-00; Mon, 13 Oct 2003 20:56:37 -0400 Received: from [129.254.16.14] (helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1A9DUK-0003sy-00; Mon, 13 Oct 2003 20:56:37 -0400 Received: from jafywinxp (pd412h.etri.re.kr [129.254.112.174]) by cms4.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 4Z7CZYX6; Tue, 14 Oct 2003 09:53:27 +0900 Reply-To: From: "HyunWook Cha" To: "'Alexandru Petrescu'" Cc: , Date: Tue, 14 Oct 2003 09:56:06 +0900 Message-ID: <000001c391ed$f311c2d0$ae70fe81@jafywinxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <3F8A8156.4090409@nal.motlabs.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [nemo] RE: NEMO or MANET? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Alex. Thank you for your reply. Please see inline comments. > -----Original Message----- > From: Alexandru Petrescu [mailto:petrescu@nal.motlabs.com] > Sent: Monday, October 13, 2003 7:41 PM > To: jafy@etri.re.kr > Cc: nemo@ietf.org; manet@ietf.org > Subject: Re: NEMO or MANET? > > > > HyunWook Cha wrote: > > ...NEMO solution using prefix delegation through DHCP is enough to > > support this issue or scenario. But, I think this kind of > solution is > > useful under infrastructured condition or very short time session. > > Yes, if infrastructure is available and only short time > communication is needed, using DHCP prefix delegation to > nodes in the mobile network can help. But of course > providing reachability at a permanent home address is not > feasible if _only_ prefix delegation is used. > If infrastructure is not available, I think that delegator in visited mobile network can not delegate its prefix any more. > > > However, let's consider what happens if no access > points(routers) are > > available and three mobile networks(cars) are connected > temporarily as > > following. A<-B<-C ( a <- b means a is parent of b or b visiting > > a) A delegates a prefix (a:b) to B. B delegates a prefix (b:c) to C. > > In this case, if a node with prefix a in A want to > communicate a node > > with prefix (b:c) in C, how can it be possible without any routing > > protocol including MANET? > > A delegates a prefix to B implies that both A and B add > entries in their respective routing tables in order to make > forwarding work. Similar when B delegates to C. In this way > routes are added where needed, and without a routing protocol > involved. Moreover, DHCP also distributes defaults routes to > be installed in routing tables. > I understand that new corresponding routing entry is inserted after a prefix is delegated to visiting mobile network and default route entry of visiting network is set to delegator. But this seems to be insufficient for my question. If sender in A want to send its packets to destination in C, default route of MR_A should be set to MR_B. Can you explain how it works more specifically? > Do you have an analytical (if practical even better) example > of behaviour of a manet routing protocol when topology > changes from A-B-C to A-C-B? > As for reactive routing protocol AODV, MR_A altready knows route information(next_hop : MR_B) for network C through route discovery before topological change. After topology changes into A-C-B, MR_A tries to forward packets(destined to a node in C) of sender in A to MR_B and finds out link between MR_A and MR_B is broken. Then, MR_A reinitiates route discovery for C. At this time, MR_C replies to RREQ of MR_A and MR_A obtains fresh route information for C by receiving RREP by MR_C. As for proactive routing protocol, each MR sends its routing message to disseminate its reachability info after it finds out that any link to neighbors change. > I was not pointing to a duplicate address assignment problem, > mainly because that equates to other cataclysms that might > happen. I was pointing to the fact that using manet > exclusively does not provide universal reachability at a > permanent home address when the nodes move anywhere at the > edges of the Internet. I agree. MIP, NEMO are tackling this subject. I think manet routing protocols are useful for inter mobile network routing when networks are nested whether they are attached to Internet or not. In addition, they can be used for RO in netsted mobile network using manet internet gateway. Regards, HyunWook Cha > > Alex > GBU > From nemo-admin@ietf.org Tue Oct 14 14:56:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23795 for ; Tue, 14 Oct 2003 14:56:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UKv-0001Sh-T6; Tue, 14 Oct 2003 14:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UKi-0001SP-MF for nemo@optimus.ietf.org; Tue, 14 Oct 2003 14:55:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23768 for ; Tue, 14 Oct 2003 14:55:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9UKf-0006Zb-00 for nemo@ietf.org; Tue, 14 Oct 2003 14:55:45 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1A9UKf-0006ZX-00 for nemo@ietf.org; Tue, 14 Oct 2003 14:55:45 -0400 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id h9EItDA0008431; Tue, 14 Oct 2003 11:55:14 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h9EItbJN003691; Tue, 14 Oct 2003 13:55:41 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 028062EC95; Tue, 14 Oct 2003 20:55:36 +0200 (CEST) Message-ID: <3F8C46A8.4080107@nal.motlabs.com> Date: Tue, 14 Oct 2003 20:55:36 +0200 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: jafy@etri.re.kr Cc: nemo@ietf.org References: <000001c391ed$f311c2d0$ae70fe81@jafywinxp> In-Reply-To: <000001c391ed$f311c2d0$ae70fe81@jafywinxp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: [manet] RE: NEMO or MANET? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit HyunWook Cha wrote: > If infrastructure is not available, I think that delegator in visited > mobile network can not delegate its prefix any more. I tend to disagree. If a vehicle is administratively assigned a set of addresses then that vehicle can decide to keep a subset of these addresses for its own use and further delegate another subset of these addresses to visitor nodes or networks, regardless of being connected or not to an infrastructure, or? >> A delegates a prefix to B implies that both A and B add entries in >> their respective routing tables in order to make forwarding work. >> Similar when B delegates to C. In this way routes are added where >> needed, and without a routing protocol involved. Moreover, DHCP >> also distributes defaults routes to be installed in routing tables. >> > I understand that new corresponding routing entry is inserted after a > prefix is delegated to visiting mobile network and default route > entry of visiting network is set to delegator. But this seems to be > insufficient for my question. If sender in A want to send its packets > to destination in C, default route of MR_A should be set to MR_B. If A delegates 2002:aaaa:aaaa:b::/52 to B and B delegates 2002:aaaa:aaaa:bc::/54 to C then MR_A will use its usual default route to everything different than 2002:aaaa:aaaa::/52 through its usual default route. MR_A does not need to change its default route. It is sufficient for MR_A to a have a route towards the delegated prefix 2002:aaaa:aaaa:b::/52 towards MR_B and MR_B to have a route towards the delegated prefix 2002:aaaa:aaaa:bc::54 towards MR_C. > As for reactive routing protocol AODV, MR_A altready knows route > information(next_hop : MR_B) for network C through route discovery > before topological change. After topology changes into A-C-B, MR_A > tries to forward packets(destined to a node in C) of sender in A to > MR_B and finds out link between MR_A and MR_B is broken. Then, MR_A > reinitiates route discovery for C. At this time, MR_C replies to RREQ > of MR_A and MR_A obtains fresh route information for C by receiving > RREP by MR_C. A-ha, I think I understand that. Remark that DHCP too has a sort of discovery process where when links are felt to be broken DISCOVER messages are broadcasted, so those two mechanisms could be thought of as to achieve same result. One difference that seems to hold (IMHO) is that moving networks are assumed to be rather stable both in terms of their internal structure _and_ in terms of the way they nest or group together (while manets are freer in their movement patterns). That says, in moving networks, data exchanged is of highly applicative nature and less of IP control due to frequent changes of L2 link topology. Alex GBU From exim@www1.ietf.org Tue Oct 14 14:56:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23810 for ; Tue, 14 Oct 2003 14:56:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UL1-0001Ta-3O for nemo-archive@odin.ietf.org; Tue, 14 Oct 2003 14:56:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EIu71G005674 for nemo-archive@odin.ietf.org; Tue, 14 Oct 2003 14:56:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UL0-0001TR-V2 for nemo-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 14:56:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23782 for ; Tue, 14 Oct 2003 14:55:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9UKy-0006Zp-00 for nemo-web-archive@ietf.org; Tue, 14 Oct 2003 14:56:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9UKx-0006Zl-00 for nemo-web-archive@ietf.org; Tue, 14 Oct 2003 14:56:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UKv-0001Sh-T6; Tue, 14 Oct 2003 14:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UKi-0001SP-MF for nemo@optimus.ietf.org; Tue, 14 Oct 2003 14:55:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23768 for ; Tue, 14 Oct 2003 14:55:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9UKf-0006Zb-00 for nemo@ietf.org; Tue, 14 Oct 2003 14:55:45 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1A9UKf-0006ZX-00 for nemo@ietf.org; Tue, 14 Oct 2003 14:55:45 -0400 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id h9EItDA0008431; Tue, 14 Oct 2003 11:55:14 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h9EItbJN003691; Tue, 14 Oct 2003 13:55:41 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 028062EC95; Tue, 14 Oct 2003 20:55:36 +0200 (CEST) Message-ID: <3F8C46A8.4080107@nal.motlabs.com> Date: Tue, 14 Oct 2003 20:55:36 +0200 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: jafy@etri.re.kr Cc: nemo@ietf.org References: <000001c391ed$f311c2d0$ae70fe81@jafywinxp> In-Reply-To: <000001c391ed$f311c2d0$ae70fe81@jafywinxp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: [manet] RE: NEMO or MANET? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit HyunWook Cha wrote: > If infrastructure is not available, I think that delegator in visited > mobile network can not delegate its prefix any more. I tend to disagree. If a vehicle is administratively assigned a set of addresses then that vehicle can decide to keep a subset of these addresses for its own use and further delegate another subset of these addresses to visitor nodes or networks, regardless of being connected or not to an infrastructure, or? >> A delegates a prefix to B implies that both A and B add entries in >> their respective routing tables in order to make forwarding work. >> Similar when B delegates to C. In this way routes are added where >> needed, and without a routing protocol involved. Moreover, DHCP >> also distributes defaults routes to be installed in routing tables. >> > I understand that new corresponding routing entry is inserted after a > prefix is delegated to visiting mobile network and default route > entry of visiting network is set to delegator. But this seems to be > insufficient for my question. If sender in A want to send its packets > to destination in C, default route of MR_A should be set to MR_B. If A delegates 2002:aaaa:aaaa:b::/52 to B and B delegates 2002:aaaa:aaaa:bc::/54 to C then MR_A will use its usual default route to everything different than 2002:aaaa:aaaa::/52 through its usual default route. MR_A does not need to change its default route. It is sufficient for MR_A to a have a route towards the delegated prefix 2002:aaaa:aaaa:b::/52 towards MR_B and MR_B to have a route towards the delegated prefix 2002:aaaa:aaaa:bc::54 towards MR_C. > As for reactive routing protocol AODV, MR_A altready knows route > information(next_hop : MR_B) for network C through route discovery > before topological change. After topology changes into A-C-B, MR_A > tries to forward packets(destined to a node in C) of sender in A to > MR_B and finds out link between MR_A and MR_B is broken. Then, MR_A > reinitiates route discovery for C. At this time, MR_C replies to RREQ > of MR_A and MR_A obtains fresh route information for C by receiving > RREP by MR_C. A-ha, I think I understand that. Remark that DHCP too has a sort of discovery process where when links are felt to be broken DISCOVER messages are broadcasted, so those two mechanisms could be thought of as to achieve same result. One difference that seems to hold (IMHO) is that moving networks are assumed to be rather stable both in terms of their internal structure _and_ in terms of the way they nest or group together (while manets are freer in their movement patterns). That says, in moving networks, data exchanged is of highly applicative nature and less of IP control due to frequent changes of L2 link topology. Alex GBU From nemo-admin@ietf.org Wed Oct 15 02:32:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13080 for ; Wed, 15 Oct 2003 02:32:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9fCZ-0003dN-RB; Wed, 15 Oct 2003 02:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9fCG-0003b7-SN for nemo@optimus.ietf.org; Wed, 15 Oct 2003 02:31:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12430; Wed, 15 Oct 2003 02:31:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9fCC-0007Uw-00; Wed, 15 Oct 2003 02:31:44 -0400 Received: from [129.254.16.14] (helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1A9fCC-0007Tr-00; Wed, 15 Oct 2003 02:31:44 -0400 Received: from jafywinxp (pd412h.etri.re.kr [129.254.112.174]) by cms4.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 48SD3G9B; Wed, 15 Oct 2003 15:28:02 +0900 Reply-To: From: "HyunWook Cha" Cc: , Date: Wed, 15 Oct 2003 15:30:44 +0900 Message-ID: <000c01c392e5$dcd7c480$ae70fe81@jafywinxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [nemo] FW: [manet] RE: NEMO or MANET? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, I re-post my reply about this overwraped issue to two mailing list since it seems to be rejected as a spam mail because of non-english character. If I have misunderstood, please enlighten me. Regards, HyunWook Cha -----Original Message----- From: HyunWook Cha [mailto:jafy@etri.re.kr] Sent: Wednesday, October 15, 2003 2:51 PM To: 'Alexandru Petrescu' Cc: 'nemo@ietf.org'; 'manet@ietf.org' Subject: FW: [manet] RE: NEMO or MANET? Hi Alex, I apologize that my second comment on A-C-B seems to be repeated. Please ignore that. And, I modify my first comment. Since an MR which does not have global prefixes requests prefix delegation, MR_B delegates its prefix to MR_A in case A-(B-C) that I mentioned below. How about this case where one group(cluster or partion in terms of MANET) of mobile networks is connected to another group of mobile netwroks? (A->B)-(C->D) I think prefix delegation should be extended to propagate route information for prefix of one group to other group although prefix delegation is not needed. If so, why don't you use MANET routing protcols? If I have misunderstood, please enlighten me. Thank you in advance. HyunWook Cha [Previous discussion is as following. ] Hi Alex, Ok, Since the scenario which we are considering is with no infrastructure, we do not need to mention issue like "HoA expiration". Please see inline comments. > If A delegates 2002:aaaa:aaaa:b::/52 to B and B delegates > 2002:aaaa:aaaa:bc::/54 to C then MR_A will use its usual default route > to everything different than 2002:aaaa:aaaa::/52 through its usual > default route. MR_A does not need to change its default route. > > It is sufficient for MR_A to a have a route towards the delegated > prefix 2002:aaaa:aaaa:b::/52 towards MR_B and MR_B to have a route > towards the delegated prefix 2002:aaaa:aaaa:bc::54 towards MR_C. > I agree partially. You assume that MR_C is connected to MR_B after MR_B is connected to MR_A and configure a prefix delegated from MR_A. However, let's consider another scenario. What happens if MR_C is connected to MR_B before MR_B is connected to MR_A and configure a prefix delegated from MR_A. In this case, the prefix which MR_C is delegated from MR_B is not 2002:aaaa:aaaa:bc::56 but 2002:bbbb:bbbb:c/52. If a node in network A wants to communicate one with 2002:bbbb:bbbb:c/52 as prefix in network C, it is not possible if default route entry of MR_A is not changed to MR_B or route entry for 2002:bbbb:bbbb/48 is not added in MR_A when MR_A delegates its prefix to MR_B. If the latter is perfomed, it satisfies this scenario. But, how about the case where 4 mobile networks are connected in direction of bottem_up, that is D is connected to C, C to B, and B to A and a node in A starts to communicate one( 2002:cccc:cccc:d::/52) in D. Routing protocls including manet protocols is necessary to do this. From exim@www1.ietf.org Wed Oct 15 02:32:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13111 for ; Wed, 15 Oct 2003 02:32:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9fCd-0003eL-SF for nemo-archive@odin.ietf.org; Wed, 15 Oct 2003 02:32:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F6WB5m014028 for nemo-archive@odin.ietf.org; Wed, 15 Oct 2003 02:32:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9fCd-0003eB-C7 for nemo-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 02:32:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12706 for ; Wed, 15 Oct 2003 02:32:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9fCZ-0007Vx-00 for nemo-web-archive@ietf.org; Wed, 15 Oct 2003 02:32:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9fCY-0007Vu-00 for nemo-web-archive@ietf.org; Wed, 15 Oct 2003 02:32:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9fCZ-0003dN-RB; Wed, 15 Oct 2003 02:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9fCG-0003b7-SN for nemo@optimus.ietf.org; Wed, 15 Oct 2003 02:31:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12430; Wed, 15 Oct 2003 02:31:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9fCC-0007Uw-00; Wed, 15 Oct 2003 02:31:44 -0400 Received: from [129.254.16.14] (helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1A9fCC-0007Tr-00; Wed, 15 Oct 2003 02:31:44 -0400 Received: from jafywinxp (pd412h.etri.re.kr [129.254.112.174]) by cms4.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 48SD3G9B; Wed, 15 Oct 2003 15:28:02 +0900 Reply-To: From: "HyunWook Cha" Cc: , Date: Wed, 15 Oct 2003 15:30:44 +0900 Message-ID: <000c01c392e5$dcd7c480$ae70fe81@jafywinxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [nemo] FW: [manet] RE: NEMO or MANET? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, I re-post my reply about this overwraped issue to two mailing list since it seems to be rejected as a spam mail because of non-english character. If I have misunderstood, please enlighten me. Regards, HyunWook Cha -----Original Message----- From: HyunWook Cha [mailto:jafy@etri.re.kr] Sent: Wednesday, October 15, 2003 2:51 PM To: 'Alexandru Petrescu' Cc: 'nemo@ietf.org'; 'manet@ietf.org' Subject: FW: [manet] RE: NEMO or MANET? Hi Alex, I apologize that my second comment on A-C-B seems to be repeated. Please ignore that. And, I modify my first comment. Since an MR which does not have global prefixes requests prefix delegation, MR_B delegates its prefix to MR_A in case A-(B-C) that I mentioned below. How about this case where one group(cluster or partion in terms of MANET) of mobile networks is connected to another group of mobile netwroks? (A->B)-(C->D) I think prefix delegation should be extended to propagate route information for prefix of one group to other group although prefix delegation is not needed. If so, why don't you use MANET routing protcols? If I have misunderstood, please enlighten me. Thank you in advance. HyunWook Cha [Previous discussion is as following. ] Hi Alex, Ok, Since the scenario which we are considering is with no infrastructure, we do not need to mention issue like "HoA expiration". Please see inline comments. > If A delegates 2002:aaaa:aaaa:b::/52 to B and B delegates > 2002:aaaa:aaaa:bc::/54 to C then MR_A will use its usual default route > to everything different than 2002:aaaa:aaaa::/52 through its usual > default route. MR_A does not need to change its default route. > > It is sufficient for MR_A to a have a route towards the delegated > prefix 2002:aaaa:aaaa:b::/52 towards MR_B and MR_B to have a route > towards the delegated prefix 2002:aaaa:aaaa:bc::54 towards MR_C. > I agree partially. You assume that MR_C is connected to MR_B after MR_B is connected to MR_A and configure a prefix delegated from MR_A. However, let's consider another scenario. What happens if MR_C is connected to MR_B before MR_B is connected to MR_A and configure a prefix delegated from MR_A. In this case, the prefix which MR_C is delegated from MR_B is not 2002:aaaa:aaaa:bc::56 but 2002:bbbb:bbbb:c/52. If a node in network A wants to communicate one with 2002:bbbb:bbbb:c/52 as prefix in network C, it is not possible if default route entry of MR_A is not changed to MR_B or route entry for 2002:bbbb:bbbb/48 is not added in MR_A when MR_A delegates its prefix to MR_B. If the latter is perfomed, it satisfies this scenario. But, how about the case where 4 mobile networks are connected in direction of bottem_up, that is D is connected to C, C to B, and B to A and a node in A starts to communicate one( 2002:cccc:cccc:d::/52) in D. Routing protocls including manet protocols is necessary to do this. From nemo-admin@ietf.org Wed Oct 15 04:01:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19591 for ; Wed, 15 Oct 2003 04:01:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9gaf-00028y-S9; Wed, 15 Oct 2003 04:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9gaX-00028B-Ae for nemo@optimus.ietf.org; Wed, 15 Oct 2003 04:00:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19548 for ; Wed, 15 Oct 2003 04:00:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9gaR-0000tC-00 for nemo@ietf.org; Wed, 15 Oct 2003 04:00:51 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1A9gaQ-0000t9-00 for nemo@ietf.org; Wed, 15 Oct 2003 04:00:50 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id h9F80IA0000976; Wed, 15 Oct 2003 01:00:18 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h9F80efI015775; Wed, 15 Oct 2003 03:00:42 -0500 Received: from motorola.com (zfr01-0108.crm.mot.com [10.161.201.135]) by thorgal.crm.mot.com (Postfix) with ESMTP id 6E32A2EC95; Wed, 15 Oct 2003 10:00:42 +0200 (CEST) Message-ID: <3F8CFEAA.FD82596F@motorola.com> Date: Wed, 15 Oct 2003 10:00:42 +0200 From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: NEMO , "Pascal Thubert (pthubert)" , "T.J. Kniveton" , Thierry Ernst Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] IPR on NEMO basic protocol Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pascal and WG Chairs, Referring to Cisco's statement about IPR claimed in draft-ietf-nemo-basic-support: http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-nemo-basic-support.txt Would it be possible to inform the working group about the name/identifier of those patents or patent applications (or better a pointer to them) so that the working group can get a better understanding of their impact on the nemo basic support draft? BTW, Nokia already provided such information in their statement: http://www.ietf.org/ietf/IPR/nokia-ipr-draft-ietf-nemo-basic-support.txt Thanks a lot, Christophe From exim@www1.ietf.org Wed Oct 15 04:01:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19609 for ; Wed, 15 Oct 2003 04:01:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9gam-00029v-W0 for nemo-archive@odin.ietf.org; Wed, 15 Oct 2003 04:01:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F81CwC008300 for nemo-archive@odin.ietf.org; Wed, 15 Oct 2003 04:01:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9gam-00029m-HN for nemo-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 04:01:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19567 for ; Wed, 15 Oct 2003 04:01:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9gaj-0000tW-00 for nemo-web-archive@ietf.org; Wed, 15 Oct 2003 04:01:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9gaj-0000tT-00 for nemo-web-archive@ietf.org; Wed, 15 Oct 2003 04:01:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9gaf-00028y-S9; Wed, 15 Oct 2003 04:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9gaX-00028B-Ae for nemo@optimus.ietf.org; Wed, 15 Oct 2003 04:00:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19548 for ; Wed, 15 Oct 2003 04:00:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9gaR-0000tC-00 for nemo@ietf.org; Wed, 15 Oct 2003 04:00:51 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1A9gaQ-0000t9-00 for nemo@ietf.org; Wed, 15 Oct 2003 04:00:50 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id h9F80IA0000976; Wed, 15 Oct 2003 01:00:18 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h9F80efI015775; Wed, 15 Oct 2003 03:00:42 -0500 Received: from motorola.com (zfr01-0108.crm.mot.com [10.161.201.135]) by thorgal.crm.mot.com (Postfix) with ESMTP id 6E32A2EC95; Wed, 15 Oct 2003 10:00:42 +0200 (CEST) Message-ID: <3F8CFEAA.FD82596F@motorola.com> Date: Wed, 15 Oct 2003 10:00:42 +0200 From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: NEMO , "Pascal Thubert (pthubert)" , "T.J. Kniveton" , Thierry Ernst Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] IPR on NEMO basic protocol Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal and WG Chairs, Referring to Cisco's statement about IPR claimed in draft-ietf-nemo-basic-support: http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-nemo-basic-support.txt Would it be possible to inform the working group about the name/identifier of those patents or patent applications (or better a pointer to them) so that the working group can get a better understanding of their impact on the nemo basic support draft? BTW, Nokia already provided such information in their statement: http://www.ietf.org/ietf/IPR/nokia-ipr-draft-ietf-nemo-basic-support.txt Thanks a lot, Christophe From nemo-admin@ietf.org Wed Oct 15 11:56:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05981 for ; Wed, 15 Oct 2003 11:56:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9o0H-00084a-BF; Wed, 15 Oct 2003 11:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nzJ-00083Z-EU for nemo@optimus.ietf.org; Wed, 15 Oct 2003 11:55:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05942 for ; Wed, 15 Oct 2003 11:54:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9nzI-0006M4-00 for nemo@ietf.org; Wed, 15 Oct 2003 11:55:00 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1A9nzE-0006M1-00 for nemo@ietf.org; Wed, 15 Oct 2003 11:54:56 -0400 Received: from [64.36.73.242] (home2.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h9FFuZMU037000 for ; Wed, 15 Oct 2003 08:56:35 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 15 Oct 2003 08:54:47 -0700 From: "T.J. Kniveton" To: Message-ID: In-Reply-To: <3F8CFEAA.FD82596F@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: IPR on NEMO basic protocol Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit We are actively working on getting an answer to these questions. As soon as it is avaible, we will share it with the group. -TJ & Thierry On 10/15/03 1:00 AM, "Christophe Janneteau" wrote: > Pascal and WG Chairs, > > Referring to Cisco's statement about IPR claimed in > draft-ietf-nemo-basic-support: > > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-nemo-basic-support.txt > > Would it be possible to inform the working group about the > name/identifier of those patents or patent applications (or better a > pointer to them) so that the working group can get a better > understanding of their impact on the nemo basic support draft? > > BTW, Nokia already provided such information in their statement: > > http://www.ietf.org/ietf/IPR/nokia-ipr-draft-ietf-nemo-basic-support.txt > > Thanks a lot, > Christophe > From exim@www1.ietf.org Wed Oct 15 11:56:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05995 for ; Wed, 15 Oct 2003 11:56:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9o0L-00085i-80 for nemo-archive@odin.ietf.org; Wed, 15 Oct 2003 11:56:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FFu51c031096 for nemo-archive@odin.ietf.org; Wed, 15 Oct 2003 11:56:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9o0L-00085T-3z for nemo-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 11:56:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05972 for ; Wed, 15 Oct 2003 11:55:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9o0J-0006Mt-00 for nemo-web-archive@ietf.org; Wed, 15 Oct 2003 11:56:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9o0J-0006Mo-00 for nemo-web-archive@ietf.org; Wed, 15 Oct 2003 11:56:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9o0H-00084a-BF; Wed, 15 Oct 2003 11:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nzJ-00083Z-EU for nemo@optimus.ietf.org; Wed, 15 Oct 2003 11:55:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05942 for ; Wed, 15 Oct 2003 11:54:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9nzI-0006M4-00 for nemo@ietf.org; Wed, 15 Oct 2003 11:55:00 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1A9nzE-0006M1-00 for nemo@ietf.org; Wed, 15 Oct 2003 11:54:56 -0400 Received: from [64.36.73.242] (home2.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h9FFuZMU037000 for ; Wed, 15 Oct 2003 08:56:35 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 15 Oct 2003 08:54:47 -0700 From: "T.J. Kniveton" To: Message-ID: In-Reply-To: <3F8CFEAA.FD82596F@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: IPR on NEMO basic protocol Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We are actively working on getting an answer to these questions. As soon as it is avaible, we will share it with the group. -TJ & Thierry On 10/15/03 1:00 AM, "Christophe Janneteau" wrote: > Pascal and WG Chairs, > > Referring to Cisco's statement about IPR claimed in > draft-ietf-nemo-basic-support: > > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-nemo-basic-support.txt > > Would it be possible to inform the working group about the > name/identifier of those patents or patent applications (or better a > pointer to them) so that the working group can get a better > understanding of their impact on the nemo basic support draft? > > BTW, Nokia already provided such information in their statement: > > http://www.ietf.org/ietf/IPR/nokia-ipr-draft-ietf-nemo-basic-support.txt > > Thanks a lot, > Christophe > From nemo-admin@ietf.org Wed Oct 15 15:33:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18462 for ; Wed, 15 Oct 2003 15:33:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9rOH-0004LF-JR; Wed, 15 Oct 2003 15:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9rNz-0004KW-KH for nemo@optimus.ietf.org; Wed, 15 Oct 2003 15:32:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18320; Wed, 15 Oct 2003 15:32:35 -0400 (EDT) Message-Id: <200310151932.PAA18320@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 15 Oct 2003 15:32:35 -0400 Subject: [nemo] I-D ACTION:draft-thubert-nemo-basic-usages-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Examples of basic Nemo usage Author(s) : P. Thubert, R. Wakikawa, V. Devarapalli Filename : draft-thubert-nemo-basic-usages-00.txt Pages : 15 Date : 2003-10-15 This paper documents some practical scenarios and the associated issues when deploying Mobile Routers, conforming the Nemo Basic Support draft [6]. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in the Nemo and Nemo Design mailing lists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thubert-nemo-basic-usages-00.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-thubert-nemo-basic-usages-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-thubert-nemo-basic-usages-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-15142457.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-thubert-nemo-basic-usages-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-thubert-nemo-basic-usages-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-15142457.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Wed Oct 15 15:33:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18483 for ; Wed, 15 Oct 2003 15:33:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9rOL-0004Mj-3f for nemo-archive@odin.ietf.org; Wed, 15 Oct 2003 15:33:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FJX5Jv016777 for nemo-archive@odin.ietf.org; Wed, 15 Oct 2003 15:33:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9rOK-0004MW-Vb for nemo-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 15:33:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18372 for ; Wed, 15 Oct 2003 15:32:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9rOJ-00029t-00 for nemo-web-archive@ietf.org; Wed, 15 Oct 2003 15:33:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9rOJ-00029p-00 for nemo-web-archive@ietf.org; Wed, 15 Oct 2003 15:33:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9rOH-0004LF-JR; Wed, 15 Oct 2003 15:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9rNz-0004KW-KH for nemo@optimus.ietf.org; Wed, 15 Oct 2003 15:32:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18320; Wed, 15 Oct 2003 15:32:35 -0400 (EDT) Message-Id: <200310151932.PAA18320@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 15 Oct 2003 15:32:35 -0400 Subject: [nemo] I-D ACTION:draft-thubert-nemo-basic-usages-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Examples of basic Nemo usage Author(s) : P. Thubert, R. Wakikawa, V. Devarapalli Filename : draft-thubert-nemo-basic-usages-00.txt Pages : 15 Date : 2003-10-15 This paper documents some practical scenarios and the associated issues when deploying Mobile Routers, conforming the Nemo Basic Support draft [6]. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in the Nemo and Nemo Design mailing lists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thubert-nemo-basic-usages-00.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-thubert-nemo-basic-usages-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-thubert-nemo-basic-usages-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-15142457.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-thubert-nemo-basic-usages-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-thubert-nemo-basic-usages-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-15142457.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Wed Oct 22 06:00:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01411 for ; Wed, 22 Oct 2003 06:00:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACFma-0000gP-Px; Wed, 22 Oct 2003 06:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACFle-0000SG-Mw for nemo@optimus.ietf.org; Wed, 22 Oct 2003 05:59:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01348 for ; Wed, 22 Oct 2003 05:58:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACFla-0002r4-00 for nemo@ietf.org; Wed, 22 Oct 2003 05:58:58 -0400 Received: from mail1.ics.ntts.co.jp ([202.32.24.45]) by ietf-mx with esmtp (Exim 4.12) id 1ACFlZ-0002r0-00 for nemo@ietf.org; Wed, 22 Oct 2003 05:58:58 -0400 Received: from mail26.silk.ntts.co.jp by mail1.ics.ntts.co.jp (8.12.10/3.7W-NTTSOFT-SUR2.0) id h9M9wuSZ021130 for ; Wed, 22 Oct 2003 18:58:56 +0900 (JST) (envelope-from takamiya@po.ntts.co.jp) Received: from daemon.inl.ntts.co.jp by mail26.silk.ntts.co.jp (8.11.7/3.7W-silk-4.6) id h9M9wt517963 for ; Wed, 22 Oct 2003 18:58:55 +0900 (JST) (envelope-from takamiya@po.ntts.co.jp) Received: (qmail 46455 invoked by alias); 22 Oct 2003 18:58:55 +0900 Received: (qmail 46447 invoked from network); 22 Oct 2003 18:58:55 +0900 Received: from localhost by localhost with SMTP; 22 Oct 2003 18:58:55 +0900 Date: Wed, 22 Oct 2003 18:58:54 +0900 (JST) Message-Id: <20031022.185854.846933446.takamiya@po.ntts.co.jp> To: nemo@ietf.org From: Noriaki Takamiya X-Face: +<)&j!Ce24nM@a.\f6TA,]^9Q76[_QN_[QR-(bT&>b40Oo[:`R(>b7!b-|q5k&.8CO[_Oh_ !9Nk0rikK70~?|08EFH|:]iF6pwPlnfEn-wo-voY:rP?%7p%cxjnbf'hglO'se&QwZN7/RVX!U7*P% cTV('HfHp+?g1+hx7\+J.W]G zYWv%LsDc X-Mailer: Mew version 3.3 on XEmacs 21.4.13 (Rational FORTRAN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] About BA status 141 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I'm sorry, but I have a simple question. In draft-ietf-nemo-basic-support-01.txt, BA status code 141 is defined. I wonder how HA decides to send BA with status 141. For example, when MR sends BU with explicit or Explicit Prefix Length mode, HA process this BU as following(section 6.2): 1)check H bit in BU 2)check the contents of BU 3)verify the mobile network prefixes using Prefix Table ->If failed, HA returns BA with status 142. 4)try to setup forwarding to all prefixes listed in BU. ->If failed, HA returns BA with status 141. In 4), what does HA verify? Does 'fail' mean that HA couldn't just configure the forwarding(e.g. reverse tunneling or setup routing table)? IMO, almost misconfigured prefix in BU will result in status 142. What is the situation that HA could return 141? If I misunderstand, correct me. regards, -- Noriaki Takamiya From exim@www1.ietf.org Wed Oct 22 06:00:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01426 for ; Wed, 22 Oct 2003 06:00:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACFmh-0000ir-Ou for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 06:00:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MA07aV002774 for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 06:00:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACFmh-0000ia-1W for nemo-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 06:00:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01390 for ; Wed, 22 Oct 2003 05:59:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACFmd-0002rr-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 06:00:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACFmc-0002rn-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 06:00:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACFma-0000gP-Px; Wed, 22 Oct 2003 06:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACFle-0000SG-Mw for nemo@optimus.ietf.org; Wed, 22 Oct 2003 05:59:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01348 for ; Wed, 22 Oct 2003 05:58:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACFla-0002r4-00 for nemo@ietf.org; Wed, 22 Oct 2003 05:58:58 -0400 Received: from mail1.ics.ntts.co.jp ([202.32.24.45]) by ietf-mx with esmtp (Exim 4.12) id 1ACFlZ-0002r0-00 for nemo@ietf.org; Wed, 22 Oct 2003 05:58:58 -0400 Received: from mail26.silk.ntts.co.jp by mail1.ics.ntts.co.jp (8.12.10/3.7W-NTTSOFT-SUR2.0) id h9M9wuSZ021130 for ; Wed, 22 Oct 2003 18:58:56 +0900 (JST) (envelope-from takamiya@po.ntts.co.jp) Received: from daemon.inl.ntts.co.jp by mail26.silk.ntts.co.jp (8.11.7/3.7W-silk-4.6) id h9M9wt517963 for ; Wed, 22 Oct 2003 18:58:55 +0900 (JST) (envelope-from takamiya@po.ntts.co.jp) Received: (qmail 46455 invoked by alias); 22 Oct 2003 18:58:55 +0900 Received: (qmail 46447 invoked from network); 22 Oct 2003 18:58:55 +0900 Received: from localhost by localhost with SMTP; 22 Oct 2003 18:58:55 +0900 Date: Wed, 22 Oct 2003 18:58:54 +0900 (JST) Message-Id: <20031022.185854.846933446.takamiya@po.ntts.co.jp> To: nemo@ietf.org From: Noriaki Takamiya X-Face: +<)&j!Ce24nM@a.\f6TA,]^9Q76[_QN_[QR-(bT&>b40Oo[:`R(>b7!b-|q5k&.8CO[_Oh_ !9Nk0rikK70~?|08EFH|:]iF6pwPlnfEn-wo-voY:rP?%7p%cxjnbf'hglO'se&QwZN7/RVX!U7*P% cTV('HfHp+?g1+hx7\+J.W]G zYWv%LsDc X-Mailer: Mew version 3.3 on XEmacs 21.4.13 (Rational FORTRAN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] About BA status 141 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I'm sorry, but I have a simple question. In draft-ietf-nemo-basic-support-01.txt, BA status code 141 is defined. I wonder how HA decides to send BA with status 141. For example, when MR sends BU with explicit or Explicit Prefix Length mode, HA process this BU as following(section 6.2): 1)check H bit in BU 2)check the contents of BU 3)verify the mobile network prefixes using Prefix Table ->If failed, HA returns BA with status 142. 4)try to setup forwarding to all prefixes listed in BU. ->If failed, HA returns BA with status 141. In 4), what does HA verify? Does 'fail' mean that HA couldn't just configure the forwarding(e.g. reverse tunneling or setup routing table)? IMO, almost misconfigured prefix in BU will result in status 142. What is the situation that HA could return 141? If I misunderstand, correct me. regards, -- Noriaki Takamiya From nemo-admin@ietf.org Wed Oct 22 11:47:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15046 for ; Wed, 22 Oct 2003 11:47:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLCO-0001i5-Df; Wed, 22 Oct 2003 11:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLBl-0001eY-5O for nemo@optimus.ietf.org; Wed, 22 Oct 2003 11:46:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14980 for ; Wed, 22 Oct 2003 11:46:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLBj-0006vf-00 for nemo@ietf.org; Wed, 22 Oct 2003 11:46:20 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1ACLBj-0006vV-00 for nemo@ietf.org; Wed, 22 Oct 2003 11:46:19 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h9MFkClW022621; Wed, 22 Oct 2003 08:46:14 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h9MFcaQe009066; Wed, 22 Oct 2003 10:38:38 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 12E472EC95; Wed, 22 Oct 2003 17:39:23 +0200 (CEST) Message-ID: <3F96A4AA.5000105@nal.motlabs.com> Date: Wed, 22 Oct 2003 17:39:22 +0200 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: Noriaki Takamiya Cc: nemo@ietf.org Subject: Re: [nemo] About BA status 141 References: <20031022.185854.846933446.takamiya@po.ntts.co.jp> In-Reply-To: <20031022.185854.846933446.takamiya@po.ntts.co.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Noriaki Takamiya wrote: > Hi, > > I'm sorry, but I have a simple question. > > In draft-ietf-nemo-basic-support-01.txt, BA status code 141 is defined. > > I wonder how HA decides to send BA with status 141. > > For example, when MR sends BU with explicit or Explicit Prefix > Length mode, HA process this BU as following(section 6.2): > > 1)check H bit in BU > 2)check the contents of BU > 3)verify the mobile network prefixes using Prefix Table > ->If failed, HA returns BA with status 142. > 4)try to setup forwarding to all prefixes listed in BU. > ->If failed, HA returns BA with status 141. > > In 4), what does HA verify? > > Does 'fail' mean that HA couldn't just configure the > forwarding(e.g. reverse tunneling or setup routing table)? I guess so. For example if a similar entry already exists in the table, or if the prefix is larger than 128. No? (prefix len can be larger than 128 by error because encoded on 8bit instead of 7 because easier to program). Alex GBU From exim@www1.ietf.org Wed Oct 22 11:47:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15063 for ; Wed, 22 Oct 2003 11:47:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLCX-0001kH-Me for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 11:47:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MFl99C006705 for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 11:47:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLCX-0001k4-HV for nemo-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 11:47:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15008 for ; Wed, 22 Oct 2003 11:46:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLCW-0006wQ-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 11:47:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACLCW-0006wN-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 11:47:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLCO-0001i5-Df; Wed, 22 Oct 2003 11:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLBl-0001eY-5O for nemo@optimus.ietf.org; Wed, 22 Oct 2003 11:46:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14980 for ; Wed, 22 Oct 2003 11:46:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLBj-0006vf-00 for nemo@ietf.org; Wed, 22 Oct 2003 11:46:20 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1ACLBj-0006vV-00 for nemo@ietf.org; Wed, 22 Oct 2003 11:46:19 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h9MFkClW022621; Wed, 22 Oct 2003 08:46:14 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h9MFcaQe009066; Wed, 22 Oct 2003 10:38:38 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 12E472EC95; Wed, 22 Oct 2003 17:39:23 +0200 (CEST) Message-ID: <3F96A4AA.5000105@nal.motlabs.com> Date: Wed, 22 Oct 2003 17:39:22 +0200 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: Noriaki Takamiya Cc: nemo@ietf.org Subject: Re: [nemo] About BA status 141 References: <20031022.185854.846933446.takamiya@po.ntts.co.jp> In-Reply-To: <20031022.185854.846933446.takamiya@po.ntts.co.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Noriaki Takamiya wrote: > Hi, > > I'm sorry, but I have a simple question. > > In draft-ietf-nemo-basic-support-01.txt, BA status code 141 is defined. > > I wonder how HA decides to send BA with status 141. > > For example, when MR sends BU with explicit or Explicit Prefix > Length mode, HA process this BU as following(section 6.2): > > 1)check H bit in BU > 2)check the contents of BU > 3)verify the mobile network prefixes using Prefix Table > ->If failed, HA returns BA with status 142. > 4)try to setup forwarding to all prefixes listed in BU. > ->If failed, HA returns BA with status 141. > > In 4), what does HA verify? > > Does 'fail' mean that HA couldn't just configure the > forwarding(e.g. reverse tunneling or setup routing table)? I guess so. For example if a similar entry already exists in the table, or if the prefix is larger than 128. No? (prefix len can be larger than 128 by error because encoded on 8bit instead of 7 because easier to program). Alex GBU From nemo-admin@ietf.org Wed Oct 22 12:23:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16559 for ; Wed, 22 Oct 2003 12:23:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLlF-0007GO-UC; Wed, 22 Oct 2003 12:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLl8-0007ER-2w for nemo@optimus.ietf.org; Wed, 22 Oct 2003 12:22:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16472 for ; Wed, 22 Oct 2003 12:22:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLl6-0007Ou-00 for nemo@ietf.org; Wed, 22 Oct 2003 12:22:52 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1ACLl5-0007Or-00 for nemo@ietf.org; Wed, 22 Oct 2003 12:22:52 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h9MGMOlW019315; Wed, 22 Oct 2003 09:22:27 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h9MGMHWV005444; Wed, 22 Oct 2003 11:22:19 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 962B62EC95; Wed, 22 Oct 2003 18:22:17 +0200 (CEST) Message-ID: <3F96AEB9.4030709@nal.motlabs.com> Date: Wed, 22 Oct 2003 18:22:17 +0200 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@ietf.org Cc: Ryuji Wakikawa , Vijay Devarapalli , "Pascal Thubert (pthubert)" X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Comments on draft-wakikawa-mip6-nemo-haha-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello to authors of draft-wakikawa-mip6-nemo-haha-00.txt available at http://www.mobilenetworks.org/nemo/drafts/draft-wakikawa-mip6-nemo-haha-00.txt Here are some comments on the draft. Please take them as comments only. The whole idea of having an inter-HA protocol (HAHA) for HA's _not_ on the same link seems valuable from several standpoints, most importantly for redundancy. The presentation of the mechanisms makes sense and covers a large set of scenarios; thanks for writing it. However, I have doubts with respect to motivating the use of these mechanisms in order to help with RO; and also doubting about where to target these mechanisms: MIP6 or NEMO. > Sometimes the Mobile Network could be closer to the Correspondent > Node than the Home Agent. If the Mobile Router could pick another > Home Agent closer to its current location, the tunneling overhead on > every packet could be reduced to a much shorter path in the > Internet. In order to have important gains from reducing the path length of the path on which encapsulation happens, it is implicit that they are proportional with the distance between HA's. The farther apart are the HA's placed, the better gains in terms of having a shorter path over which encapsulation is needed. Otherwise, if HA's are close, why bother for two-three short links. But the farther distanced the HA's are placed, the more difficult it is for them to advertise the same Home Address (or MNP) without disturbing the routing in the overall Internet. > Multiple Home Agents could be located on different links and still > serve the same home prefix. I think that if they are located on different links (IP subnets) then they will have difficulty to advertise reachability to a same Home Address (or same MNP). If these home links are relatively close to each other, as to form an IGP area, then adertising reachability towards the same Home Address (or MNP) is indeed feasible, and OSPF does that. If however these home links are in different domains (separated by e.g. BGP) then I doubt these HA's can effectively advertise reachability of the same Home Address (or MNP). No? > When multiple Home Agents are configured at different links, each > home agent is expected to know the other Home Agents beforehand and > establishes Security Association with them for a secure path towards > the other home agent. I wonder how this could be done, to have a set of HA's scattered in the Internet and have SA's among them, do you have a specific tool in mind? > But each Home Agent can not listen Router Advertisements sent by the > other Home Agents configured at different link, because Router > Advertisements can not be sent over the link-local scope. ^^^ Maybe "RAs can _only_ be sent over a ll scope"? YEs, the overall cause-effect makes sense, just maybe the "not" is wrong. > The Home Agent Solicitation message MUST NOT be multicasted Why not? I understand that RA's can not be multicasted on other scope than link, but why forbidding HAS being multicasted on a wider scope? It would be good to multicast the HAS especially if there are many HAs in this "HA multicast group". > The Home Agent initiated switching is useful for load-sharing of each > Home Agents. A Home Agent can control the load average by moving > some of Mobile Routers to other Home Agents compulsory. "compulsory"? Maybe "compulsorily"?, just a thought... > When a Home Agent receives a Binding Update from a Mobile Router and > processes the Binding Update successfully, it enables route > distribution for the mobile network prefixes. So HA receives a completely unknown MNP in a BU and redistributes it to the Internet? How is HA confident about MR not attacking the Internet? > Each Home Agent advertises the same home prefix to the Internet. How far are the HA's from each other and how far do those home prefixes propagate to the Internet? > On the other hand, if the Home Agent does not enable forwarding for > the Home Address and the mobile network prefixes, it tunnels > intercepted packets to the primary Home Agent (Fig 2) first. If the HA does not enable forwarding for that Home Address, then how it obtained packets addressed to that Home Address in first place? I agree that if HA obtains those packets, it then forwards them to the primary HA, and that's a good idea, but how does it "intercept" those packets in first place if it does not forward for that Home Address? > One specific advantage of not relying on a Home Link for HAHA > communication is that for a large configuration, the Home Agents can > be organized hierarchically and distributed geographically, as a set > of local clusters linked together to form a global Home Network. I think this explanation is very important to motivate the need of HAHA previously described. I think this picture should be given somewhere at the beginning of the document, instead of at the appendix. Still, if we consider a very wide-area network (inter-continental) as described above, then HAHA can work only if the longest links between the clusters are L2 links (say ATM or sattelite or fiber, your choice), and are very short in terms of number of IP hops. One can not imagine that two HAs advertising same MNP are separated by BGP-served zones, because dynamically inducing new routes might pose problems in terms of routing table size (or so they say). And, once we assume that those HAs are only a few IP hops apart (even if over inter-continental lengths) then Mobile IP per se brings in little advantage. Just use OSPF in this small domain (small in terms of IP hops, but large in terms of physical distance) and suddenly encapsulation problems and RO problems disappear. And finally, thank you for providing the concepts in this draft, the mechanisms of binding synchronization and so on make sense, the messages are described in bit-detail (few drafts do) and looking forward for your comments, Alex GBU From exim@www1.ietf.org Wed Oct 22 12:23:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16575 for ; Wed, 22 Oct 2003 12:23:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLlO-0007Jw-DG for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 12:23:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MGNAPp028134 for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 12:23:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLlO-0007IY-6q for nemo-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 12:23:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16517 for ; Wed, 22 Oct 2003 12:22:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLlJ-0007QL-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 12:23:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACLlJ-0007QI-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 12:23:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLlF-0007GO-UC; Wed, 22 Oct 2003 12:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLl8-0007ER-2w for nemo@optimus.ietf.org; Wed, 22 Oct 2003 12:22:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16472 for ; Wed, 22 Oct 2003 12:22:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLl6-0007Ou-00 for nemo@ietf.org; Wed, 22 Oct 2003 12:22:52 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1ACLl5-0007Or-00 for nemo@ietf.org; Wed, 22 Oct 2003 12:22:52 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h9MGMOlW019315; Wed, 22 Oct 2003 09:22:27 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h9MGMHWV005444; Wed, 22 Oct 2003 11:22:19 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 962B62EC95; Wed, 22 Oct 2003 18:22:17 +0200 (CEST) Message-ID: <3F96AEB9.4030709@nal.motlabs.com> Date: Wed, 22 Oct 2003 18:22:17 +0200 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@ietf.org Cc: Ryuji Wakikawa , Vijay Devarapalli , "Pascal Thubert (pthubert)" X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Comments on draft-wakikawa-mip6-nemo-haha-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello to authors of draft-wakikawa-mip6-nemo-haha-00.txt available at http://www.mobilenetworks.org/nemo/drafts/draft-wakikawa-mip6-nemo-haha-00.txt Here are some comments on the draft. Please take them as comments only. The whole idea of having an inter-HA protocol (HAHA) for HA's _not_ on the same link seems valuable from several standpoints, most importantly for redundancy. The presentation of the mechanisms makes sense and covers a large set of scenarios; thanks for writing it. However, I have doubts with respect to motivating the use of these mechanisms in order to help with RO; and also doubting about where to target these mechanisms: MIP6 or NEMO. > Sometimes the Mobile Network could be closer to the Correspondent > Node than the Home Agent. If the Mobile Router could pick another > Home Agent closer to its current location, the tunneling overhead on > every packet could be reduced to a much shorter path in the > Internet. In order to have important gains from reducing the path length of the path on which encapsulation happens, it is implicit that they are proportional with the distance between HA's. The farther apart are the HA's placed, the better gains in terms of having a shorter path over which encapsulation is needed. Otherwise, if HA's are close, why bother for two-three short links. But the farther distanced the HA's are placed, the more difficult it is for them to advertise the same Home Address (or MNP) without disturbing the routing in the overall Internet. > Multiple Home Agents could be located on different links and still > serve the same home prefix. I think that if they are located on different links (IP subnets) then they will have difficulty to advertise reachability to a same Home Address (or same MNP). If these home links are relatively close to each other, as to form an IGP area, then adertising reachability towards the same Home Address (or MNP) is indeed feasible, and OSPF does that. If however these home links are in different domains (separated by e.g. BGP) then I doubt these HA's can effectively advertise reachability of the same Home Address (or MNP). No? > When multiple Home Agents are configured at different links, each > home agent is expected to know the other Home Agents beforehand and > establishes Security Association with them for a secure path towards > the other home agent. I wonder how this could be done, to have a set of HA's scattered in the Internet and have SA's among them, do you have a specific tool in mind? > But each Home Agent can not listen Router Advertisements sent by the > other Home Agents configured at different link, because Router > Advertisements can not be sent over the link-local scope. ^^^ Maybe "RAs can _only_ be sent over a ll scope"? YEs, the overall cause-effect makes sense, just maybe the "not" is wrong. > The Home Agent Solicitation message MUST NOT be multicasted Why not? I understand that RA's can not be multicasted on other scope than link, but why forbidding HAS being multicasted on a wider scope? It would be good to multicast the HAS especially if there are many HAs in this "HA multicast group". > The Home Agent initiated switching is useful for load-sharing of each > Home Agents. A Home Agent can control the load average by moving > some of Mobile Routers to other Home Agents compulsory. "compulsory"? Maybe "compulsorily"?, just a thought... > When a Home Agent receives a Binding Update from a Mobile Router and > processes the Binding Update successfully, it enables route > distribution for the mobile network prefixes. So HA receives a completely unknown MNP in a BU and redistributes it to the Internet? How is HA confident about MR not attacking the Internet? > Each Home Agent advertises the same home prefix to the Internet. How far are the HA's from each other and how far do those home prefixes propagate to the Internet? > On the other hand, if the Home Agent does not enable forwarding for > the Home Address and the mobile network prefixes, it tunnels > intercepted packets to the primary Home Agent (Fig 2) first. If the HA does not enable forwarding for that Home Address, then how it obtained packets addressed to that Home Address in first place? I agree that if HA obtains those packets, it then forwards them to the primary HA, and that's a good idea, but how does it "intercept" those packets in first place if it does not forward for that Home Address? > One specific advantage of not relying on a Home Link for HAHA > communication is that for a large configuration, the Home Agents can > be organized hierarchically and distributed geographically, as a set > of local clusters linked together to form a global Home Network. I think this explanation is very important to motivate the need of HAHA previously described. I think this picture should be given somewhere at the beginning of the document, instead of at the appendix. Still, if we consider a very wide-area network (inter-continental) as described above, then HAHA can work only if the longest links between the clusters are L2 links (say ATM or sattelite or fiber, your choice), and are very short in terms of number of IP hops. One can not imagine that two HAs advertising same MNP are separated by BGP-served zones, because dynamically inducing new routes might pose problems in terms of routing table size (or so they say). And, once we assume that those HAs are only a few IP hops apart (even if over inter-continental lengths) then Mobile IP per se brings in little advantage. Just use OSPF in this small domain (small in terms of IP hops, but large in terms of physical distance) and suddenly encapsulation problems and RO problems disappear. And finally, thank you for providing the concepts in this draft, the mechanisms of binding synchronization and so on make sense, the messages are described in bit-detail (few drafts do) and looking forward for your comments, Alex GBU From nemo-admin@ietf.org Wed Oct 22 12:47:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17248 for ; Wed, 22 Oct 2003 12:47:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACM8T-0001v3-52; Wed, 22 Oct 2003 12:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACM7o-0001pt-3j for nemo@optimus.ietf.org; Wed, 22 Oct 2003 12:46:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17191 for ; Wed, 22 Oct 2003 12:46:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACM7k-0007eC-00 for nemo@ietf.org; Wed, 22 Oct 2003 12:46:17 -0400 Received: from mail1.ics.ntts.co.jp ([202.32.24.45]) by ietf-mx with esmtp (Exim 4.12) id 1ACM7j-0007e8-00 for nemo@ietf.org; Wed, 22 Oct 2003 12:46:16 -0400 Received: from mail26.silk.ntts.co.jp by mail1.ics.ntts.co.jp (8.12.10/3.7W-NTTSOFT-SUR2.0) id h9MGkDSZ018970 for ; Thu, 23 Oct 2003 01:46:13 +0900 (JST) (envelope-from takamiya@po.ntts.co.jp) Received: from daemon.inl.ntts.co.jp by mail26.silk.ntts.co.jp (8.11.7/3.7W-silk-4.6) id h9MGkCG10609 for ; Thu, 23 Oct 2003 01:46:12 +0900 (JST) (envelope-from takamiya@po.ntts.co.jp) Received: (qmail 58007 invoked by alias); 23 Oct 2003 01:46:12 +0900 Received: (qmail 57992 invoked from network); 23 Oct 2003 01:46:12 +0900 Received: from localhost by localhost with SMTP; 23 Oct 2003 01:46:12 +0900 Date: Thu, 23 Oct 2003 01:46:12 +0900 (JST) Message-Id: <20031023.014612.607960534.takamiya@po.ntts.co.jp> To: petrescu@nal.motlabs.com Cc: nemo@ietf.org Subject: Re: [nemo] About BA status 141 From: Noriaki Takamiya In-Reply-To: <3F96A4AA.5000105@nal.motlabs.com> References: <20031022.185854.846933446.takamiya@po.ntts.co.jp> <3F96A4AA.5000105@nal.motlabs.com> X-Face: +<)&j!Ce24nM@a.\f6TA,]^9Q76[_QN_[QR-(bT&>b40Oo[:`R(>b7!b-|q5k&.8CO[_Oh_ !9Nk0rikK70~?|08EFH|:]iF6pwPlnfEn-wo-voY:rP?%7p%cxjnbf'hglO'se&QwZN7/RVX!U7*P% cTV('HfHp+?g1+hx7\+J.W]G zYWv%LsDc X-Mailer: Mew version 3.3 on XEmacs 21.4.13 (Rational FORTRAN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, >> Wed, 22 Oct 2003 17:39:22 +0200 >> [Subject: Re: [nemo] About BA status 141] >> Alexandru Petrescu wrote... petrescu> I guess so. For example if a similar entry already exists in the table, petrescu> or if the prefix is larger than 128. No? petrescu> (prefix len can be larger than 128 by error because encoded on 8bit petrescu> instead of 7 because easier to program). I see. Thank you for your advice. IMHO, I thought that HA must check if it can forward to the mobile network prefix or not(e.g. using ICMP echoreplay) after configuration for forwarding. I recognize that the check using ICMP is not realistic. Regards, -- Noriaki Takamiya From exim@www1.ietf.org Wed Oct 22 12:47:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17265 for ; Wed, 22 Oct 2003 12:47:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACM8Z-0001xl-Jd for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 12:47:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MGl7LC007539 for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 12:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACM8Z-0001xW-CB for nemo-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 12:47:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17232 for ; Wed, 22 Oct 2003 12:46:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACM8X-0007eg-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 12:47:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACM8X-0007ed-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 12:47:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACM8T-0001v3-52; Wed, 22 Oct 2003 12:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACM7o-0001pt-3j for nemo@optimus.ietf.org; Wed, 22 Oct 2003 12:46:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17191 for ; Wed, 22 Oct 2003 12:46:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACM7k-0007eC-00 for nemo@ietf.org; Wed, 22 Oct 2003 12:46:17 -0400 Received: from mail1.ics.ntts.co.jp ([202.32.24.45]) by ietf-mx with esmtp (Exim 4.12) id 1ACM7j-0007e8-00 for nemo@ietf.org; Wed, 22 Oct 2003 12:46:16 -0400 Received: from mail26.silk.ntts.co.jp by mail1.ics.ntts.co.jp (8.12.10/3.7W-NTTSOFT-SUR2.0) id h9MGkDSZ018970 for ; Thu, 23 Oct 2003 01:46:13 +0900 (JST) (envelope-from takamiya@po.ntts.co.jp) Received: from daemon.inl.ntts.co.jp by mail26.silk.ntts.co.jp (8.11.7/3.7W-silk-4.6) id h9MGkCG10609 for ; Thu, 23 Oct 2003 01:46:12 +0900 (JST) (envelope-from takamiya@po.ntts.co.jp) Received: (qmail 58007 invoked by alias); 23 Oct 2003 01:46:12 +0900 Received: (qmail 57992 invoked from network); 23 Oct 2003 01:46:12 +0900 Received: from localhost by localhost with SMTP; 23 Oct 2003 01:46:12 +0900 Date: Thu, 23 Oct 2003 01:46:12 +0900 (JST) Message-Id: <20031023.014612.607960534.takamiya@po.ntts.co.jp> To: petrescu@nal.motlabs.com Cc: nemo@ietf.org Subject: Re: [nemo] About BA status 141 From: Noriaki Takamiya In-Reply-To: <3F96A4AA.5000105@nal.motlabs.com> References: <20031022.185854.846933446.takamiya@po.ntts.co.jp> <3F96A4AA.5000105@nal.motlabs.com> X-Face: +<)&j!Ce24nM@a.\f6TA,]^9Q76[_QN_[QR-(bT&>b40Oo[:`R(>b7!b-|q5k&.8CO[_Oh_ !9Nk0rikK70~?|08EFH|:]iF6pwPlnfEn-wo-voY:rP?%7p%cxjnbf'hglO'se&QwZN7/RVX!U7*P% cTV('HfHp+?g1+hx7\+J.W]G zYWv%LsDc X-Mailer: Mew version 3.3 on XEmacs 21.4.13 (Rational FORTRAN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, >> Wed, 22 Oct 2003 17:39:22 +0200 >> [Subject: Re: [nemo] About BA status 141] >> Alexandru Petrescu wrote... petrescu> I guess so. For example if a similar entry already exists in the table, petrescu> or if the prefix is larger than 128. No? petrescu> (prefix len can be larger than 128 by error because encoded on 8bit petrescu> instead of 7 because easier to program). I see. Thank you for your advice. IMHO, I thought that HA must check if it can forward to the mobile network prefix or not(e.g. using ICMP echoreplay) after configuration for forwarding. I recognize that the check using ICMP is not realistic. Regards, -- Noriaki Takamiya From nemo-admin@ietf.org Wed Oct 22 12:49:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17375 for ; Wed, 22 Oct 2003 12:49:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMAP-0002PP-MU; Wed, 22 Oct 2003 12:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMAG-0002O4-Dd for nemo@optimus.ietf.org; Wed, 22 Oct 2003 12:48:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17343 for ; Wed, 22 Oct 2003 12:48:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMAE-0007gi-00 for nemo@ietf.org; Wed, 22 Oct 2003 12:48:50 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1ACMAD-0007gf-00 for nemo@ietf.org; Wed, 22 Oct 2003 12:48:50 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id h9MGkPxh023191; Wed, 22 Oct 2003 09:46:25 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h9MGkvee032260; Wed, 22 Oct 2003 11:46:58 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 91A082EC95; Wed, 22 Oct 2003 18:46:56 +0200 (CEST) Message-ID: <3F96B480.2040906@nal.motlabs.com> Date: Wed, 22 Oct 2003 18:46:56 +0200 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: jafy@etri.re.kr Cc: nemo@ietf.org References: <000c01c392e5$dcd7c480$ae70fe81@jafywinxp> In-Reply-To: <000c01c392e5$dcd7c480$ae70fe81@jafywinxp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: NEMO or MANET? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit HyunWook Cha wrote: > Hi Alex, I apologize that my second comment on A-C-B seems to be > repeated. Please ignore that. And, I modify my first comment. Since > an MR which does not have global prefixes requests prefix delegation, As long as manets or partitions (clusters?) of manets stay separated from the Internet, they don't quite need global prefixes, no? > MR_B delegates its prefix to MR_A in case A-(B-C) that I mentioned > below. How about this case where one group(cluster or partion in > terms of MANET) of mobile networks is connected to another group of > mobile netwroks? (A->B)-(C->D) I think prefix delegation should be > extended to propagate route information for prefix of one group to > other group although prefix delegation is not needed. I would say that before extending prefix delegation to propagate groups of prefixes in the form of routing information, let's see first how prefix delegation works in simple cases, draft-droms-nemo-dhcpv6-pd-00.txt > If so, why don't you use MANET routing protcols? Yes, using MANET routing protocols when there are many manets or many manet partitions makes a lot of sense. I am not knowledgeable enough on the manet protocols to know whether any does address assignment (or address autoconfiguration), and if not, maybe manet protocols couldl be extended to do that too with DHCP. Thanks for comments, Alex GBU From exim@www1.ietf.org Wed Oct 22 12:49:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17390 for ; Wed, 22 Oct 2003 12:49:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMAT-0002Qp-0t for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 12:49:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MGn4Nb009325 for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 12:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMAS-0002QK-R3 for nemo-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 12:49:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17347 for ; Wed, 22 Oct 2003 12:48:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMAR-0007gt-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 12:49:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACMAQ-0007gq-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 12:49:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMAP-0002PP-MU; Wed, 22 Oct 2003 12:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMAG-0002O4-Dd for nemo@optimus.ietf.org; Wed, 22 Oct 2003 12:48:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17343 for ; Wed, 22 Oct 2003 12:48:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMAE-0007gi-00 for nemo@ietf.org; Wed, 22 Oct 2003 12:48:50 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1ACMAD-0007gf-00 for nemo@ietf.org; Wed, 22 Oct 2003 12:48:50 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id h9MGkPxh023191; Wed, 22 Oct 2003 09:46:25 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h9MGkvee032260; Wed, 22 Oct 2003 11:46:58 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 91A082EC95; Wed, 22 Oct 2003 18:46:56 +0200 (CEST) Message-ID: <3F96B480.2040906@nal.motlabs.com> Date: Wed, 22 Oct 2003 18:46:56 +0200 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: jafy@etri.re.kr Cc: nemo@ietf.org References: <000c01c392e5$dcd7c480$ae70fe81@jafywinxp> In-Reply-To: <000c01c392e5$dcd7c480$ae70fe81@jafywinxp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: NEMO or MANET? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit HyunWook Cha wrote: > Hi Alex, I apologize that my second comment on A-C-B seems to be > repeated. Please ignore that. And, I modify my first comment. Since > an MR which does not have global prefixes requests prefix delegation, As long as manets or partitions (clusters?) of manets stay separated from the Internet, they don't quite need global prefixes, no? > MR_B delegates its prefix to MR_A in case A-(B-C) that I mentioned > below. How about this case where one group(cluster or partion in > terms of MANET) of mobile networks is connected to another group of > mobile netwroks? (A->B)-(C->D) I think prefix delegation should be > extended to propagate route information for prefix of one group to > other group although prefix delegation is not needed. I would say that before extending prefix delegation to propagate groups of prefixes in the form of routing information, let's see first how prefix delegation works in simple cases, draft-droms-nemo-dhcpv6-pd-00.txt > If so, why don't you use MANET routing protcols? Yes, using MANET routing protocols when there are many manets or many manet partitions makes a lot of sense. I am not knowledgeable enough on the manet protocols to know whether any does address assignment (or address autoconfiguration), and if not, maybe manet protocols couldl be extended to do that too with DHCP. Thanks for comments, Alex GBU From nemo-admin@ietf.org Wed Oct 22 12:56:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17575 for ; Wed, 22 Oct 2003 12:56:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMHB-0003MA-Io; Wed, 22 Oct 2003 12:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMGQ-0003Hm-7G for nemo@optimus.ietf.org; Wed, 22 Oct 2003 12:55:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17561 for ; Wed, 22 Oct 2003 12:55:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMGO-0007kd-00 for nemo@ietf.org; Wed, 22 Oct 2003 12:55:12 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1ACMGI-0007ka-00 for nemo@ietf.org; Wed, 22 Oct 2003 12:55:06 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h9MGsxI0012641; Wed, 22 Oct 2003 09:55:05 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h9MGstvM018455; Wed, 22 Oct 2003 11:54:56 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 3A31C2EC95; Wed, 22 Oct 2003 18:54:55 +0200 (CEST) Message-ID: <3F96B65E.4040006@nal.motlabs.com> Date: Wed, 22 Oct 2003 18:54:54 +0200 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: Noriaki Takamiya Cc: nemo@ietf.org Subject: Re: [nemo] About BA status 141 References: <20031022.185854.846933446.takamiya@po.ntts.co.jp> <3F96A4AA.5000105@nal.motlabs.com> <20031023.014612.607960534.takamiya@po.ntts.co.jp> In-Reply-To: <20031023.014612.607960534.takamiya@po.ntts.co.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Noriaki Takamiya wrote: > IMHO, I thought that HA must check if it can forward to the mobile > network prefix or not(e.g. using ICMP echoreplay) after > configuration for forwarding. > > I recognize that the check using ICMP is not realistic. Of course it depends. The idea of checking connectivity with echo request/reply comes to mind immediately when thinking about reachability. For example RR tests of Mobile IPv6 are a sort of just that: check routability between CN, MN and HA. On another hand, a very early version of draft-kniveton-mobrtr had a sort of check echo req/rep too from HA to MR, IIRC. Then it was no longer proposed, probably because being an ICMP message does not give real reliable indication ("reply" can be lost now and not 10s later). With failing Mobile IPv6 RR tests, there's a backup: use bidir tunnel instead of using RO. With failing req/rep from HA to MR there is no backup, HA simply informs the MR 141. Or something like that... Alex GBU From exim@www1.ietf.org Wed Oct 22 12:56:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17590 for ; Wed, 22 Oct 2003 12:56:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMHD-0003Nf-D1 for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 12:56:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MGu3C3012989 for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 12:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMHD-0003NQ-8d for nemo-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 12:56:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17570 for ; Wed, 22 Oct 2003 12:55:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMHB-0007kv-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 12:56:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACMHB-0007ks-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 12:56:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMHB-0003MA-Io; Wed, 22 Oct 2003 12:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMGQ-0003Hm-7G for nemo@optimus.ietf.org; Wed, 22 Oct 2003 12:55:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17561 for ; Wed, 22 Oct 2003 12:55:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMGO-0007kd-00 for nemo@ietf.org; Wed, 22 Oct 2003 12:55:12 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1ACMGI-0007ka-00 for nemo@ietf.org; Wed, 22 Oct 2003 12:55:06 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h9MGsxI0012641; Wed, 22 Oct 2003 09:55:05 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h9MGstvM018455; Wed, 22 Oct 2003 11:54:56 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 3A31C2EC95; Wed, 22 Oct 2003 18:54:55 +0200 (CEST) Message-ID: <3F96B65E.4040006@nal.motlabs.com> Date: Wed, 22 Oct 2003 18:54:54 +0200 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: Noriaki Takamiya Cc: nemo@ietf.org Subject: Re: [nemo] About BA status 141 References: <20031022.185854.846933446.takamiya@po.ntts.co.jp> <3F96A4AA.5000105@nal.motlabs.com> <20031023.014612.607960534.takamiya@po.ntts.co.jp> In-Reply-To: <20031023.014612.607960534.takamiya@po.ntts.co.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Noriaki Takamiya wrote: > IMHO, I thought that HA must check if it can forward to the mobile > network prefix or not(e.g. using ICMP echoreplay) after > configuration for forwarding. > > I recognize that the check using ICMP is not realistic. Of course it depends. The idea of checking connectivity with echo request/reply comes to mind immediately when thinking about reachability. For example RR tests of Mobile IPv6 are a sort of just that: check routability between CN, MN and HA. On another hand, a very early version of draft-kniveton-mobrtr had a sort of check echo req/rep too from HA to MR, IIRC. Then it was no longer proposed, probably because being an ICMP message does not give real reliable indication ("reply" can be lost now and not 10s later). With failing Mobile IPv6 RR tests, there's a backup: use bidir tunnel instead of using RO. With failing req/rep from HA to MR there is no backup, HA simply informs the MR 141. Or something like that... Alex GBU From nemo-admin@ietf.org Wed Oct 22 13:25:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18545 for ; Wed, 22 Oct 2003 13:25:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMjG-0006hL-2G; Wed, 22 Oct 2003 13:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMj5-0006gX-5q for nemo@optimus.ietf.org; Wed, 22 Oct 2003 13:24:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18520 for ; Wed, 22 Oct 2003 13:24:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMj3-0000DD-00 for nemo@ietf.org; Wed, 22 Oct 2003 13:24:49 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ACMj2-0000D4-00 for nemo@ietf.org; Wed, 22 Oct 2003 13:24:48 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9MHO7I08548; Wed, 22 Oct 2003 10:24:07 -0700 X-mProtect: <200310221724> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFAkcyj; Wed, 22 Oct 2003 10:24:05 PDT Message-ID: <3F96BDB4.1030703@iprg.nokia.com> Date: Wed, 22 Oct 2003 10:26:12 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@ietf.org, Ryuji Wakikawa , "Pascal Thubert (pthubert)" Subject: Re: [nemo] Comments on draft-wakikawa-mip6-nemo-haha-00.txt References: <3F96AEB9.4030709@nal.motlabs.com> In-Reply-To: <3F96AEB9.4030709@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Hello to authors of draft-wakikawa-mip6-nemo-haha-00.txt available at > http://www.mobilenetworks.org/nemo/drafts/draft-wakikawa-mip6-nemo-haha-00.txt > > > Here are some comments on the draft. Please take them as comments only. > > The whole idea of having an inter-HA protocol (HAHA) for HA's _not_ on > the same link seems valuable from several standpoints, most importantly > for redundancy. The presentation of the mechanisms makes sense and > covers a large set of scenarios; thanks for writing it. > > However, I have doubts with respect to motivating the use of these > mechanisms in order to help with RO; and also doubting about where to > target these mechanisms: MIP6 or NEMO. it is definitely not intended to be a substitute for Route Optimization. we will add an explicit statement to that effect in the next version of the draft. >> Multiple Home Agents could be located on different links and still >> serve the same home prefix. > > > I think that if they are located on different links (IP subnets) then > they will have difficulty to advertise reachability to a same Home > Address (or same MNP). If these home links are relatively close to each > other, as to form an IGP area, then adertising reachability towards the > same Home Address (or MNP) is indeed feasible, and OSPF does that. If > however these home links are in different domains (separated by e.g. > BGP) then I doubt these HA's can effectively advertise reachability of > the same Home Address (or MNP). No? this is an open issue. I believe that even if the Home Agents are on different links serving the same set of home prefixes, they still have to belong to the same Autonomous System. they are not in different domains. Pascal might have something different to say here. > >> When multiple Home Agents are configured at different links, each home >> agent is expected to know the other Home Agents beforehand and >> establishes Security Association with them for a secure path towards >> the other home agent. > > > I wonder how this could be done, to have a set of HA's scattered in the > Internet and have SA's among them, do you have a specific tool in mind? thats easy. they are part of the same domain. they can just run IKE to negotiate the keys. or some admin can manually setup IPsec SAs. >> When a Home Agent receives a Binding Update from a Mobile Router and >> processes the Binding Update successfully, it enables route >> distribution for the mobile network prefixes. > > > So HA receives a completely unknown MNP in a BU and redistributes it to > the Internet? How is HA confident about MR not attacking the Internet? HA has to verify if the Mobile Router is authorized for a particular MNP. I prefer doing this check always. >> On the other hand, if the Home Agent does not enable forwarding for >> the Home Address and the mobile network prefixes, it tunnels >> intercepted packets to the primary Home Agent (Fig 2) first. > > > If the HA does not enable forwarding for that Home Address, then how it > obtained packets addressed to that Home Address in first place? I agree > that if HA obtains those packets, it then forwards them to the primary > HA, and that's a good idea, but how does it "intercept" those packets in > first place if it does not forward for that Home Address? it just said "if the Home Agent does not enable forwarding...." it didnt say "the Home Agent does not advertise reachability for the MNP...". > >> One specific advantage of not relying on a Home Link for HAHA >> communication is that for a large configuration, the Home Agents can >> be organized hierarchically and distributed geographically, as a set >> of local clusters linked together to form a global Home Network. > > > I think this explanation is very important to motivate the need of HAHA > previously described. I think this picture should be given somewhere at > the beginning of the document, instead of at the appendix. > > Still, if we consider a very wide-area network (inter-continental) as > described above, then HAHA can work only if the longest links between > the clusters are L2 links (say ATM or sattelite or fiber, your choice), what about IP-in-IP tunnels between the HA clusters? Vijay From exim@www1.ietf.org Wed Oct 22 13:25:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18562 for ; Wed, 22 Oct 2003 13:25:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMjP-0006it-H8 for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 13:25:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MHPBJE025837 for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 13:25:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMjP-0006ie-CH for nemo-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 13:25:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18539 for ; Wed, 22 Oct 2003 13:24:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMjL-0000Dm-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 13:25:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACMjL-0000Dj-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 13:25:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMjG-0006hL-2G; Wed, 22 Oct 2003 13:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMj5-0006gX-5q for nemo@optimus.ietf.org; Wed, 22 Oct 2003 13:24:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18520 for ; Wed, 22 Oct 2003 13:24:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMj3-0000DD-00 for nemo@ietf.org; Wed, 22 Oct 2003 13:24:49 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ACMj2-0000D4-00 for nemo@ietf.org; Wed, 22 Oct 2003 13:24:48 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9MHO7I08548; Wed, 22 Oct 2003 10:24:07 -0700 X-mProtect: <200310221724> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFAkcyj; Wed, 22 Oct 2003 10:24:05 PDT Message-ID: <3F96BDB4.1030703@iprg.nokia.com> Date: Wed, 22 Oct 2003 10:26:12 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@ietf.org, Ryuji Wakikawa , "Pascal Thubert (pthubert)" Subject: Re: [nemo] Comments on draft-wakikawa-mip6-nemo-haha-00.txt References: <3F96AEB9.4030709@nal.motlabs.com> In-Reply-To: <3F96AEB9.4030709@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Hello to authors of draft-wakikawa-mip6-nemo-haha-00.txt available at > http://www.mobilenetworks.org/nemo/drafts/draft-wakikawa-mip6-nemo-haha-00.txt > > > Here are some comments on the draft. Please take them as comments only. > > The whole idea of having an inter-HA protocol (HAHA) for HA's _not_ on > the same link seems valuable from several standpoints, most importantly > for redundancy. The presentation of the mechanisms makes sense and > covers a large set of scenarios; thanks for writing it. > > However, I have doubts with respect to motivating the use of these > mechanisms in order to help with RO; and also doubting about where to > target these mechanisms: MIP6 or NEMO. it is definitely not intended to be a substitute for Route Optimization. we will add an explicit statement to that effect in the next version of the draft. >> Multiple Home Agents could be located on different links and still >> serve the same home prefix. > > > I think that if they are located on different links (IP subnets) then > they will have difficulty to advertise reachability to a same Home > Address (or same MNP). If these home links are relatively close to each > other, as to form an IGP area, then adertising reachability towards the > same Home Address (or MNP) is indeed feasible, and OSPF does that. If > however these home links are in different domains (separated by e.g. > BGP) then I doubt these HA's can effectively advertise reachability of > the same Home Address (or MNP). No? this is an open issue. I believe that even if the Home Agents are on different links serving the same set of home prefixes, they still have to belong to the same Autonomous System. they are not in different domains. Pascal might have something different to say here. > >> When multiple Home Agents are configured at different links, each home >> agent is expected to know the other Home Agents beforehand and >> establishes Security Association with them for a secure path towards >> the other home agent. > > > I wonder how this could be done, to have a set of HA's scattered in the > Internet and have SA's among them, do you have a specific tool in mind? thats easy. they are part of the same domain. they can just run IKE to negotiate the keys. or some admin can manually setup IPsec SAs. >> When a Home Agent receives a Binding Update from a Mobile Router and >> processes the Binding Update successfully, it enables route >> distribution for the mobile network prefixes. > > > So HA receives a completely unknown MNP in a BU and redistributes it to > the Internet? How is HA confident about MR not attacking the Internet? HA has to verify if the Mobile Router is authorized for a particular MNP. I prefer doing this check always. >> On the other hand, if the Home Agent does not enable forwarding for >> the Home Address and the mobile network prefixes, it tunnels >> intercepted packets to the primary Home Agent (Fig 2) first. > > > If the HA does not enable forwarding for that Home Address, then how it > obtained packets addressed to that Home Address in first place? I agree > that if HA obtains those packets, it then forwards them to the primary > HA, and that's a good idea, but how does it "intercept" those packets in > first place if it does not forward for that Home Address? it just said "if the Home Agent does not enable forwarding...." it didnt say "the Home Agent does not advertise reachability for the MNP...". > >> One specific advantage of not relying on a Home Link for HAHA >> communication is that for a large configuration, the Home Agents can >> be organized hierarchically and distributed geographically, as a set >> of local clusters linked together to form a global Home Network. > > > I think this explanation is very important to motivate the need of HAHA > previously described. I think this picture should be given somewhere at > the beginning of the document, instead of at the appendix. > > Still, if we consider a very wide-area network (inter-continental) as > described above, then HAHA can work only if the longest links between > the clusters are L2 links (say ATM or sattelite or fiber, your choice), what about IP-in-IP tunnels between the HA clusters? Vijay From nemo-admin@ietf.org Wed Oct 22 13:33:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18752 for ; Wed, 22 Oct 2003 13:33:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMqy-0007R1-Q2; Wed, 22 Oct 2003 13:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMqZ-0007On-G0 for nemo@optimus.ietf.org; Wed, 22 Oct 2003 13:32:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18743 for ; Wed, 22 Oct 2003 13:32:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMqX-0000Hs-00 for nemo@ietf.org; Wed, 22 Oct 2003 13:32:33 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1ACMqW-0000Hp-00 for nemo@ietf.org; Wed, 22 Oct 2003 13:32:32 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h9MHWQqD002088; Wed, 22 Oct 2003 10:32:26 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h9MHWLVu004359; Wed, 22 Oct 2003 12:32:22 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 12DA22EC95; Wed, 22 Oct 2003 19:32:22 +0200 (CEST) Message-ID: <3F96BF25.2020808@nal.motlabs.com> Date: Wed, 22 Oct 2003 19:32:21 +0200 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: Ralph Droms Cc: IETF NEMO WG X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Comments on draft-droms-nemo-dhcpv6-pd-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Ralph, I have some comments with respect to draft-droms-nemo-dhcpv6-pd-00.txt where it is explained how to use DHCPv6PD between MR and its HA, in a NEMO (Network Mobility) context. > The network mobility requirements document [7] defines a solution for > mobile IPv6 networks based on the mobile IPv6 protocol [4]. In fact, the requirements document 7 defines just that, and it prefigures the form of a solution, yes. And there is a WG item basic support solution for Mobile IPv6 moving networks draft-ietf-nemo-basic-support-01.txt > The requirements for basic network mobility support [8] [8] draft-wakikawa will probably be outdated, but there is the WG item mentioned above. That does not have reqs, so it would be sufficient to cite 7 instead of 8. > The HA (acting as the DR) is provisioned with prefixes to be assigned > using any of the prefix assignment mechanisms described in the > DHCPv6PD specifications. So the HA will have forwarding information (routes?) in its forwarding information table (routing table?) with entries for each one of these prefixes to be delegated, and pointing towards the MR's Home Address, right? Maybe those routes will be added at HA only when HA receives a DHCP Request and only if it replies positively? In this case, let's look at the overall picture when MR is away from home and bootstraps and does not have a Mobile Network Prefix (MNP) allocated. 1- it sends a DHCP request through the tunnel to obtain prefix MNP 2- HA receives this request, allocates one MNP and adds entry in routing table. 3- HA sends positive reply to MR and sends it the MNP too. 4- MR sends NEMO BU to HA informing it about this prefix. 5- HA sends back a NEMO Binding Acknowldegement to MR. It is obvious that messages 4 and 5 are not absolutely needed for forwarding to work if the message 1 contained some optional bits saying that this is an MR away from home. > Other updates to the HA data structures required as a side effect of > prefix delegation are specified by the particular network mobility > protocol. For example, in the case of "Basic Network Mobility > Support" [8], the HA would add an entry in its binding cache > registering the delegated prefix to the MR to which the prefix was > delegated. In the current nemo basic spec there are actually three ways in which HA structures are modified: implicit (the prefix is not in the BU, but is present in the rHA outing table), "explicit network" (the prefix is in the BU) and "explicit prefix len" (where only the prefix length is sent, to be applied to the HoA of the address of MR's interface connecting to the moving network; its egress connects to the home link). So, I guess that if MR uses implicit mode to update BC of HA, then HA uses whatever prefix information it has in its routing table. Whether that information comes from DHCPv6PD or from a routing protocol like OSPF, MR does not care. But, if MR uses explicit network mode to inform its HA about an MNP to be put in its routing table (or its BC) then that MNP MUST NOt conflict with the MNP assigned by DHCPv6PD. Same contention must be avoided if "explicit prefix length" mode is used. What do you think? Alex GBU From exim@www1.ietf.org Wed Oct 22 13:33:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18768 for ; Wed, 22 Oct 2003 13:33:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMr2-0007SP-ME for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 13:33:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MHX4W0028659 for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 13:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMr2-0007SA-HO for nemo-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 13:33:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18749 for ; Wed, 22 Oct 2003 13:32:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMr0-0000I3-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 13:33:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACMr0-0000I0-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 13:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMqy-0007R1-Q2; Wed, 22 Oct 2003 13:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMqZ-0007On-G0 for nemo@optimus.ietf.org; Wed, 22 Oct 2003 13:32:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18743 for ; Wed, 22 Oct 2003 13:32:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMqX-0000Hs-00 for nemo@ietf.org; Wed, 22 Oct 2003 13:32:33 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1ACMqW-0000Hp-00 for nemo@ietf.org; Wed, 22 Oct 2003 13:32:32 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h9MHWQqD002088; Wed, 22 Oct 2003 10:32:26 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h9MHWLVu004359; Wed, 22 Oct 2003 12:32:22 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 12DA22EC95; Wed, 22 Oct 2003 19:32:22 +0200 (CEST) Message-ID: <3F96BF25.2020808@nal.motlabs.com> Date: Wed, 22 Oct 2003 19:32:21 +0200 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: Ralph Droms Cc: IETF NEMO WG X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Comments on draft-droms-nemo-dhcpv6-pd-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Ralph, I have some comments with respect to draft-droms-nemo-dhcpv6-pd-00.txt where it is explained how to use DHCPv6PD between MR and its HA, in a NEMO (Network Mobility) context. > The network mobility requirements document [7] defines a solution for > mobile IPv6 networks based on the mobile IPv6 protocol [4]. In fact, the requirements document 7 defines just that, and it prefigures the form of a solution, yes. And there is a WG item basic support solution for Mobile IPv6 moving networks draft-ietf-nemo-basic-support-01.txt > The requirements for basic network mobility support [8] [8] draft-wakikawa will probably be outdated, but there is the WG item mentioned above. That does not have reqs, so it would be sufficient to cite 7 instead of 8. > The HA (acting as the DR) is provisioned with prefixes to be assigned > using any of the prefix assignment mechanisms described in the > DHCPv6PD specifications. So the HA will have forwarding information (routes?) in its forwarding information table (routing table?) with entries for each one of these prefixes to be delegated, and pointing towards the MR's Home Address, right? Maybe those routes will be added at HA only when HA receives a DHCP Request and only if it replies positively? In this case, let's look at the overall picture when MR is away from home and bootstraps and does not have a Mobile Network Prefix (MNP) allocated. 1- it sends a DHCP request through the tunnel to obtain prefix MNP 2- HA receives this request, allocates one MNP and adds entry in routing table. 3- HA sends positive reply to MR and sends it the MNP too. 4- MR sends NEMO BU to HA informing it about this prefix. 5- HA sends back a NEMO Binding Acknowldegement to MR. It is obvious that messages 4 and 5 are not absolutely needed for forwarding to work if the message 1 contained some optional bits saying that this is an MR away from home. > Other updates to the HA data structures required as a side effect of > prefix delegation are specified by the particular network mobility > protocol. For example, in the case of "Basic Network Mobility > Support" [8], the HA would add an entry in its binding cache > registering the delegated prefix to the MR to which the prefix was > delegated. In the current nemo basic spec there are actually three ways in which HA structures are modified: implicit (the prefix is not in the BU, but is present in the rHA outing table), "explicit network" (the prefix is in the BU) and "explicit prefix len" (where only the prefix length is sent, to be applied to the HoA of the address of MR's interface connecting to the moving network; its egress connects to the home link). So, I guess that if MR uses implicit mode to update BC of HA, then HA uses whatever prefix information it has in its routing table. Whether that information comes from DHCPv6PD or from a routing protocol like OSPF, MR does not care. But, if MR uses explicit network mode to inform its HA about an MNP to be put in its routing table (or its BC) then that MNP MUST NOt conflict with the MNP assigned by DHCPv6PD. Same contention must be avoided if "explicit prefix length" mode is used. What do you think? Alex GBU From nemo-admin@ietf.org Wed Oct 22 13:48:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19439 for ; Wed, 22 Oct 2003 13:48:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACN5U-0001is-OR; Wed, 22 Oct 2003 13:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACN4k-0001bQ-Cj for nemo@optimus.ietf.org; Wed, 22 Oct 2003 13:47:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19415 for ; Wed, 22 Oct 2003 13:47:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACN4i-0000TQ-00 for nemo@ietf.org; Wed, 22 Oct 2003 13:47:12 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 1ACN4h-0000TN-00 for nemo@ietf.org; Wed, 22 Oct 2003 13:47:11 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h9MHl4lg004928; Wed, 22 Oct 2003 10:47:05 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h9MHl1vM030319; Wed, 22 Oct 2003 12:47:01 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 715ED2EC95; Wed, 22 Oct 2003 19:47:00 +0200 (CEST) Message-ID: <3F96C294.8060407@nal.motlabs.com> Date: Wed, 22 Oct 2003 19:47:00 +0200 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: Vijay Devarapalli Cc: nemo@ietf.org, Ryuji Wakikawa , "Pascal Thubert (pthubert)" Subject: Re: [nemo] Comments on draft-wakikawa-mip6-nemo-haha-00.txt References: <3F96AEB9.4030709@nal.motlabs.com> <3F96BDB4.1030703@iprg.nokia.com> In-Reply-To: <3F96BDB4.1030703@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> However, I have doubts with respect to motivating the use of these >> mechanisms in order to help with RO; and also doubting about where >> to target these mechanisms: MIP6 or NEMO. > > it is definitely not intended to be a substitute for Route > Optimization. we will add an explicit statement to that effect in the > next version of the draft. Ok, so I retain as problem only "tunnelling overhead on every packet could be reduced to a much shorter path in the Internet". >> I think that if they are located on different links (IP subnets) >> then they will have difficulty to advertise reachability to a same >> Home Address (or same MNP). If these home links are relatively >> close to each other, as to form an IGP area, then adertising >> reachability towards the same Home Address (or MNP) is indeed >> feasible, and OSPF does that. If however these home links are in >> different domains (separated by e.g. BGP) then I doubt these HA's >> can effectively advertise reachability of the same Home Address (or >> MNP). No? > > > this is an open issue. Well said. > I believe that even if the Home Agents are on different links serving > the same set of home prefixes, they still have to belong to the same > Autonomous System. they are not in different domains. Pascal might > have something different to say here. Ok. >> I wonder how this could be done, to have a set of HA's scattered in >> the Internet and have SA's among them, do you have a specific tool >> in mind? > > thats easy. they are part of the same domain. they can just run IKE > to negotiate the keys. or some admin can manually setup IPsec SAs. Ok, so again you rely on HA's being in the same domain; and if yes then IKE could be used. >>> On the other hand, if the Home Agent does not enable forwarding >>> for the Home Address and the mobile network prefixes, it tunnels >>> intercepted packets to the primary Home Agent (Fig 2) first. >> >> If the HA does not enable forwarding for that Home Address, then >> how it obtained packets addressed to that Home Address in first >> place? I agree that if HA obtains those packets, it then forwards >> them to the primary HA, and that's a good idea, but how does it >> "intercept" those packets in first place if it does not forward for >> that Home Address? > > > it just said "if the Home Agent does not enable forwarding...." it > didnt say "the Home Agent does not advertise reachability for the > MNP...". It said "it does not enable forwarding for the Home Address", no MNP. Forwarding for a Home Address can only happen if there is forwarding for some prefix, or host-based route, but it is still forwarding for a Home Address. >>> One specific advantage of not relying on a Home Link for HAHA >>> communication is that for a large configuration, the Home Agents >>> can be organized hierarchically and distributed geographically, >>> as a set of local clusters linked together to form a global Home >>> Network. >> >> >> >> I think this explanation is very important to motivate the need of >> HAHA previously described. I think this picture should be given >> somewhere at the beginning of the document, instead of at the >> appendix. >> >> Still, if we consider a very wide-area network (inter-continental) >> as described above, then HAHA can work only if the longest links >> between the clusters are L2 links (say ATM or sattelite or fiber, >> your choice), > > > what about IP-in-IP tunnels between the HA clusters? Coming back to the first statement, which says that this HAHA is not about RO, it is implicitely about reducing the length of the path on which packets travel encapsulated. What? There is always a level of encapsulation between HA clusters with IP-in-IP tunnels? So, even if there is no tunnel between MH and its primary HA (there is only encapsulation between MH and its local HA) but then there is a level of encapsulation between the HA's anyways, so what is it gained? Alex GBU From exim@www1.ietf.org Wed Oct 22 13:48:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19460 for ; Wed, 22 Oct 2003 13:48:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACN5c-0001kK-KR for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 13:48:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MHm8Rl006706 for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 13:48:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACN5b-0001k4-1p for nemo-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 13:48:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19434 for ; Wed, 22 Oct 2003 13:47:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACN5Y-0000Tp-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 13:48:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACN5Y-0000Tm-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 13:48:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACN5U-0001is-OR; Wed, 22 Oct 2003 13:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACN4k-0001bQ-Cj for nemo@optimus.ietf.org; Wed, 22 Oct 2003 13:47:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19415 for ; Wed, 22 Oct 2003 13:47:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACN4i-0000TQ-00 for nemo@ietf.org; Wed, 22 Oct 2003 13:47:12 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 1ACN4h-0000TN-00 for nemo@ietf.org; Wed, 22 Oct 2003 13:47:11 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h9MHl4lg004928; Wed, 22 Oct 2003 10:47:05 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h9MHl1vM030319; Wed, 22 Oct 2003 12:47:01 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 715ED2EC95; Wed, 22 Oct 2003 19:47:00 +0200 (CEST) Message-ID: <3F96C294.8060407@nal.motlabs.com> Date: Wed, 22 Oct 2003 19:47:00 +0200 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: Vijay Devarapalli Cc: nemo@ietf.org, Ryuji Wakikawa , "Pascal Thubert (pthubert)" Subject: Re: [nemo] Comments on draft-wakikawa-mip6-nemo-haha-00.txt References: <3F96AEB9.4030709@nal.motlabs.com> <3F96BDB4.1030703@iprg.nokia.com> In-Reply-To: <3F96BDB4.1030703@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> However, I have doubts with respect to motivating the use of these >> mechanisms in order to help with RO; and also doubting about where >> to target these mechanisms: MIP6 or NEMO. > > it is definitely not intended to be a substitute for Route > Optimization. we will add an explicit statement to that effect in the > next version of the draft. Ok, so I retain as problem only "tunnelling overhead on every packet could be reduced to a much shorter path in the Internet". >> I think that if they are located on different links (IP subnets) >> then they will have difficulty to advertise reachability to a same >> Home Address (or same MNP). If these home links are relatively >> close to each other, as to form an IGP area, then adertising >> reachability towards the same Home Address (or MNP) is indeed >> feasible, and OSPF does that. If however these home links are in >> different domains (separated by e.g. BGP) then I doubt these HA's >> can effectively advertise reachability of the same Home Address (or >> MNP). No? > > > this is an open issue. Well said. > I believe that even if the Home Agents are on different links serving > the same set of home prefixes, they still have to belong to the same > Autonomous System. they are not in different domains. Pascal might > have something different to say here. Ok. >> I wonder how this could be done, to have a set of HA's scattered in >> the Internet and have SA's among them, do you have a specific tool >> in mind? > > thats easy. they are part of the same domain. they can just run IKE > to negotiate the keys. or some admin can manually setup IPsec SAs. Ok, so again you rely on HA's being in the same domain; and if yes then IKE could be used. >>> On the other hand, if the Home Agent does not enable forwarding >>> for the Home Address and the mobile network prefixes, it tunnels >>> intercepted packets to the primary Home Agent (Fig 2) first. >> >> If the HA does not enable forwarding for that Home Address, then >> how it obtained packets addressed to that Home Address in first >> place? I agree that if HA obtains those packets, it then forwards >> them to the primary HA, and that's a good idea, but how does it >> "intercept" those packets in first place if it does not forward for >> that Home Address? > > > it just said "if the Home Agent does not enable forwarding...." it > didnt say "the Home Agent does not advertise reachability for the > MNP...". It said "it does not enable forwarding for the Home Address", no MNP. Forwarding for a Home Address can only happen if there is forwarding for some prefix, or host-based route, but it is still forwarding for a Home Address. >>> One specific advantage of not relying on a Home Link for HAHA >>> communication is that for a large configuration, the Home Agents >>> can be organized hierarchically and distributed geographically, >>> as a set of local clusters linked together to form a global Home >>> Network. >> >> >> >> I think this explanation is very important to motivate the need of >> HAHA previously described. I think this picture should be given >> somewhere at the beginning of the document, instead of at the >> appendix. >> >> Still, if we consider a very wide-area network (inter-continental) >> as described above, then HAHA can work only if the longest links >> between the clusters are L2 links (say ATM or sattelite or fiber, >> your choice), > > > what about IP-in-IP tunnels between the HA clusters? Coming back to the first statement, which says that this HAHA is not about RO, it is implicitely about reducing the length of the path on which packets travel encapsulated. What? There is always a level of encapsulation between HA clusters with IP-in-IP tunnels? So, even if there is no tunnel between MH and its primary HA (there is only encapsulation between MH and its local HA) but then there is a level of encapsulation between the HA's anyways, so what is it gained? Alex GBU From nemo-admin@ietf.org Wed Oct 22 14:01:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20051 for ; Wed, 22 Oct 2003 14:01:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNI6-0003Nj-FZ; Wed, 22 Oct 2003 14:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNHN-0003Fj-FM for nemo@optimus.ietf.org; Wed, 22 Oct 2003 14:00:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19936 for ; Wed, 22 Oct 2003 14:00:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACNHK-0000fk-00 for nemo@ietf.org; Wed, 22 Oct 2003 14:00:15 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ACNHK-0000f3-00 for nemo@ietf.org; Wed, 22 Oct 2003 14:00:14 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9MHxaW09403; Wed, 22 Oct 2003 10:59:36 -0700 X-mProtect: <200310221759> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdMHjLrK; Wed, 22 Oct 2003 10:59:34 PDT Message-ID: <3F96C604.9010409@iprg.nokia.com> Date: Wed, 22 Oct 2003 11:01:40 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@ietf.org, Ryuji Wakikawa , "Pascal Thubert (pthubert)" Subject: Re: [nemo] Comments on draft-wakikawa-mip6-nemo-haha-00.txt References: <3F96AEB9.4030709@nal.motlabs.com> <3F96BDB4.1030703@iprg.nokia.com> <3F96C294.8060407@nal.motlabs.com> In-Reply-To: <3F96C294.8060407@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: >>>> On the other hand, if the Home Agent does not enable forwarding for >>>> the Home Address and the mobile network prefixes, it tunnels >>>> intercepted packets to the primary Home Agent (Fig 2) first. >>> >>> >>> If the HA does not enable forwarding for that Home Address, then how >>> it obtained packets addressed to that Home Address in first place? I >>> agree that if HA obtains those packets, it then forwards >>> them to the primary HA, and that's a good idea, but how does it >>> "intercept" those packets in first place if it does not forward for >>> that Home Address? >> >> >> >> it just said "if the Home Agent does not enable forwarding...." it >> didnt say "the Home Agent does not advertise reachability for the >> MNP...". > > > It said "it does not enable forwarding for the Home Address", no MNP. > Forwarding for a Home Address can only happen if there is forwarding for > some prefix, or host-based route, but it is still forwarding for a Home > Address. needs to be fixed. but I guess you understood what it intends to say. each Home Agent can either tunnel the packets directly to the Mobile Router's current point of attachment or to the primary HA. >>> I think this explanation is very important to motivate the need of >>> HAHA previously described. I think this picture should be given >>> somewhere at the beginning of the document, instead of at the appendix. >>> >>> Still, if we consider a very wide-area network (inter-continental) >>> as described above, then HAHA can work only if the longest links >>> between the clusters are L2 links (say ATM or sattelite or fiber, >>> your choice), >> >> >> >> what about IP-in-IP tunnels between the HA clusters? > > > Coming back to the first statement, which says that this HAHA is not > about RO, it is implicitely about reducing the length of the path on > which packets travel encapsulated. What? There is always a level of > encapsulation between HA clusters with IP-in-IP tunnels? > > So, even if there is no tunnel between MH and its primary HA (there is > only encapsulation between MH and its local HA) but then there is a > level of encapsulation between the HA's anyways, so what is it gained? think of a fat pipe between the HA clusters. Vijay From exim@www1.ietf.org Wed Oct 22 14:01:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20067 for ; Wed, 22 Oct 2003 14:01:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNIE-0003Q1-Hk for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 14:01:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MI1AHf013138 for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 14:01:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNIE-0003Pp-B8 for nemo-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 14:01:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20015 for ; Wed, 22 Oct 2003 14:00:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACNIB-0000gl-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 14:01:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACNIB-0000gf-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 14:01:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNI6-0003Nj-FZ; Wed, 22 Oct 2003 14:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNHN-0003Fj-FM for nemo@optimus.ietf.org; Wed, 22 Oct 2003 14:00:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19936 for ; Wed, 22 Oct 2003 14:00:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACNHK-0000fk-00 for nemo@ietf.org; Wed, 22 Oct 2003 14:00:15 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ACNHK-0000f3-00 for nemo@ietf.org; Wed, 22 Oct 2003 14:00:14 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9MHxaW09403; Wed, 22 Oct 2003 10:59:36 -0700 X-mProtect: <200310221759> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdMHjLrK; Wed, 22 Oct 2003 10:59:34 PDT Message-ID: <3F96C604.9010409@iprg.nokia.com> Date: Wed, 22 Oct 2003 11:01:40 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@ietf.org, Ryuji Wakikawa , "Pascal Thubert (pthubert)" Subject: Re: [nemo] Comments on draft-wakikawa-mip6-nemo-haha-00.txt References: <3F96AEB9.4030709@nal.motlabs.com> <3F96BDB4.1030703@iprg.nokia.com> <3F96C294.8060407@nal.motlabs.com> In-Reply-To: <3F96C294.8060407@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: >>>> On the other hand, if the Home Agent does not enable forwarding for >>>> the Home Address and the mobile network prefixes, it tunnels >>>> intercepted packets to the primary Home Agent (Fig 2) first. >>> >>> >>> If the HA does not enable forwarding for that Home Address, then how >>> it obtained packets addressed to that Home Address in first place? I >>> agree that if HA obtains those packets, it then forwards >>> them to the primary HA, and that's a good idea, but how does it >>> "intercept" those packets in first place if it does not forward for >>> that Home Address? >> >> >> >> it just said "if the Home Agent does not enable forwarding...." it >> didnt say "the Home Agent does not advertise reachability for the >> MNP...". > > > It said "it does not enable forwarding for the Home Address", no MNP. > Forwarding for a Home Address can only happen if there is forwarding for > some prefix, or host-based route, but it is still forwarding for a Home > Address. needs to be fixed. but I guess you understood what it intends to say. each Home Agent can either tunnel the packets directly to the Mobile Router's current point of attachment or to the primary HA. >>> I think this explanation is very important to motivate the need of >>> HAHA previously described. I think this picture should be given >>> somewhere at the beginning of the document, instead of at the appendix. >>> >>> Still, if we consider a very wide-area network (inter-continental) >>> as described above, then HAHA can work only if the longest links >>> between the clusters are L2 links (say ATM or sattelite or fiber, >>> your choice), >> >> >> >> what about IP-in-IP tunnels between the HA clusters? > > > Coming back to the first statement, which says that this HAHA is not > about RO, it is implicitely about reducing the length of the path on > which packets travel encapsulated. What? There is always a level of > encapsulation between HA clusters with IP-in-IP tunnels? > > So, even if there is no tunnel between MH and its primary HA (there is > only encapsulation between MH and its local HA) but then there is a > level of encapsulation between the HA's anyways, so what is it gained? think of a fat pipe between the HA clusters. Vijay From nemo-admin@ietf.org Wed Oct 22 14:35:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21265 for ; Wed, 22 Oct 2003 14:35:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNp0-0002e0-5c; Wed, 22 Oct 2003 14:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNoe-0002Vr-0M for nemo@optimus.ietf.org; Wed, 22 Oct 2003 14:34:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21228 for ; Wed, 22 Oct 2003 14:34:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACNob-00010V-00 for nemo@ietf.org; Wed, 22 Oct 2003 14:34:37 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1ACNoa-00010S-00 for nemo@ietf.org; Wed, 22 Oct 2003 14:34:36 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h9MIYVqD018039; Wed, 22 Oct 2003 11:34:31 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h9MIYCaM001173; Wed, 22 Oct 2003 13:34:13 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id D897E2EC95; Wed, 22 Oct 2003 20:34:26 +0200 (CEST) Message-ID: <3F96CDB2.7060208@nal.motlabs.com> Date: Wed, 22 Oct 2003 20:34:26 +0200 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: Vijay Devarapalli Cc: nemo@ietf.org, Ryuji Wakikawa , "Pascal Thubert (pthubert)" Subject: Re: [nemo] Comments on draft-wakikawa-mip6-nemo-haha-00.txt References: <3F96AEB9.4030709@nal.motlabs.com> <3F96BDB4.1030703@iprg.nokia.com> <3F96C294.8060407@nal.motlabs.com> <3F96C604.9010409@iprg.nokia.com> In-Reply-To: <3F96C604.9010409@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> It said "it does not enable forwarding for the Home Address", no MNP. >> Forwarding for a Home Address can only happen if there is forwarding for >> some prefix, or host-based route, but it is still forwarding for a Home >> Address. > > > needs to be fixed. but I guess you understood what it intends > to say. each Home Agent can either tunnel the packets directly > to the Mobile Router's current point of attachment or to the > primary HA. Yes I got that. I reacted on it because it seemed the only point in the text to mention a little bit that HA's will not always advertise reachability of same HoA. But now that you say that it is a common thread of the entire HAHA draft that all HA's are _inside_ a unique small domain (even if spread over a wide geographical area) then I understand it. > think of a fat pipe between the HA clusters. YEs, fat but very distant from the CN. The HAHA domain being very small in terms of IP hops it can not be close to any IP CN of the Internet (even if it _could be_ close geographically). There can surely be no big fat pipe close to all CNs of the Internet, because there are so many. No? Alex GBU From exim@www1.ietf.org Wed Oct 22 14:35:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21267 for ; Wed, 22 Oct 2003 14:35:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNp4-0002fK-Mw for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 14:35:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MIZ6g2010231 for nemo-archive@odin.ietf.org; Wed, 22 Oct 2003 14:35:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNp4-0002ew-Fo for nemo-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 14:35:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21237 for ; Wed, 22 Oct 2003 14:34:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACNp1-00010m-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 14:35:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACNp1-00010j-00 for nemo-web-archive@ietf.org; Wed, 22 Oct 2003 14:35:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNp0-0002e0-5c; Wed, 22 Oct 2003 14:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNoe-0002Vr-0M for nemo@optimus.ietf.org; Wed, 22 Oct 2003 14:34:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21228 for ; Wed, 22 Oct 2003 14:34:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACNob-00010V-00 for nemo@ietf.org; Wed, 22 Oct 2003 14:34:37 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1ACNoa-00010S-00 for nemo@ietf.org; Wed, 22 Oct 2003 14:34:36 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h9MIYVqD018039; Wed, 22 Oct 2003 11:34:31 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h9MIYCaM001173; Wed, 22 Oct 2003 13:34:13 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id D897E2EC95; Wed, 22 Oct 2003 20:34:26 +0200 (CEST) Message-ID: <3F96CDB2.7060208@nal.motlabs.com> Date: Wed, 22 Oct 2003 20:34:26 +0200 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: Vijay Devarapalli Cc: nemo@ietf.org, Ryuji Wakikawa , "Pascal Thubert (pthubert)" Subject: Re: [nemo] Comments on draft-wakikawa-mip6-nemo-haha-00.txt References: <3F96AEB9.4030709@nal.motlabs.com> <3F96BDB4.1030703@iprg.nokia.com> <3F96C294.8060407@nal.motlabs.com> <3F96C604.9010409@iprg.nokia.com> In-Reply-To: <3F96C604.9010409@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> It said "it does not enable forwarding for the Home Address", no MNP. >> Forwarding for a Home Address can only happen if there is forwarding for >> some prefix, or host-based route, but it is still forwarding for a Home >> Address. > > > needs to be fixed. but I guess you understood what it intends > to say. each Home Agent can either tunnel the packets directly > to the Mobile Router's current point of attachment or to the > primary HA. Yes I got that. I reacted on it because it seemed the only point in the text to mention a little bit that HA's will not always advertise reachability of same HoA. But now that you say that it is a common thread of the entire HAHA draft that all HA's are _inside_ a unique small domain (even if spread over a wide geographical area) then I understand it. > think of a fat pipe between the HA clusters. YEs, fat but very distant from the CN. The HAHA domain being very small in terms of IP hops it can not be close to any IP CN of the Internet (even if it _could be_ close geographically). There can surely be no big fat pipe close to all CNs of the Internet, because there are so many. No? Alex GBU From nemo-admin@ietf.org Thu Oct 23 01:13:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19817 for ; Thu, 23 Oct 2003 01:13:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACXmO-0000DE-PF; Thu, 23 Oct 2003 01:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACXmN-0000Cd-0H for nemo@optimus.ietf.org; Thu, 23 Oct 2003 01:12:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19791 for ; Thu, 23 Oct 2003 01:12:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACXmJ-0001I4-00 for nemo@ietf.org; Thu, 23 Oct 2003 01:12:55 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ACXmJ-0001Hw-00 for nemo@ietf.org; Thu, 23 Oct 2003 01:12:55 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDBF2>; Thu, 23 Oct 2003 01:12:25 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E02@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Alexandru Petrescu'" , Noriaki Takamiya Cc: nemo@ietf.org Subject: RE: [nemo] About BA status 141 Date: Thu, 23 Oct 2003 01:12:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > > In 4), what does HA verify? > > > > Does 'fail' mean that HA couldn't just configure the > > forwarding(e.g. reverse tunneling or setup routing table)? > > I guess so. For example if a similar entry already exists in > the table, > or if the prefix is larger than 128. No? => But that sounds more like a message format error which should be generic for any incorrect field in the BU. I thought this was already covered in the base MIPv6 spec. Hesham From exim@www1.ietf.org Thu Oct 23 01:13:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19833 for ; Thu, 23 Oct 2003 01:13:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACXmS-0000F5-Cu for nemo-archive@odin.ietf.org; Thu, 23 Oct 2003 01:13:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N5D4Oe000926 for nemo-archive@odin.ietf.org; Thu, 23 Oct 2003 01:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACXmS-0000Er-5P for nemo-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 01:13:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19807 for ; Thu, 23 Oct 2003 01:12:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACXmP-0001IR-00 for nemo-web-archive@ietf.org; Thu, 23 Oct 2003 01:13:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACXmO-0001IO-00 for nemo-web-archive@ietf.org; Thu, 23 Oct 2003 01:13:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACXmO-0000DE-PF; Thu, 23 Oct 2003 01:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACXmN-0000Cd-0H for nemo@optimus.ietf.org; Thu, 23 Oct 2003 01:12:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19791 for ; Thu, 23 Oct 2003 01:12:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACXmJ-0001I4-00 for nemo@ietf.org; Thu, 23 Oct 2003 01:12:55 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ACXmJ-0001Hw-00 for nemo@ietf.org; Thu, 23 Oct 2003 01:12:55 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDBF2>; Thu, 23 Oct 2003 01:12:25 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E02@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Alexandru Petrescu'" , Noriaki Takamiya Cc: nemo@ietf.org Subject: RE: [nemo] About BA status 141 Date: Thu, 23 Oct 2003 01:12:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > > In 4), what does HA verify? > > > > Does 'fail' mean that HA couldn't just configure the > > forwarding(e.g. reverse tunneling or setup routing table)? > > I guess so. For example if a similar entry already exists in > the table, > or if the prefix is larger than 128. No? => But that sounds more like a message format error which should be generic for any incorrect field in the BU. I thought this was already covered in the base MIPv6 spec. Hesham From nemo-admin@ietf.org Thu Oct 23 02:57:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05161 for ; Thu, 23 Oct 2003 02:57:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZP3-0002Wr-Bq; Thu, 23 Oct 2003 02:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZOJ-0002HA-5V for nemo@optimus.ietf.org; Thu, 23 Oct 2003 02:56:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05141; Thu, 23 Oct 2003 02:56:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZOD-0002PI-00; Thu, 23 Oct 2003 02:56:09 -0400 Received: from [129.254.16.14] (helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1ACZOD-0002P7-00; Thu, 23 Oct 2003 02:56:09 -0400 Received: from jafymobile (211.253.241.187 [211.253.241.187]) by cms4.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VCN88DRT; Thu, 23 Oct 2003 15:52:33 +0900 Reply-To: From: "HyunWook Cha" To: "'Alexandru Petrescu'" Cc: , Date: Thu, 23 Oct 2003 15:55:13 +0900 Organization: ETRI Message-ID: <000601c39932$a92b2f20$660010ac@jafymobile> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3F96B480.2040906@nal.motlabs.com> Content-Transfer-Encoding: 7bit Subject: [nemo] RE: NEMO or MANET? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alex, I am glad to receive your reply though it seems a bit late. Anyway, please see inline comments. > > HyunWook Cha wrote: > > Hi Alex, I apologize that my second comment on A-C-B seems to be > > repeated. Please ignore that. And, I modify my first comment. Since > > an MR which does not have global prefixes requests prefix > delegation, > > As long as manets or partitions (clusters?) of manets stay > separated from the Internet, they don't quite need global > prefixes, no? > Right. However, I assume that at least one mobile network prefix be assingned for a mobile network statically for normal nodes in a mobile network to be enable to communicate with normal nodes in another mobile network. In this case, duplicate address problem can occur. After all, without gateways, each MR should configure its global prefix autonomously. This is not considered in the MANET wg, though. > > MR_B delegates its prefix to MR_A in case A-(B-C) that I mentioned > > below. How about this case where one group(cluster or partion in > > terms of MANET) of mobile networks is connected to another group of > > mobile netwroks? (A->B)-(C->D) I think prefix delegation should be > > extended to propagate route information for prefix of one group to > > other group although prefix delegation is not needed. > > I would say that before extending prefix delegation to > propagate groups of prefixes in the form of routing > information, let's see first how prefix delegation works in > simple cases, draft-droms-nemo-dhcpv6-pd-00.txt > > > If so, why don't you use MANET routing protcols? > > Yes, using MANET routing protocols when there are many manets > or many manet partitions makes a lot of sense. I am not > knowledgeable enough on the manet protocols to know whether > any does address assignment (or address autoconfiguration), > and if not, maybe manet protocols couldl be extended to do > that too with DHCP. > Basically, any unique id or prefix for a MR is applicable since manet routing protocol exists. MANET wg views topology of a manet more unreliable than you NEMO guys do. Thus, address renumbering according to change of the topology is not suitable. > Thanks for comments, > > Alex > GBU > From exim@www1.ietf.org Thu Oct 23 02:57:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05178 for ; Thu, 23 Oct 2003 02:57:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZP7-0002Yj-2d for nemo-archive@odin.ietf.org; Thu, 23 Oct 2003 02:57:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N6v4u5009831 for nemo-archive@odin.ietf.org; Thu, 23 Oct 2003 02:57:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZP6-0002YU-My for nemo-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 02:57:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05145 for ; Thu, 23 Oct 2003 02:56:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZP2-0002PY-00 for nemo-web-archive@ietf.org; Thu, 23 Oct 2003 02:57:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACZP2-0002PV-00 for nemo-web-archive@ietf.org; Thu, 23 Oct 2003 02:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZP3-0002Wr-Bq; Thu, 23 Oct 2003 02:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZOJ-0002HA-5V for nemo@optimus.ietf.org; Thu, 23 Oct 2003 02:56:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05141; Thu, 23 Oct 2003 02:56:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZOD-0002PI-00; Thu, 23 Oct 2003 02:56:09 -0400 Received: from [129.254.16.14] (helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1ACZOD-0002P7-00; Thu, 23 Oct 2003 02:56:09 -0400 Received: from jafymobile (211.253.241.187 [211.253.241.187]) by cms4.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VCN88DRT; Thu, 23 Oct 2003 15:52:33 +0900 Reply-To: From: "HyunWook Cha" To: "'Alexandru Petrescu'" Cc: , Date: Thu, 23 Oct 2003 15:55:13 +0900 Organization: ETRI Message-ID: <000601c39932$a92b2f20$660010ac@jafymobile> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3F96B480.2040906@nal.motlabs.com> Content-Transfer-Encoding: 7bit Subject: [nemo] RE: NEMO or MANET? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, I am glad to receive your reply though it seems a bit late. Anyway, please see inline comments. > > HyunWook Cha wrote: > > Hi Alex, I apologize that my second comment on A-C-B seems to be > > repeated. Please ignore that. And, I modify my first comment. Since > > an MR which does not have global prefixes requests prefix > delegation, > > As long as manets or partitions (clusters?) of manets stay > separated from the Internet, they don't quite need global > prefixes, no? > Right. However, I assume that at least one mobile network prefix be assingned for a mobile network statically for normal nodes in a mobile network to be enable to communicate with normal nodes in another mobile network. In this case, duplicate address problem can occur. After all, without gateways, each MR should configure its global prefix autonomously. This is not considered in the MANET wg, though. > > MR_B delegates its prefix to MR_A in case A-(B-C) that I mentioned > > below. How about this case where one group(cluster or partion in > > terms of MANET) of mobile networks is connected to another group of > > mobile netwroks? (A->B)-(C->D) I think prefix delegation should be > > extended to propagate route information for prefix of one group to > > other group although prefix delegation is not needed. > > I would say that before extending prefix delegation to > propagate groups of prefixes in the form of routing > information, let's see first how prefix delegation works in > simple cases, draft-droms-nemo-dhcpv6-pd-00.txt > > > If so, why don't you use MANET routing protcols? > > Yes, using MANET routing protocols when there are many manets > or many manet partitions makes a lot of sense. I am not > knowledgeable enough on the manet protocols to know whether > any does address assignment (or address autoconfiguration), > and if not, maybe manet protocols couldl be extended to do > that too with DHCP. > Basically, any unique id or prefix for a MR is applicable since manet routing protocol exists. MANET wg views topology of a manet more unreliable than you NEMO guys do. Thus, address renumbering according to change of the topology is not suitable. > Thanks for comments, > > Alex > GBU > From nemo-admin@ietf.org Thu Oct 23 03:27:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06383 for ; Thu, 23 Oct 2003 03:27:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZs5-0003OM-Ei; Thu, 23 Oct 2003 03:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZri-0003Iw-AN for nemo@optimus.ietf.org; Thu, 23 Oct 2003 03:26:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06374 for ; Thu, 23 Oct 2003 03:26:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZrf-0002qE-00 for nemo@ietf.org; Thu, 23 Oct 2003 03:26:35 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1ACZrf-0002pX-00 for nemo@ietf.org; Thu, 23 Oct 2003 03:26:35 -0400 Received: from wanwan.sfc.wide.ad.jp (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 587B05D013; Thu, 23 Oct 2003 16:26:05 +0900 (JST) Date: Thu, 23 Oct 2003 16:26:05 +0900 Message-ID: From: Koshiro MITSUYA To: Alexandru Petrescu Cc: Noriaki Takamiya , nemo@ietf.org Subject: Re: [nemo] About BA status 141 In-Reply-To: <3F96B65E.4040006@nal.motlabs.com> References: <20031022.185854.846933446.takamiya@po.ntts.co.jp> <3F96A4AA.5000105@nal.motlabs.com> <20031023.014612.607960534.takamiya@po.ntts.co.jp> <3F96B65E.4040006@nal.motlabs.com> User-Agent: Wanderlust/2.8.1 (Something) EMIKO/1.14.1 (Choanoflagellata) LIMIT/1.14.7 (Fujiidera) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.8) MULE/4.0 (HANANOEN) Organization: Keio University MIME-Version: 1.0 (generated by EMIKO 1.14.1 - "Choanoflagellata") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi all, In my implementation, HA has a table which includes "capable" mobile network prefixes which is statically configured by manager. I mean "capable" that the prefix can be routed and managed by this HA. If HA receive invalid prefix, "invalid" means not-capable-mobile network prefixes, HA return 141. Then MR may try another HA on the HA list. (I haven't implemented this re-try part yet.) If a similar entry already exists in the table, MR overwrite the entry by new BU. Otherwise Alexandru said he guesses that HA return BA with status 141. I don't know which is good behavior.. thanks, Koshiro At Wed, 22 Oct 2003 18:54:54 +0200, Alexandru Petrescu wrote: > > Noriaki Takamiya wrote: > > IMHO, I thought that HA must check if it can forward to the mobile > > network prefix or not(e.g. using ICMP echoreplay) after > > configuration for forwarding. > > > > I recognize that the check using ICMP is not realistic. > > Of course it depends. The idea of checking connectivity with echo > request/reply comes to mind immediately when thinking about > reachability. For example RR tests of Mobile IPv6 are a sort of just > that: check routability between CN, MN and HA. > > On another hand, a very early version of draft-kniveton-mobrtr had a > sort of check echo req/rep too from HA to MR, IIRC. Then it was no > longer proposed, probably because being an ICMP message does not give > real reliable indication ("reply" can be lost now and not 10s later). > > With failing Mobile IPv6 RR tests, there's a backup: use bidir tunnel > instead of using RO. With failing req/rep from HA to MR there is no > backup, HA simply informs the MR 141. > > Or something like that... > > Alex > GBU > --- Koshiro Mitsuya Jun Murai lab. Graduate School of Media and Governance, Keio University. 5322 Endo, Fujisawa-shi, Kanagawa 252-8520, Japan. Phone : +81-466-49-1100 Fax : +81-466-49-1395 E-mail: mitsuya@sfc.wide.ad.jp HP : http://www.sfc.wide.ad.jp/~mitsuya/ key fingerprint = 3487 88C9 B9AA 3BFC B5CF D479 5466 0680 98C0 9202 From exim@www1.ietf.org Thu Oct 23 03:27:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06403 for ; Thu, 23 Oct 2003 03:27:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZs7-0003Qe-JQ for nemo-archive@odin.ietf.org; Thu, 23 Oct 2003 03:27:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N7R3xv013174 for nemo-archive@odin.ietf.org; Thu, 23 Oct 2003 03:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZs7-0003QP-Dv for nemo-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 03:27:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06378 for ; Thu, 23 Oct 2003 03:26:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZs5-0002qW-00 for nemo-web-archive@ietf.org; Thu, 23 Oct 2003 03:27:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACZs4-0002qT-00 for nemo-web-archive@ietf.org; Thu, 23 Oct 2003 03:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZs5-0003OM-Ei; Thu, 23 Oct 2003 03:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZri-0003Iw-AN for nemo@optimus.ietf.org; Thu, 23 Oct 2003 03:26:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06374 for ; Thu, 23 Oct 2003 03:26:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZrf-0002qE-00 for nemo@ietf.org; Thu, 23 Oct 2003 03:26:35 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1ACZrf-0002pX-00 for nemo@ietf.org; Thu, 23 Oct 2003 03:26:35 -0400 Received: from wanwan.sfc.wide.ad.jp (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 587B05D013; Thu, 23 Oct 2003 16:26:05 +0900 (JST) Date: Thu, 23 Oct 2003 16:26:05 +0900 Message-ID: From: Koshiro MITSUYA To: Alexandru Petrescu Cc: Noriaki Takamiya , nemo@ietf.org Subject: Re: [nemo] About BA status 141 In-Reply-To: <3F96B65E.4040006@nal.motlabs.com> References: <20031022.185854.846933446.takamiya@po.ntts.co.jp> <3F96A4AA.5000105@nal.motlabs.com> <20031023.014612.607960534.takamiya@po.ntts.co.jp> <3F96B65E.4040006@nal.motlabs.com> User-Agent: Wanderlust/2.8.1 (Something) EMIKO/1.14.1 (Choanoflagellata) LIMIT/1.14.7 (Fujiidera) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.8) MULE/4.0 (HANANOEN) Organization: Keio University MIME-Version: 1.0 (generated by EMIKO 1.14.1 - "Choanoflagellata") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi all, In my implementation, HA has a table which includes "capable" mobile network prefixes which is statically configured by manager. I mean "capable" that the prefix can be routed and managed by this HA. If HA receive invalid prefix, "invalid" means not-capable-mobile network prefixes, HA return 141. Then MR may try another HA on the HA list. (I haven't implemented this re-try part yet.) If a similar entry already exists in the table, MR overwrite the entry by new BU. Otherwise Alexandru said he guesses that HA return BA with status 141. I don't know which is good behavior.. thanks, Koshiro At Wed, 22 Oct 2003 18:54:54 +0200, Alexandru Petrescu wrote: > > Noriaki Takamiya wrote: > > IMHO, I thought that HA must check if it can forward to the mobile > > network prefix or not(e.g. using ICMP echoreplay) after > > configuration for forwarding. > > > > I recognize that the check using ICMP is not realistic. > > Of course it depends. The idea of checking connectivity with echo > request/reply comes to mind immediately when thinking about > reachability. For example RR tests of Mobile IPv6 are a sort of just > that: check routability between CN, MN and HA. > > On another hand, a very early version of draft-kniveton-mobrtr had a > sort of check echo req/rep too from HA to MR, IIRC. Then it was no > longer proposed, probably because being an ICMP message does not give > real reliable indication ("reply" can be lost now and not 10s later). > > With failing Mobile IPv6 RR tests, there's a backup: use bidir tunnel > instead of using RO. With failing req/rep from HA to MR there is no > backup, HA simply informs the MR 141. > > Or something like that... > > Alex > GBU > --- Koshiro Mitsuya Jun Murai lab. Graduate School of Media and Governance, Keio University. 5322 Endo, Fujisawa-shi, Kanagawa 252-8520, Japan. Phone : +81-466-49-1100 Fax : +81-466-49-1395 E-mail: mitsuya@sfc.wide.ad.jp HP : http://www.sfc.wide.ad.jp/~mitsuya/ key fingerprint = 3487 88C9 B9AA 3BFC B5CF D479 5466 0680 98C0 9202 From nemo-admin@ietf.org Thu Oct 23 14:06:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10325 for ; Thu, 23 Oct 2003 14:06:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjqV-0005KQ-6P; Thu, 23 Oct 2003 14:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjqH-0005GF-Bx for nemo@optimus.ietf.org; Thu, 23 Oct 2003 14:05:50 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10204 for ; Thu, 23 Oct 2003 14:05:36 -0400 (EDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9NI4Rf22522; Thu, 23 Oct 2003 11:04:27 -0700 X-mProtect: <200310231804> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdd0a3iT; Thu, 23 Oct 2003 11:04:26 PDT Message-ID: <3F9818AD.4040800@iprg.nokia.com> Date: Thu, 23 Oct 2003 11:06:37 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: "'Alexandru Petrescu'" , Noriaki Takamiya , nemo@ietf.org Subject: Re: [nemo] About BA status 141 References: <748C6D0A58C0F94CA63C198B6674697A01922E02@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E02@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > > In 4), what does HA verify? > > > > > > Does 'fail' mean that HA couldn't just configure the > > > forwarding(e.g. reverse tunneling or setup routing table)? > > > > I guess so. For example if a similar entry already exists in > > the table, > > or if the prefix is larger than 128. No? > > => But that sounds more like a message format error > which should be generic for any incorrect field in the > BU. I thought this was already covered in the base MIPv6 > spec. prefix information is not sent in the BU in MIPv6. in Nemo we are trying to deal with the Mobile Router including some invalid prefix in the Binding Update. the prefix could be invalid due to many reasons (invalid prefix length, site-local Mobile Network Prefix, reserved IPv6 prefix as Mobile Network Prefix, prefix that cannot be aggregated at the Home Network, etc.....). Vijay From exim@www1.ietf.org Thu Oct 23 14:29:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11340 for ; Thu, 23 Oct 2003 14:29:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACkD7-0000pz-LB for nemo-archive@odin.ietf.org; Thu, 23 Oct 2003 14:29:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NITPAa003211 for nemo-archive@odin.ietf.org; Thu, 23 Oct 2003 14:29:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACkD7-0000pZ-0r for nemo-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 14:29:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11260 for ; Thu, 23 Oct 2003 14:29:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACkD4-0006Bh-00 for nemo-web-archive@ietf.org; Thu, 23 Oct 2003 14:29:22 -0400 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ACk4A-000615-00 for nemo-web-archive@ietf.org; Thu, 23 Oct 2003 14:20:10 -0400 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1ACjqg-00057a-K2 for nemo-web-archive@ietf.org; Thu, 23 Oct 2003 14:06:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjqV-0005KQ-6P; Thu, 23 Oct 2003 14:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACjqH-0005GF-Bx for nemo@optimus.ietf.org; Thu, 23 Oct 2003 14:05:50 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10204 for ; Thu, 23 Oct 2003 14:05:36 -0400 (EDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9NI4Rf22522; Thu, 23 Oct 2003 11:04:27 -0700 X-mProtect: <200310231804> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdd0a3iT; Thu, 23 Oct 2003 11:04:26 PDT Message-ID: <3F9818AD.4040800@iprg.nokia.com> Date: Thu, 23 Oct 2003 11:06:37 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: "'Alexandru Petrescu'" , Noriaki Takamiya , nemo@ietf.org Subject: Re: [nemo] About BA status 141 References: <748C6D0A58C0F94CA63C198B6674697A01922E02@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E02@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > > In 4), what does HA verify? > > > > > > Does 'fail' mean that HA couldn't just configure the > > > forwarding(e.g. reverse tunneling or setup routing table)? > > > > I guess so. For example if a similar entry already exists in > > the table, > > or if the prefix is larger than 128. No? > > => But that sounds more like a message format error > which should be generic for any incorrect field in the > BU. I thought this was already covered in the base MIPv6 > spec. prefix information is not sent in the BU in MIPv6. in Nemo we are trying to deal with the Mobile Router including some invalid prefix in the Binding Update. the prefix could be invalid due to many reasons (invalid prefix length, site-local Mobile Network Prefix, reserved IPv6 prefix as Mobile Network Prefix, prefix that cannot be aggregated at the Home Network, etc.....). Vijay From nemo-admin@ietf.org Thu Oct 23 22:07:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29271 for ; Thu, 23 Oct 2003 22:07:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrLy-0007HK-8A; Thu, 23 Oct 2003 22:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrK5-0006hK-1O for nemo@optimus.ietf.org; Thu, 23 Oct 2003 22:06:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29227 for ; Thu, 23 Oct 2003 22:04:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACrK1-0003vI-00 for nemo@ietf.org; Thu, 23 Oct 2003 22:05:01 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ACrK1-0003v4-00 for nemo@ietf.org; Thu, 23 Oct 2003 22:05:01 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDFF7>; Thu, 23 Oct 2003 22:08:47 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E0E@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Vijay Devarapalli'" Cc: "'Alexandru Petrescu'" , Noriaki Takamiya , nemo@ietf.org Subject: RE: [nemo] About BA status 141 Date: Thu, 23 Oct 2003 22:08:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > > > I guess so. For example if a similar entry already exists in > > > the table, > > > or if the prefix is larger than 128. No? > > > > => But that sounds more like a message format error > > which should be generic for any incorrect field in the > > BU. I thought this was already covered in the base MIPv6 > > spec. > > prefix information is not sent in the BU in MIPv6. in Nemo > we are trying to deal with the Mobile Router including > some invalid prefix in the Binding Update. the prefix could > be invalid due to many reasons (invalid prefix length, > site-local Mobile Network Prefix, reserved IPv6 prefix as > Mobile Network Prefix, prefix that cannot be aggregated at > the Home Network, etc.....). => I understand. If that's what it's used for then perhaps the error code should reflect that, i.e. 'invalid prefix' or something like that. Of course you can still reuse the 'format error' anyway for a new field, but if you want to be specific you can create a new error code (e.g. 141) and give it a specific meaning. Hesham > > Vijay > From exim@www1.ietf.org Thu Oct 23 22:09:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29307 for ; Thu, 23 Oct 2003 22:09:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrNK-00088v-GH for nemo-archive@odin.ietf.org; Thu, 23 Oct 2003 22:09:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O28QjD031295 for nemo-archive@odin.ietf.org; Thu, 23 Oct 2003 22:08:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrM1-0007K5-9E for nemo-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 22:08:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29266 for ; Thu, 23 Oct 2003 22:06:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACrLy-0003wV-00 for nemo-web-archive@ietf.org; Thu, 23 Oct 2003 22:07:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACrLx-0003wS-00 for nemo-web-archive@ietf.org; Thu, 23 Oct 2003 22:07:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrLy-0007HK-8A; Thu, 23 Oct 2003 22:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACrK5-0006hK-1O for nemo@optimus.ietf.org; Thu, 23 Oct 2003 22:06:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29227 for ; Thu, 23 Oct 2003 22:04:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACrK1-0003vI-00 for nemo@ietf.org; Thu, 23 Oct 2003 22:05:01 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ACrK1-0003v4-00 for nemo@ietf.org; Thu, 23 Oct 2003 22:05:01 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <497RDFF7>; Thu, 23 Oct 2003 22:08:47 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E0E@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Vijay Devarapalli'" Cc: "'Alexandru Petrescu'" , Noriaki Takamiya , nemo@ietf.org Subject: RE: [nemo] About BA status 141 Date: Thu, 23 Oct 2003 22:08:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > > > I guess so. For example if a similar entry already exists in > > > the table, > > > or if the prefix is larger than 128. No? > > > > => But that sounds more like a message format error > > which should be generic for any incorrect field in the > > BU. I thought this was already covered in the base MIPv6 > > spec. > > prefix information is not sent in the BU in MIPv6. in Nemo > we are trying to deal with the Mobile Router including > some invalid prefix in the Binding Update. the prefix could > be invalid due to many reasons (invalid prefix length, > site-local Mobile Network Prefix, reserved IPv6 prefix as > Mobile Network Prefix, prefix that cannot be aggregated at > the Home Network, etc.....). => I understand. If that's what it's used for then perhaps the error code should reflect that, i.e. 'invalid prefix' or something like that. Of course you can still reuse the 'format error' anyway for a new field, but if you want to be specific you can create a new error code (e.g. 141) and give it a specific meaning. Hesham > > Vijay > From nemo-admin@ietf.org Fri Oct 24 05:28:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22514 for ; Fri, 24 Oct 2003 05:28:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACyEk-00029m-6E; Fri, 24 Oct 2003 05:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACyEa-000260-D2 for nemo@optimus.ietf.org; Fri, 24 Oct 2003 05:27:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22470 for ; Fri, 24 Oct 2003 05:27:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACyEW-0000OZ-00 for nemo@ietf.org; Fri, 24 Oct 2003 05:27:48 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ACyEW-0000OW-00 for nemo@ietf.org; Fri, 24 Oct 2003 05:27:48 -0400 Received: from [64.36.73.242] (home2.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h9O9S8MU077574; Fri, 24 Oct 2003 02:28:08 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 24 Oct 2003 02:27:46 -0700 From: "T.J. Kniveton" To: CC: Margaret Wasserman , Thomas Narten Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi folks, The Basic Support draft has been issued for a while now and has had no significant issues pending in this version. We would like to encourage everyone in the working group to make sure you have read this draft and contributed any open issues so that they can be resolved and we can move on from this charter item. So, we would like to issue a working group last call for this draft, which will extend for two weeks, until November 7th. Based on the response during this time, the working group will decide how to update the draft and move forward. Thanks, -TJ Kniveton, Thierry Ernst. NEMO chairs From exim@www1.ietf.org Fri Oct 24 05:28:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22529 for ; Fri, 24 Oct 2003 05:28:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACyEq-0002Fi-FG for nemo-archive@odin.ietf.org; Fri, 24 Oct 2003 05:28:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O9S8Vh008654 for nemo-archive@odin.ietf.org; Fri, 24 Oct 2003 05:28:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACyEp-0002FU-SD for nemo-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 05:28:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22483 for ; Fri, 24 Oct 2003 05:27:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACyEl-0000Or-00 for nemo-web-archive@ietf.org; Fri, 24 Oct 2003 05:28:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACyEl-0000Oo-00 for nemo-web-archive@ietf.org; Fri, 24 Oct 2003 05:28:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACyEk-00029m-6E; Fri, 24 Oct 2003 05:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACyEa-000260-D2 for nemo@optimus.ietf.org; Fri, 24 Oct 2003 05:27:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22470 for ; Fri, 24 Oct 2003 05:27:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACyEW-0000OZ-00 for nemo@ietf.org; Fri, 24 Oct 2003 05:27:48 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ACyEW-0000OW-00 for nemo@ietf.org; Fri, 24 Oct 2003 05:27:48 -0400 Received: from [64.36.73.242] (home2.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h9O9S8MU077574; Fri, 24 Oct 2003 02:28:08 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 24 Oct 2003 02:27:46 -0700 From: "T.J. Kniveton" To: CC: Margaret Wasserman , Thomas Narten Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi folks, The Basic Support draft has been issued for a while now and has had no significant issues pending in this version. We would like to encourage everyone in the working group to make sure you have read this draft and contributed any open issues so that they can be resolved and we can move on from this charter item. So, we would like to issue a working group last call for this draft, which will extend for two weeks, until November 7th. Based on the response during this time, the working group will decide how to update the draft and move forward. Thanks, -TJ Kniveton, Thierry Ernst. NEMO chairs From nemo-admin@ietf.org Fri Oct 24 13:41:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19586 for ; Fri, 24 Oct 2003 13:41:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5vp-0006WQ-9y; Fri, 24 Oct 2003 13:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5tw-0005sH-QN for nemo@optimus.ietf.org; Fri, 24 Oct 2003 13:40:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19519 for ; Fri, 24 Oct 2003 13:38:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD5tu-0001Tx-00 for nemo@ietf.org; Fri, 24 Oct 2003 13:39:02 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AD5tt-0001Tr-00 for nemo@ietf.org; Fri, 24 Oct 2003 13:39:01 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9OHaQh30044; Fri, 24 Oct 2003 10:36:26 -0700 X-mProtect: <200310241736> Nokia Silicon Valley Messaging Protection Received: from danira-pool05289.americas.nokia.com (10.241.52.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmTfdYs; Fri, 24 Oct 2003 10:36:24 PDT Message-ID: <3F99630B.8080005@iprg.nokia.com> Date: Fri, 24 Oct 2003 10:36:11 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: "'Alexandru Petrescu'" , Noriaki Takamiya , nemo@ietf.org Subject: Re: [nemo] About BA status 141 References: <748C6D0A58C0F94CA63C198B6674697A01922E0E@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E0E@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > > > I guess so. For example if a similar entry already exists in > > > > the table, > > > > or if the prefix is larger than 128. No? > > > > > > => But that sounds more like a message format error > > > which should be generic for any incorrect field in the > > > BU. I thought this was already covered in the base MIPv6 > > > spec. > > > > prefix information is not sent in the BU in MIPv6. in Nemo > > we are trying to deal with the Mobile Router including > > some invalid prefix in the Binding Update. the prefix could > > be invalid due to many reasons (invalid prefix length, > > site-local Mobile Network Prefix, reserved IPv6 prefix as > > Mobile Network Prefix, prefix that cannot be aggregated at > > the Home Network, etc.....). > > => I understand. If that's what it's used for > then perhaps the error code should reflect that, > i.e. 'invalid prefix' or something like that. actually it is. :) 141 Invalid Prefix section 4.2 of http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-01.txt Vijay From exim@www1.ietf.org Fri Oct 24 13:43:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19665 for ; Fri, 24 Oct 2003 13:43:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5xD-0006jv-5v for nemo-archive@odin.ietf.org; Fri, 24 Oct 2003 13:43:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OHgRC9025904 for nemo-archive@odin.ietf.org; Fri, 24 Oct 2003 13:42:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5vt-0006XX-V6 for nemo-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 13:42:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19562 for ; Fri, 24 Oct 2003 13:40:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD5vr-0001UV-00 for nemo-web-archive@ietf.org; Fri, 24 Oct 2003 13:41:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD5vr-0001US-00 for nemo-web-archive@ietf.org; Fri, 24 Oct 2003 13:41:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5vp-0006WQ-9y; Fri, 24 Oct 2003 13:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5tw-0005sH-QN for nemo@optimus.ietf.org; Fri, 24 Oct 2003 13:40:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19519 for ; Fri, 24 Oct 2003 13:38:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD5tu-0001Tx-00 for nemo@ietf.org; Fri, 24 Oct 2003 13:39:02 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AD5tt-0001Tr-00 for nemo@ietf.org; Fri, 24 Oct 2003 13:39:01 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9OHaQh30044; Fri, 24 Oct 2003 10:36:26 -0700 X-mProtect: <200310241736> Nokia Silicon Valley Messaging Protection Received: from danira-pool05289.americas.nokia.com (10.241.52.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmTfdYs; Fri, 24 Oct 2003 10:36:24 PDT Message-ID: <3F99630B.8080005@iprg.nokia.com> Date: Fri, 24 Oct 2003 10:36:11 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: "'Alexandru Petrescu'" , Noriaki Takamiya , nemo@ietf.org Subject: Re: [nemo] About BA status 141 References: <748C6D0A58C0F94CA63C198B6674697A01922E0E@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E0E@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > > > > I guess so. For example if a similar entry already exists in > > > > the table, > > > > or if the prefix is larger than 128. No? > > > > > > => But that sounds more like a message format error > > > which should be generic for any incorrect field in the > > > BU. I thought this was already covered in the base MIPv6 > > > spec. > > > > prefix information is not sent in the BU in MIPv6. in Nemo > > we are trying to deal with the Mobile Router including > > some invalid prefix in the Binding Update. the prefix could > > be invalid due to many reasons (invalid prefix length, > > site-local Mobile Network Prefix, reserved IPv6 prefix as > > Mobile Network Prefix, prefix that cannot be aggregated at > > the Home Network, etc.....). > > => I understand. If that's what it's used for > then perhaps the error code should reflect that, > i.e. 'invalid prefix' or something like that. actually it is. :) 141 Invalid Prefix section 4.2 of http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-01.txt Vijay From nemo-admin@ietf.org Sun Oct 26 18:59:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05452 for ; Sun, 26 Oct 2003 18:59:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADumi-00019H-Ty; Sun, 26 Oct 2003 18:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADum6-00012E-Vt for nemo@optimus.ietf.org; Sun, 26 Oct 2003 18:58:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05415 for ; Sun, 26 Oct 2003 18:58:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADum3-0002op-00 for nemo@ietf.org; Sun, 26 Oct 2003 18:58:19 -0500 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 1ADum3-0002oH-00 for nemo@ietf.org; Sun, 26 Oct 2003 18:58:19 -0500 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 1ADuk0-0001lB-00 for ; Mon, 27 Oct 2003 10:56:12 +1100 Date: Mon, 27 Oct 2003 10:56:11 +1100 (EST) From: Eranga Perera To: nemo@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [nemo] 58th IETF meeting Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi, Will there be any NEMO related discussions at the 58th IETF meeting? Cheers Eranga From exim@www1.ietf.org Sun Oct 26 18:59:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05484 for ; Sun, 26 Oct 2003 18:59:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADumq-0001Am-C4 for nemo-archive@odin.ietf.org; Sun, 26 Oct 2003 18:59:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9QNx87k004507 for nemo-archive@odin.ietf.org; Sun, 26 Oct 2003 18:59:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADumq-0001Ac-6h for nemo-web-archive@optimus.ietf.org; Sun, 26 Oct 2003 18:59:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05443 for ; Sun, 26 Oct 2003 18:58:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADumn-0002p9-00 for nemo-web-archive@ietf.org; Sun, 26 Oct 2003 18:59:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADumm-0002p5-00 for nemo-web-archive@ietf.org; Sun, 26 Oct 2003 18:59:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADumi-00019H-Ty; Sun, 26 Oct 2003 18:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADum6-00012E-Vt for nemo@optimus.ietf.org; Sun, 26 Oct 2003 18:58:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05415 for ; Sun, 26 Oct 2003 18:58:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADum3-0002op-00 for nemo@ietf.org; Sun, 26 Oct 2003 18:58:19 -0500 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 1ADum3-0002oH-00 for nemo@ietf.org; Sun, 26 Oct 2003 18:58:19 -0500 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 1ADuk0-0001lB-00 for ; Mon, 27 Oct 2003 10:56:12 +1100 Date: Mon, 27 Oct 2003 10:56:11 +1100 (EST) From: Eranga Perera To: nemo@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [nemo] 58th IETF meeting Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi, Will there be any NEMO related discussions at the 58th IETF meeting? Cheers Eranga From nemo-admin@ietf.org Sun Oct 26 19:39:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06429 for ; Sun, 26 Oct 2003 19:39:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADvPQ-0004V8-Vf; Sun, 26 Oct 2003 19:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADvP0-0004TQ-KX for nemo@optimus.ietf.org; Sun, 26 Oct 2003 19:38:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06396 for ; Sun, 26 Oct 2003 19:38:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADvOy-0003Qz-00 for nemo@ietf.org; Sun, 26 Oct 2003 19:38:32 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ADvOy-0003QW-00 for nemo@ietf.org; Sun, 26 Oct 2003 19:38:32 -0500 Received: from [64.36.73.242] (home2.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h9R0ciMU090711; Sun, 26 Oct 2003 16:38:47 -0800 (PST) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 26 Oct 2003 16:38:13 -0800 Subject: Re: [nemo] 58th IETF meeting From: "T.J. Kniveton" To: Eranga Perera , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 10/26/03 3:56 PM, "Eranga Perera" wrote: > Hi, > Will there be any NEMO related discussions at the 58th IETF meeting? > Cheers > Eranga > > > Yes! http://www.ietf.org/meetings/agenda_58.html check wednesday afternoon. -TJ From exim@www1.ietf.org Sun Oct 26 19:39:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06445 for ; Sun, 26 Oct 2003 19:39:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADvPU-0004WI-TW for nemo-archive@odin.ietf.org; Sun, 26 Oct 2003 19:39:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9R0d4Gr017368 for nemo-archive@odin.ietf.org; Sun, 26 Oct 2003 19:39:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADvPU-0004W3-NV for nemo-web-archive@optimus.ietf.org; Sun, 26 Oct 2003 19:39:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06406 for ; Sun, 26 Oct 2003 19:38:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADvPT-0003RD-00 for nemo-web-archive@ietf.org; Sun, 26 Oct 2003 19:39:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADvPS-0003RA-00 for nemo-web-archive@ietf.org; Sun, 26 Oct 2003 19:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADvPQ-0004V8-Vf; Sun, 26 Oct 2003 19:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADvP0-0004TQ-KX for nemo@optimus.ietf.org; Sun, 26 Oct 2003 19:38:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06396 for ; Sun, 26 Oct 2003 19:38:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADvOy-0003Qz-00 for nemo@ietf.org; Sun, 26 Oct 2003 19:38:32 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ADvOy-0003QW-00 for nemo@ietf.org; Sun, 26 Oct 2003 19:38:32 -0500 Received: from [64.36.73.242] (home2.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h9R0ciMU090711; Sun, 26 Oct 2003 16:38:47 -0800 (PST) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 26 Oct 2003 16:38:13 -0800 Subject: Re: [nemo] 58th IETF meeting From: "T.J. Kniveton" To: Eranga Perera , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 10/26/03 3:56 PM, "Eranga Perera" wrote: > Hi, > Will there be any NEMO related discussions at the 58th IETF meeting? > Cheers > Eranga > > > Yes! http://www.ietf.org/meetings/agenda_58.html check wednesday afternoon. -TJ From nemo-admin@ietf.org Sun Oct 26 19:53:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06618 for ; Sun, 26 Oct 2003 19:53:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADvcz-0005M7-Ed; Sun, 26 Oct 2003 19:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADvcp-0005LD-OQ for nemo@optimus.ietf.org; Sun, 26 Oct 2003 19:52:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06610 for ; Sun, 26 Oct 2003 19:52:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADvcn-0003aA-00 for nemo@ietf.org; Sun, 26 Oct 2003 19:52:49 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1ADvcn-0003a6-00 for nemo@ietf.org; Sun, 26 Oct 2003 19:52:49 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h9R0qlUC000295 for ; Mon, 27 Oct 2003 09:52:47 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h9R0qlpo019980 for ; Mon, 27 Oct 2003 09:52:47 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h9R0qk8H018882 for ; Mon, 27 Oct 2003 09:52:46 +0900 (JST) Received: from imd.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id JAA09939 for ; Mon, 27 Oct 2003 09:52:46 +0900 (JST) Received: from [127.0.0.1] by imd.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id JAA06139 for ; Mon, 27 Oct 2003 09:52:45 +0900 (JST) Date: Mon, 27 Oct 2003 09:57:21 +0900 From: Hiroyuki OHNISHI To: nemo@ietf.org Message-Id: <20031027094656.29F5.OHNISHI.HIROYUKI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Subject: [nemo] RO draft(draft-ohnishi-nemo-ro-hmip-00.txt) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, I have submitted a draft on HMIP based Route optimization method in a mobile network. This draft proposes an approach similar to the mechanism specified in HMIPv6 to shortcut the HAs of MRs. I'd like to get some feedback. The URL for the draft is : http://www.ietf.org/internet-drafts/draft-ohnishi-nemo-ro-hmip-00.txt -- Hiroyuki OHNISHI NTT Network Service Systems Laboratories Phone: +81-422-59-4132, Fax: +81-422-60-7460 mailto: ohnishi.hiroyuki@lab.ntt.co.jp From exim@www1.ietf.org Sun Oct 26 19:53:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06634 for ; Sun, 26 Oct 2003 19:53:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADvd3-0005N3-Aw for nemo-archive@odin.ietf.org; Sun, 26 Oct 2003 19:53:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9R0r5xw020639 for nemo-archive@odin.ietf.org; Sun, 26 Oct 2003 19:53:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADvd3-0005Mo-3S for nemo-web-archive@optimus.ietf.org; Sun, 26 Oct 2003 19:53:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06614 for ; Sun, 26 Oct 2003 19:52:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADvd1-0003aK-00 for nemo-web-archive@ietf.org; Sun, 26 Oct 2003 19:53:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADvd0-0003aG-00 for nemo-web-archive@ietf.org; Sun, 26 Oct 2003 19:53:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADvcz-0005M7-Ed; Sun, 26 Oct 2003 19:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADvcp-0005LD-OQ for nemo@optimus.ietf.org; Sun, 26 Oct 2003 19:52:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06610 for ; Sun, 26 Oct 2003 19:52:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADvcn-0003aA-00 for nemo@ietf.org; Sun, 26 Oct 2003 19:52:49 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1ADvcn-0003a6-00 for nemo@ietf.org; Sun, 26 Oct 2003 19:52:49 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h9R0qlUC000295 for ; Mon, 27 Oct 2003 09:52:47 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h9R0qlpo019980 for ; Mon, 27 Oct 2003 09:52:47 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h9R0qk8H018882 for ; Mon, 27 Oct 2003 09:52:46 +0900 (JST) Received: from imd.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id JAA09939 for ; Mon, 27 Oct 2003 09:52:46 +0900 (JST) Received: from [127.0.0.1] by imd.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id JAA06139 for ; Mon, 27 Oct 2003 09:52:45 +0900 (JST) Date: Mon, 27 Oct 2003 09:57:21 +0900 From: Hiroyuki OHNISHI To: nemo@ietf.org Message-Id: <20031027094656.29F5.OHNISHI.HIROYUKI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Subject: [nemo] RO draft(draft-ohnishi-nemo-ro-hmip-00.txt) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, I have submitted a draft on HMIP based Route optimization method in a mobile network. This draft proposes an approach similar to the mechanism specified in HMIPv6 to shortcut the HAs of MRs. I'd like to get some feedback. The URL for the draft is : http://www.ietf.org/internet-drafts/draft-ohnishi-nemo-ro-hmip-00.txt -- Hiroyuki OHNISHI NTT Network Service Systems Laboratories Phone: +81-422-59-4132, Fax: +81-422-60-7460 mailto: ohnishi.hiroyuki@lab.ntt.co.jp From nemo-admin@ietf.org Sun Oct 26 22:16:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09857 for ; Sun, 26 Oct 2003 22:16:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADxrN-0008BO-Vs; Sun, 26 Oct 2003 22:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADxrE-0008AK-QA for nemo@optimus.ietf.org; Sun, 26 Oct 2003 22:15:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09823 for ; Sun, 26 Oct 2003 22:15:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADxrB-0005Em-00 for nemo@ietf.org; Sun, 26 Oct 2003 22:15:49 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1ADxrA-0005EA-00 for nemo@ietf.org; Sun, 26 Oct 2003 22:15:48 -0500 Received: from huez (net56-dhcp-760.sfc.keio.ac.jp [133.27.59.248]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 485455D084; Mon, 27 Oct 2003 12:15:17 +0900 (JST) Date: Mon, 27 Oct 2003 12:14:31 +0900 From: Thierry Ernst To: nemo Cc: tj Message-Id: <20031027121431.62a3eab6.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Mon__27_Oct_2003_12:14:31_+0900_08299b40" Subject: [nemo] Draft Agenda for 58th IETF Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Multipart_Mon__27_Oct_2003_12:14:31_+0900_08299b40 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dear all, Here follows a draft agenda for next meeting. We assume discussions will be raised on the ML prior to the meeting for all the agenda items so that our meeting is efficient. The agenda lists a number of drafts attendees are assumed to have read prior to the meeting. For transparency and for the interest of the IETF participants, we also list all the other drafts submitted to the WG. If you have been submitted a draft to the NEMO WG that is not listed below, please let us know. However, if the draft does not attend to address one of the below listed issue, this will not grant a slot unless there is a significant discussion going on on the ML. We will update the agenda based on your input. Regards, Thierry. --Multipart_Mon__27_Oct_2003_12:14:31_+0900_08299b40 Content-Type: text/plain; name="nemo-agenda-ietf58.txt" Content-Disposition: attachment; filename="nemo-agenda-ietf58.txt" Content-Transfer-Encoding: 7bit # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # NEMO WG Draft Agenda 58th IETF, Nov.03 Chairs: Thierry Ernst T.J. Kniveton IETF web page: http://www.ietf.org/html.charters/nemo-charter.html Additional Web Page: http://www.mobilenetworks.org/nemo/ # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ o Agenda Bashing ............................................ 5 mins Chairs o NEMO status and milestones ................................ 5 mins Chairs o NEMO Basic Support ....................................... 15 mins Vijay Devarapalli ? draft-ietf-nemo-basic-support-01.txt http://people.nokia.net/vijayd/nemo/issues.html This slot will cover the following points: - draft update - issues solved since last IETF - remaining Issues o NEMO Basic Support Additional Documents .................. 15 mins Pascal Thubert ? draft-thubert-nemo-basic-usages-00.txt The DT came to the conclusion that some clarifications about the NEMO Basic Support specification need to be made in separate drafts: - usages - ??? o IPR Status.................................................15 mins TJ Kniveton IPRs concerns from CISCO have been raised since before last 57thIETF meeting in Wien. o Multihoming ...............................................15 mins draft-ng-nemo-multihoming-issues-01.txt draft-charbon-nemo-multihoming-evaluation-01.txt This slot should address the following points: - what scenarios must be supported in NEMO Basic Support - what are multihoming issues in NEMO Basic Support - at 57th IETF Wien, the WG decided to add multihoming as a WG document. However, we have not yet decided what specific items this document should include. o Threat Analysis Discussion ............................... 15 mins draft-jung-nemo-threat-analysis-01.txt draft-???? This slot should address the following points: - what are the potential threats in NEMO Basic Support - how are we going to proceed with this WG item o MIB....................................................... 10 mins We don't yet have any contribution on this WG item. How should we proceed ? o Terminology and Requirements Updates.......................10 mins draft-ietf-nemo-requirements-01.txt draft-ietf-nemo-terminology-00.txt Thierry Ernst o Conclusion and next steps.................................. 5 mins # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Internet Drafts Submitted to the NEMO WG All drafts available directly from http://www.mobilenetworks.org/nemo/ or from the IETF web page: http://www.ietf.org/internet-drafts/ # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ o Must Read List for this meeting: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - draft-ietf-nemo-terminology-00.txt Network Mobility Support Terminology May 03 - draft-ietf-nemo-requirements-01.txt Network Mobility Support Goals and Requirements May 03 - draft-ietf-nemo-basic-support-01.txt Nemo Basic Support Protocol Sept.03 - draft-ng-nemo-multihoming-issues-02.txt Multi-Homing Issues in Bi-directional Tunneling Oct.03 - draft-charbon-nemo-multihoming-evaluation-00.txt Evaluating Multi-homing Support in NEMO Basic Solution July 03 - draft-paik-nemo-multihoming-problem-00.txt> Multihomed Mobile Networks Problem Statements Oct. 03 - draft-jung-nemo-threat-analysis-01.txt Threat Analysis for NEMO Oct. 03 - draft-thubert-nemo-basic-usages-00.txt o Other drafts advertised on the NEMO ML (not in today's agenda): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - draft-droms-nemo-dhcpv6-pd-00.txt DHCPv6 Prefix Delegation for NEMO June 03 - draft-hkang-nemo-ro-tlmr-00.txt Route Optimization for Mobile Network by Using Bi-directional Between Home Agent and Top Level Mobile Router June 03 - draft-jeong-nemo-ro-ndproxy-01.txt ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network Oct.03 - draft-lach-nemo-experiments-overdrive-00.txt Laboratory and "Field" Experiments with IPv6 Mobile Networks in Vehicular Environments June 03 - draft-leekj-nemo-ro-pd-01.txt Route Optimization for Mobile Nodes in Mobile Network based on Prefix Delegation Oct.03 - draft-na-nemo-nested-path-info-00 Secure Nested Tunnels Optimization using Nested Path Information Sept.03 - draft-ohnishi-nemo-ro-hmip-00.txt HMIP based Route optimization method in a mobile network Oct.03 - draft-paakkonen-nemo-prefix-delegation-00.txt Mobile Network Prefix Delegation extension for Mobile IPv6 March 03 - draft-perera-nemo-extended-00.txt Extended Network Mobility Support July 03 - draft-thubert-nemo-ipv4-traversal-01.txt IPv4 traversal for MIPv6 based Mobile Routers May 03 - draft-thubert-nemo-ro-taxonomy-01.txt Taxonomy of Route Optimization models in the Nemo Context June 03 - draft-thubert-nemo-reverse-routing-header-03 IPv6 Reverse Routing Header and its application to Mobile Networks Oct. 03 - draft-wakikawa-mip6-nemo-haha-00.txt Inter Home Agents Protocol (HAHA) Oct. 03 o Related drafts ~~~~~~~~~~~~~~ - draft-ohta-multihomed-isps-00.txt - draft-park-mobileip-wifi-handover-00.txt The chairs. --Multipart_Mon__27_Oct_2003_12:14:31_+0900_08299b40-- From exim@www1.ietf.org Sun Oct 26 22:16:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09876 for ; Sun, 26 Oct 2003 22:16:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADxrS-0008Fc-SN for nemo-archive@odin.ietf.org; Sun, 26 Oct 2003 22:16:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9R3G6kr031710 for nemo-archive@odin.ietf.org; Sun, 26 Oct 2003 22:16:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADxrS-0008FN-NC for nemo-web-archive@optimus.ietf.org; Sun, 26 Oct 2003 22:16:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09835 for ; Sun, 26 Oct 2003 22:15:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADxrP-0005Ez-00 for nemo-web-archive@ietf.org; Sun, 26 Oct 2003 22:16:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADxrP-0005Ev-00 for nemo-web-archive@ietf.org; Sun, 26 Oct 2003 22:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADxrN-0008BO-Vs; Sun, 26 Oct 2003 22:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADxrE-0008AK-QA for nemo@optimus.ietf.org; Sun, 26 Oct 2003 22:15:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09823 for ; Sun, 26 Oct 2003 22:15:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADxrB-0005Em-00 for nemo@ietf.org; Sun, 26 Oct 2003 22:15:49 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1ADxrA-0005EA-00 for nemo@ietf.org; Sun, 26 Oct 2003 22:15:48 -0500 Received: from huez (net56-dhcp-760.sfc.keio.ac.jp [133.27.59.248]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 485455D084; Mon, 27 Oct 2003 12:15:17 +0900 (JST) Date: Mon, 27 Oct 2003 12:14:31 +0900 From: Thierry Ernst To: nemo Cc: tj Message-Id: <20031027121431.62a3eab6.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Mon__27_Oct_2003_12:14:31_+0900_08299b40" Subject: [nemo] Draft Agenda for 58th IETF Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Multipart_Mon__27_Oct_2003_12:14:31_+0900_08299b40 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dear all, Here follows a draft agenda for next meeting. We assume discussions will be raised on the ML prior to the meeting for all the agenda items so that our meeting is efficient. The agenda lists a number of drafts attendees are assumed to have read prior to the meeting. For transparency and for the interest of the IETF participants, we also list all the other drafts submitted to the WG. If you have been submitted a draft to the NEMO WG that is not listed below, please let us know. However, if the draft does not attend to address one of the below listed issue, this will not grant a slot unless there is a significant discussion going on on the ML. We will update the agenda based on your input. Regards, Thierry. --Multipart_Mon__27_Oct_2003_12:14:31_+0900_08299b40 Content-Type: text/plain; name="nemo-agenda-ietf58.txt" Content-Disposition: attachment; filename="nemo-agenda-ietf58.txt" Content-Transfer-Encoding: 7bit # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # NEMO WG Draft Agenda 58th IETF, Nov.03 Chairs: Thierry Ernst T.J. Kniveton IETF web page: http://www.ietf.org/html.charters/nemo-charter.html Additional Web Page: http://www.mobilenetworks.org/nemo/ # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ o Agenda Bashing ............................................ 5 mins Chairs o NEMO status and milestones ................................ 5 mins Chairs o NEMO Basic Support ....................................... 15 mins Vijay Devarapalli ? draft-ietf-nemo-basic-support-01.txt http://people.nokia.net/vijayd/nemo/issues.html This slot will cover the following points: - draft update - issues solved since last IETF - remaining Issues o NEMO Basic Support Additional Documents .................. 15 mins Pascal Thubert ? draft-thubert-nemo-basic-usages-00.txt The DT came to the conclusion that some clarifications about the NEMO Basic Support specification need to be made in separate drafts: - usages - ??? o IPR Status.................................................15 mins TJ Kniveton IPRs concerns from CISCO have been raised since before last 57thIETF meeting in Wien. o Multihoming ...............................................15 mins draft-ng-nemo-multihoming-issues-01.txt draft-charbon-nemo-multihoming-evaluation-01.txt This slot should address the following points: - what scenarios must be supported in NEMO Basic Support - what are multihoming issues in NEMO Basic Support - at 57th IETF Wien, the WG decided to add multihoming as a WG document. However, we have not yet decided what specific items this document should include. o Threat Analysis Discussion ............................... 15 mins draft-jung-nemo-threat-analysis-01.txt draft-???? This slot should address the following points: - what are the potential threats in NEMO Basic Support - how are we going to proceed with this WG item o MIB....................................................... 10 mins We don't yet have any contribution on this WG item. How should we proceed ? o Terminology and Requirements Updates.......................10 mins draft-ietf-nemo-requirements-01.txt draft-ietf-nemo-terminology-00.txt Thierry Ernst o Conclusion and next steps.................................. 5 mins # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Internet Drafts Submitted to the NEMO WG All drafts available directly from http://www.mobilenetworks.org/nemo/ or from the IETF web page: http://www.ietf.org/internet-drafts/ # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ o Must Read List for this meeting: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - draft-ietf-nemo-terminology-00.txt Network Mobility Support Terminology May 03 - draft-ietf-nemo-requirements-01.txt Network Mobility Support Goals and Requirements May 03 - draft-ietf-nemo-basic-support-01.txt Nemo Basic Support Protocol Sept.03 - draft-ng-nemo-multihoming-issues-02.txt Multi-Homing Issues in Bi-directional Tunneling Oct.03 - draft-charbon-nemo-multihoming-evaluation-00.txt Evaluating Multi-homing Support in NEMO Basic Solution July 03 - draft-paik-nemo-multihoming-problem-00.txt> Multihomed Mobile Networks Problem Statements Oct. 03 - draft-jung-nemo-threat-analysis-01.txt Threat Analysis for NEMO Oct. 03 - draft-thubert-nemo-basic-usages-00.txt o Other drafts advertised on the NEMO ML (not in today's agenda): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - draft-droms-nemo-dhcpv6-pd-00.txt DHCPv6 Prefix Delegation for NEMO June 03 - draft-hkang-nemo-ro-tlmr-00.txt Route Optimization for Mobile Network by Using Bi-directional Between Home Agent and Top Level Mobile Router June 03 - draft-jeong-nemo-ro-ndproxy-01.txt ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network Oct.03 - draft-lach-nemo-experiments-overdrive-00.txt Laboratory and "Field" Experiments with IPv6 Mobile Networks in Vehicular Environments June 03 - draft-leekj-nemo-ro-pd-01.txt Route Optimization for Mobile Nodes in Mobile Network based on Prefix Delegation Oct.03 - draft-na-nemo-nested-path-info-00 Secure Nested Tunnels Optimization using Nested Path Information Sept.03 - draft-ohnishi-nemo-ro-hmip-00.txt HMIP based Route optimization method in a mobile network Oct.03 - draft-paakkonen-nemo-prefix-delegation-00.txt Mobile Network Prefix Delegation extension for Mobile IPv6 March 03 - draft-perera-nemo-extended-00.txt Extended Network Mobility Support July 03 - draft-thubert-nemo-ipv4-traversal-01.txt IPv4 traversal for MIPv6 based Mobile Routers May 03 - draft-thubert-nemo-ro-taxonomy-01.txt Taxonomy of Route Optimization models in the Nemo Context June 03 - draft-thubert-nemo-reverse-routing-header-03 IPv6 Reverse Routing Header and its application to Mobile Networks Oct. 03 - draft-wakikawa-mip6-nemo-haha-00.txt Inter Home Agents Protocol (HAHA) Oct. 03 o Related drafts ~~~~~~~~~~~~~~ - draft-ohta-multihomed-isps-00.txt - draft-park-mobileip-wifi-handover-00.txt The chairs. --Multipart_Mon__27_Oct_2003_12:14:31_+0900_08299b40-- From nemo-admin@ietf.org Sun Oct 26 22:30:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10260 for ; Sun, 26 Oct 2003 22:30:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADy4v-0000xJ-Aw; Sun, 26 Oct 2003 22:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADy3x-0000su-Vk for nemo@optimus.ietf.org; Sun, 26 Oct 2003 22:29:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10215 for ; Sun, 26 Oct 2003 22:28:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADy3u-0005NQ-00 for nemo@ietf.org; Sun, 26 Oct 2003 22:28:58 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ADy3t-0005NF-00 for nemo@ietf.org; Sun, 26 Oct 2003 22:28:58 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9R3SJZ20243; Sun, 26 Oct 2003 19:28:19 -0800 X-mProtect: <200310270328> Nokia Silicon Valley Messaging Protection Received: from danira-pool04897.americas.nokia.com (10.241.48.97, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6hA1fD; Sun, 26 Oct 2003 19:28:18 PST Message-ID: <3F9C90C7.1000904@iprg.nokia.com> Date: Sun, 26 Oct 2003 19:28:07 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst CC: tj , Ryuji Wakikawa , nemo@ietf.org Subject: Re: [nemo] Draft Agenda for 58th IETF References: <20031027121431.62a3eab6.ernst@sfc.wide.ad.jp> In-Reply-To: <20031027121431.62a3eab6.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit can we have a short discussion on the Inter Home Agents protocol? I believe having a HAHA protocol enables a few scenarios for Nemo Basic Support deployment which would otherwise be not possible. the draft is at http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-00.txt Vijay ps: Ryuji would present something if some time is alloted for this. Thierry Ernst wrote: > Dear all, > > Here follows a draft agenda for next meeting. We assume discussions > will be raised on the ML prior to the meeting for all the agenda > items so that our meeting is efficient. > > The agenda lists a number of drafts attendees are assumed to have read > prior to the meeting. For transparency and for the interest of the > IETF participants, we also list all the other drafts submitted to the > WG. If you have been submitted a draft to the NEMO WG that is not > listed below, please let us know. However, if the draft does not > attend to address one of the below listed issue, this will not grant a > slot unless there is a significant discussion going on on the ML. > > We will update the agenda based on your input. > > Regards, > Thierry. > > > ------------------------------------------------------------------------ > > > > # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > # NEMO WG Draft Agenda > 58th IETF, Nov.03 > Chairs: Thierry Ernst T.J. Kniveton > > IETF web page: http://www.ietf.org/html.charters/nemo-charter.html > Additional Web Page: http://www.mobilenetworks.org/nemo/ > # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > o Agenda Bashing ............................................ 5 mins > Chairs > > o NEMO status and milestones ................................ 5 mins > Chairs > > o NEMO Basic Support ....................................... 15 mins > Vijay Devarapalli ? > > draft-ietf-nemo-basic-support-01.txt > http://people.nokia.net/vijayd/nemo/issues.html > > This slot will cover the following points: > - draft update > - issues solved since last IETF > - remaining Issues > > > o NEMO Basic Support Additional Documents .................. 15 mins > Pascal Thubert ? > > draft-thubert-nemo-basic-usages-00.txt > > The DT came to the conclusion that some clarifications about > the NEMO Basic Support specification need to be made in separate > drafts: > - usages > - ??? > > o IPR Status.................................................15 mins > TJ Kniveton > > IPRs concerns from CISCO have been raised since before last > 57thIETF meeting in Wien. > > o Multihoming ...............................................15 mins > draft-ng-nemo-multihoming-issues-01.txt > draft-charbon-nemo-multihoming-evaluation-01.txt > > This slot should address the following points: > - what scenarios must be supported in NEMO Basic Support > - what are multihoming issues in NEMO Basic Support > - at 57th IETF Wien, the WG decided to add multihoming as a > WG document. However, we have not yet decided what specific > items this document should include. > > o Threat Analysis Discussion ............................... 15 mins > draft-jung-nemo-threat-analysis-01.txt > draft-???? > > This slot should address the following points: > - what are the potential threats in NEMO Basic Support > - how are we going to proceed with this WG item > > > o MIB....................................................... 10 mins > > We don't yet have any contribution on this WG item. How should we > proceed ? > > o Terminology and Requirements Updates.......................10 mins > draft-ietf-nemo-requirements-01.txt > draft-ietf-nemo-terminology-00.txt > Thierry Ernst > > o Conclusion and next steps.................................. 5 mins > > > > # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > # Internet Drafts Submitted to the NEMO WG > All drafts available directly from http://www.mobilenetworks.org/nemo/ > or from the IETF web page: http://www.ietf.org/internet-drafts/ > # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > o Must Read List for this meeting: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > - draft-ietf-nemo-terminology-00.txt > Network Mobility Support Terminology > May 03 > > - draft-ietf-nemo-requirements-01.txt > Network Mobility Support Goals and Requirements > May 03 > > - draft-ietf-nemo-basic-support-01.txt > Nemo Basic Support Protocol > Sept.03 > > - draft-ng-nemo-multihoming-issues-02.txt > Multi-Homing Issues in Bi-directional Tunneling > Oct.03 > > - draft-charbon-nemo-multihoming-evaluation-00.txt > Evaluating Multi-homing Support in NEMO Basic Solution > July 03 > > - draft-paik-nemo-multihoming-problem-00.txt> > Multihomed Mobile Networks Problem Statements > Oct. 03 > > - draft-jung-nemo-threat-analysis-01.txt > Threat Analysis for NEMO > Oct. 03 > > - draft-thubert-nemo-basic-usages-00.txt > > > o Other drafts advertised on the NEMO ML (not in today's agenda): > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > - draft-droms-nemo-dhcpv6-pd-00.txt > DHCPv6 Prefix Delegation for NEMO > June 03 > > - draft-hkang-nemo-ro-tlmr-00.txt > Route Optimization for Mobile Network by Using Bi-directional > Between Home Agent and Top Level Mobile Router > June 03 > > - draft-jeong-nemo-ro-ndproxy-01.txt > ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network > Oct.03 > > - draft-lach-nemo-experiments-overdrive-00.txt > Laboratory and "Field" Experiments with IPv6 Mobile Networks > in Vehicular Environments > June 03 > > - draft-leekj-nemo-ro-pd-01.txt > Route Optimization for Mobile Nodes in Mobile Network > based on Prefix Delegation > Oct.03 > > - draft-na-nemo-nested-path-info-00 > Secure Nested Tunnels Optimization using Nested Path Information > Sept.03 > > - draft-ohnishi-nemo-ro-hmip-00.txt > HMIP based Route optimization method in a mobile network > Oct.03 > > - draft-paakkonen-nemo-prefix-delegation-00.txt > Mobile Network Prefix Delegation extension for Mobile IPv6 > March 03 > > - draft-perera-nemo-extended-00.txt > Extended Network Mobility Support > July 03 > > - draft-thubert-nemo-ipv4-traversal-01.txt > IPv4 traversal for MIPv6 based Mobile Routers > May 03 > > - draft-thubert-nemo-ro-taxonomy-01.txt > Taxonomy of Route Optimization models in the Nemo Context > June 03 > > - draft-thubert-nemo-reverse-routing-header-03 > IPv6 Reverse Routing Header and its application to Mobile Networks > Oct. 03 > > - draft-wakikawa-mip6-nemo-haha-00.txt > Inter Home Agents Protocol (HAHA) > Oct. 03 > > o Related drafts > ~~~~~~~~~~~~~~ > - draft-ohta-multihomed-isps-00.txt > - draft-park-mobileip-wifi-handover-00.txt > > > The chairs. > > From exim@www1.ietf.org Sun Oct 26 22:30:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10276 for ; Sun, 26 Oct 2003 22:30:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADy4y-0000yt-Qs for nemo-archive@odin.ietf.org; Sun, 26 Oct 2003 22:30:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9R3U4Uh003772 for nemo-archive@odin.ietf.org; Sun, 26 Oct 2003 22:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADy4y-0000yl-Kh for nemo-web-archive@optimus.ietf.org; Sun, 26 Oct 2003 22:30:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10252 for ; Sun, 26 Oct 2003 22:29:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADy4v-0005Pl-00 for nemo-web-archive@ietf.org; Sun, 26 Oct 2003 22:30:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADy4u-0005Pi-00 for nemo-web-archive@ietf.org; Sun, 26 Oct 2003 22:30:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADy4v-0000xJ-Aw; Sun, 26 Oct 2003 22:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADy3x-0000su-Vk for nemo@optimus.ietf.org; Sun, 26 Oct 2003 22:29:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10215 for ; Sun, 26 Oct 2003 22:28:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADy3u-0005NQ-00 for nemo@ietf.org; Sun, 26 Oct 2003 22:28:58 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ADy3t-0005NF-00 for nemo@ietf.org; Sun, 26 Oct 2003 22:28:58 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9R3SJZ20243; Sun, 26 Oct 2003 19:28:19 -0800 X-mProtect: <200310270328> Nokia Silicon Valley Messaging Protection Received: from danira-pool04897.americas.nokia.com (10.241.48.97, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6hA1fD; Sun, 26 Oct 2003 19:28:18 PST Message-ID: <3F9C90C7.1000904@iprg.nokia.com> Date: Sun, 26 Oct 2003 19:28:07 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst CC: tj , Ryuji Wakikawa , nemo@ietf.org Subject: Re: [nemo] Draft Agenda for 58th IETF References: <20031027121431.62a3eab6.ernst@sfc.wide.ad.jp> In-Reply-To: <20031027121431.62a3eab6.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit can we have a short discussion on the Inter Home Agents protocol? I believe having a HAHA protocol enables a few scenarios for Nemo Basic Support deployment which would otherwise be not possible. the draft is at http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-00.txt Vijay ps: Ryuji would present something if some time is alloted for this. Thierry Ernst wrote: > Dear all, > > Here follows a draft agenda for next meeting. We assume discussions > will be raised on the ML prior to the meeting for all the agenda > items so that our meeting is efficient. > > The agenda lists a number of drafts attendees are assumed to have read > prior to the meeting. For transparency and for the interest of the > IETF participants, we also list all the other drafts submitted to the > WG. If you have been submitted a draft to the NEMO WG that is not > listed below, please let us know. However, if the draft does not > attend to address one of the below listed issue, this will not grant a > slot unless there is a significant discussion going on on the ML. > > We will update the agenda based on your input. > > Regards, > Thierry. > > > ------------------------------------------------------------------------ > > > > # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > # NEMO WG Draft Agenda > 58th IETF, Nov.03 > Chairs: Thierry Ernst T.J. Kniveton > > IETF web page: http://www.ietf.org/html.charters/nemo-charter.html > Additional Web Page: http://www.mobilenetworks.org/nemo/ > # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > o Agenda Bashing ............................................ 5 mins > Chairs > > o NEMO status and milestones ................................ 5 mins > Chairs > > o NEMO Basic Support ....................................... 15 mins > Vijay Devarapalli ? > > draft-ietf-nemo-basic-support-01.txt > http://people.nokia.net/vijayd/nemo/issues.html > > This slot will cover the following points: > - draft update > - issues solved since last IETF > - remaining Issues > > > o NEMO Basic Support Additional Documents .................. 15 mins > Pascal Thubert ? > > draft-thubert-nemo-basic-usages-00.txt > > The DT came to the conclusion that some clarifications about > the NEMO Basic Support specification need to be made in separate > drafts: > - usages > - ??? > > o IPR Status.................................................15 mins > TJ Kniveton > > IPRs concerns from CISCO have been raised since before last > 57thIETF meeting in Wien. > > o Multihoming ...............................................15 mins > draft-ng-nemo-multihoming-issues-01.txt > draft-charbon-nemo-multihoming-evaluation-01.txt > > This slot should address the following points: > - what scenarios must be supported in NEMO Basic Support > - what are multihoming issues in NEMO Basic Support > - at 57th IETF Wien, the WG decided to add multihoming as a > WG document. However, we have not yet decided what specific > items this document should include. > > o Threat Analysis Discussion ............................... 15 mins > draft-jung-nemo-threat-analysis-01.txt > draft-???? > > This slot should address the following points: > - what are the potential threats in NEMO Basic Support > - how are we going to proceed with this WG item > > > o MIB....................................................... 10 mins > > We don't yet have any contribution on this WG item. How should we > proceed ? > > o Terminology and Requirements Updates.......................10 mins > draft-ietf-nemo-requirements-01.txt > draft-ietf-nemo-terminology-00.txt > Thierry Ernst > > o Conclusion and next steps.................................. 5 mins > > > > # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > # Internet Drafts Submitted to the NEMO WG > All drafts available directly from http://www.mobilenetworks.org/nemo/ > or from the IETF web page: http://www.ietf.org/internet-drafts/ > # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > o Must Read List for this meeting: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > - draft-ietf-nemo-terminology-00.txt > Network Mobility Support Terminology > May 03 > > - draft-ietf-nemo-requirements-01.txt > Network Mobility Support Goals and Requirements > May 03 > > - draft-ietf-nemo-basic-support-01.txt > Nemo Basic Support Protocol > Sept.03 > > - draft-ng-nemo-multihoming-issues-02.txt > Multi-Homing Issues in Bi-directional Tunneling > Oct.03 > > - draft-charbon-nemo-multihoming-evaluation-00.txt > Evaluating Multi-homing Support in NEMO Basic Solution > July 03 > > - draft-paik-nemo-multihoming-problem-00.txt> > Multihomed Mobile Networks Problem Statements > Oct. 03 > > - draft-jung-nemo-threat-analysis-01.txt > Threat Analysis for NEMO > Oct. 03 > > - draft-thubert-nemo-basic-usages-00.txt > > > o Other drafts advertised on the NEMO ML (not in today's agenda): > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > - draft-droms-nemo-dhcpv6-pd-00.txt > DHCPv6 Prefix Delegation for NEMO > June 03 > > - draft-hkang-nemo-ro-tlmr-00.txt > Route Optimization for Mobile Network by Using Bi-directional > Between Home Agent and Top Level Mobile Router > June 03 > > - draft-jeong-nemo-ro-ndproxy-01.txt > ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network > Oct.03 > > - draft-lach-nemo-experiments-overdrive-00.txt > Laboratory and "Field" Experiments with IPv6 Mobile Networks > in Vehicular Environments > June 03 > > - draft-leekj-nemo-ro-pd-01.txt > Route Optimization for Mobile Nodes in Mobile Network > based on Prefix Delegation > Oct.03 > > - draft-na-nemo-nested-path-info-00 > Secure Nested Tunnels Optimization using Nested Path Information > Sept.03 > > - draft-ohnishi-nemo-ro-hmip-00.txt > HMIP based Route optimization method in a mobile network > Oct.03 > > - draft-paakkonen-nemo-prefix-delegation-00.txt > Mobile Network Prefix Delegation extension for Mobile IPv6 > March 03 > > - draft-perera-nemo-extended-00.txt > Extended Network Mobility Support > July 03 > > - draft-thubert-nemo-ipv4-traversal-01.txt > IPv4 traversal for MIPv6 based Mobile Routers > May 03 > > - draft-thubert-nemo-ro-taxonomy-01.txt > Taxonomy of Route Optimization models in the Nemo Context > June 03 > > - draft-thubert-nemo-reverse-routing-header-03 > IPv6 Reverse Routing Header and its application to Mobile Networks > Oct. 03 > > - draft-wakikawa-mip6-nemo-haha-00.txt > Inter Home Agents Protocol (HAHA) > Oct. 03 > > o Related drafts > ~~~~~~~~~~~~~~ > - draft-ohta-multihomed-isps-00.txt > - draft-park-mobileip-wifi-handover-00.txt > > > The chairs. > > From nemo-admin@ietf.org Mon Oct 27 06:25:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07241 for ; Mon, 27 Oct 2003 06:25:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5Uc-0006Bm-Ob; Mon, 27 Oct 2003 06:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5UK-0006A4-EY for nemo@optimus.ietf.org; Mon, 27 Oct 2003 06:24:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07203 for ; Mon, 27 Oct 2003 06:24:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE5UG-0003Cy-00 for nemo@ietf.org; Mon, 27 Oct 2003 06:24:40 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AE5UF-0003Cb-00 for nemo@ietf.org; Mon, 27 Oct 2003 06:24:39 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h9RBGVRn004062 for ; Mon, 27 Oct 2003 19:16:31 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id B3C6910E95DA; Mon, 27 Oct 2003 19:25:29 +0800 (SGT) From: Chan-Wah Ng To: IETF NEMO WG Content-Type: multipart/mixed; boundary="=-OukMgnU2radnNH3Ig3+7" Organization: Panasonic Singapore Laboratories Message-Id: <1067253929.2748.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 27 Oct 2003 19:25:29 +0800 Subject: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --=-OukMgnU2radnNH3Ig3+7 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, NEMO ML, see the forwarded message for the new version of multihoming draft. Please take a look at it, and in a very short while, I will post a seed mail to gather comments and suggestions for moving forward. Thanks /rgds /cwng -----Forwarded Message----- From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt Date: Fri, 24 Oct 2003 10:37:04 -0400 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multi-Homing Issues in Bi-Directional Tunneling Author(s) : C. Ng, J. Charbon Filename : draft-ng-nemo-multihoming-issues-02.txt Pages : 32 Date : 2003-10-23 This document describes deployment scenario of multi-homed Network in Motion (NEMO) and attempts to identify issues that arises when supporting multi-homing in NEMO. It is also the objective of this document to build a full taxonomy covering multi-homed scenarios in NEMO, so as to facilitate explorations into this aspect of NEMO. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-02.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-ng-nemo-multihoming-issues-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ng-nemo-multihoming-issues-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ________________________________________________________________________ Content-Type: text/plain Content-ID: <2003-10-24102152.I-D@ietf.org> --=-OukMgnU2radnNH3Ig3+7 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6CTwyMDAzLTEwLTI0MTAyMTUyLkkt REBpZXRmLm9yZz4KCkVOQ09ESU5HIG1pbWUKRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW5n LW5lbW8tbXVsdGlob21pbmctaXNzdWVzLTAyLnR4dAo= --=-OukMgnU2radnNH3Ig3+7 Content-Type: Message/External-body; name="draft-ng-nemo-multihoming-issues-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6CTwyMDAzLTEwLTI0MTAyMTUyLkkt REBpZXRmLm9yZz4K --=-OukMgnU2radnNH3Ig3+7-- From exim@www1.ietf.org Mon Oct 27 06:25:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07286 for ; Mon, 27 Oct 2003 06:25:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5Uj-0006E5-KA for nemo-archive@odin.ietf.org; Mon, 27 Oct 2003 06:25:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RBP9c1023927 for nemo-archive@odin.ietf.org; Mon, 27 Oct 2003 06:25:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5Uj-0006D8-C0 for nemo-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 06:25:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07220 for ; Mon, 27 Oct 2003 06:24:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE5Uf-0003DP-00 for nemo-web-archive@ietf.org; Mon, 27 Oct 2003 06:25:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE5Uf-0003DM-00 for nemo-web-archive@ietf.org; Mon, 27 Oct 2003 06:25:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5Uc-0006Bm-Ob; Mon, 27 Oct 2003 06:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5UK-0006A4-EY for nemo@optimus.ietf.org; Mon, 27 Oct 2003 06:24:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07203 for ; Mon, 27 Oct 2003 06:24:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE5UG-0003Cy-00 for nemo@ietf.org; Mon, 27 Oct 2003 06:24:40 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AE5UF-0003Cb-00 for nemo@ietf.org; Mon, 27 Oct 2003 06:24:39 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h9RBGVRn004062 for ; Mon, 27 Oct 2003 19:16:31 +0800 (SGT) Received: by beethoven.psl.com.sg (Postfix, from userid 1000) id B3C6910E95DA; Mon, 27 Oct 2003 19:25:29 +0800 (SGT) From: Chan-Wah Ng To: IETF NEMO WG Content-Type: multipart/mixed; boundary="=-OukMgnU2radnNH3Ig3+7" Organization: Panasonic Singapore Laboratories Message-Id: <1067253929.2748.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 27 Oct 2003 19:25:29 +0800 Subject: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --=-OukMgnU2radnNH3Ig3+7 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, NEMO ML, see the forwarded message for the new version of multihoming draft. Please take a look at it, and in a very short while, I will post a seed mail to gather comments and suggestions for moving forward. Thanks /rgds /cwng -----Forwarded Message----- From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt Date: Fri, 24 Oct 2003 10:37:04 -0400 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multi-Homing Issues in Bi-Directional Tunneling Author(s) : C. Ng, J. Charbon Filename : draft-ng-nemo-multihoming-issues-02.txt Pages : 32 Date : 2003-10-23 This document describes deployment scenario of multi-homed Network in Motion (NEMO) and attempts to identify issues that arises when supporting multi-homing in NEMO. It is also the objective of this document to build a full taxonomy covering multi-homed scenarios in NEMO, so as to facilitate explorations into this aspect of NEMO. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-02.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-ng-nemo-multihoming-issues-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ng-nemo-multihoming-issues-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ________________________________________________________________________ Content-Type: text/plain Content-ID: <2003-10-24102152.I-D@ietf.org> --=-OukMgnU2radnNH3Ig3+7 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6CTwyMDAzLTEwLTI0MTAyMTUyLkkt REBpZXRmLm9yZz4KCkVOQ09ESU5HIG1pbWUKRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW5n LW5lbW8tbXVsdGlob21pbmctaXNzdWVzLTAyLnR4dAo= --=-OukMgnU2radnNH3Ig3+7 Content-Type: Message/External-body; name="draft-ng-nemo-multihoming-issues-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6CTwyMDAzLTEwLTI0MTAyMTUyLkkt REBpZXRmLm9yZz4K --=-OukMgnU2radnNH3Ig3+7-- From nemo-admin@ietf.org Mon Oct 27 09:56:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17234 for ; Mon, 27 Oct 2003 09:56:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8mo-0002du-Jc; Mon, 27 Oct 2003 09:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8mb-0002ci-IW for nemo@optimus.ietf.org; Mon, 27 Oct 2003 09:55:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17205 for ; Mon, 27 Oct 2003 09:55:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE8mZ-00067t-00 for nemo@ietf.org; Mon, 27 Oct 2003 09:55:47 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1AE8mY-00067q-00 for nemo@ietf.org; Mon, 27 Oct 2003 09:55:46 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h9REtjEI005370 for ; Mon, 27 Oct 2003 07:55:45 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h9REs8Qe004499 for ; Mon, 27 Oct 2003 08:54:09 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 707052EC98; Mon, 27 Oct 2003 15:41:47 +0100 (CET) Message-ID: <3F9D2EAB.2070505@motorola.com> Date: Mon, 27 Oct 2003 15:41:47 +0100 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@ietf.org Cc: Hong-Yon Lach X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------060002060205030402040809" Subject: [nemo] draft on Experiments with NEMO Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------060002060205030402040809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello to NEMO WG, We've just submitted a draft update on experiments with an IPv6 mobile network attaching to HotSpot WLAN and Orange GPRS, for vehicular environments. draft-lach-nemo-experiments-overdrive-01.txt I attach the draft, and will put it on the website soon. We would like to request a short slot at the meeting (5-7 minutes); in case it is approved HYL might present. Thanks in advance, Alex GBU --------------060002060205030402040809 Content-Type: text/plain; name="draft-lach-nemo-experiments-overdrive-01.txt" Content-Disposition: inline; filename="draft-lach-nemo-experiments-overdrive-01.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by motgate.mot.com id h9REtjEI005370 Content-Transfer-Encoding: quoted-printable Internet Draft Hong-Yon Lach draft-lach-nemo-experiments-overdrive-01.txt Christophe Janneteau Expires: April 2003 Alexis Olivereau = =20 Alexandru Petrescu Motorola Tim Leinmueller Michael M. Wolf DaimlerChrysler Markus Pilz University of Bonn =20 October 2003 =20 =20 Laboratory and "Field" Experiments with IPv6 Mobile Networks in Vehicular Environments =20 Status of this Nemo=20 =20 This document is an Internet-Draft and is in full conformance=20 with all provisions of Section 10 of RFC2026.=20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that =20 other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as=20 reference material or to cite them other than as "work in progress." =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 Abstract=20 This document gives a short high-level overview of experiments performed with IPv6 mobile networks using Mobile IPv6-based NEMO extensions in the context of the IST OverDRiVE project. Laboratory experiments include simple and nested mobile networks in a pure IPv6 environment while "field" experiments demonstrated continuous IPv6 vehicular connectivity over two publicly deployed IPv4 networks: 2.5G (GPRS) and Wireless LAN 802.11b deployed around and inside a metropolitan area. Lessons learned included the necessity for Route Optimization protocols for mobile networks, NAT traversal and IPv4-to-IPv6 transition protocols in public access wireless networks. Lach, et al. Expires April 2003 [Page 1] =0C Internet Draft OverDRiVE Experiments 23 June 2003 Table of Contents=20 =20 Status of this Nemo................................................1 Abstract...........................................................1 Conventions Used in this Document..................................2 1. IST OverDRiVE Project...........................................2 2. Laboratory Experiments..........................................3 3. "Field" Experiments.............................................6 4. Conclusions and Future Work....................................10 Acknowledgements..................................................10 References........................................................11 Authors' Addresses................................................12 Changes...........................................................12 Copyright Notice..................................................13 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC-2119 [1].=20 =20 1. IST OverDRiVE Project Work Package 3 of the European research project OverDRiVE [3] aims at developing IPv6 protocol mechanisms to support mobility of hosts, as well as of networks, that are deployed in vehicular environments. The scenarios envision that future vehicular environments in trains, ships or vehicles provide on-line information to the driver and passengers; provide even access to the vehicular communication components from the outside world (e.g. allow for software downloads be pushed to car computers). All electronic devices deployed in a vehicle (PCs, head screens, engine computers and sensors) are connected together with IPv6 protocols, and to the IPv6 Internet; the connection is realized either directly or through other IPv4 tunneling and gatewaying means. The project has defined a set of scenarios which should be supported by a mobility (and security) solution [8]. The following two major characteristics are valid for all scenarios: - Session continuity while changing the point of attachment to the Internet. - Reachability of the mobile nodes regardless of the current point of attachment. Thus, several functional scenarios become relevant: - Moving of an Intra-Vehicular Area Network (IVAN): the IVAN moves homogeneously (network entities stay together) using a mobile router to provide the Internet connectivity for nodes within the IVAN. - Moving into an IVAN with a mobile device. The mobile host moves into an IVAN and changes its WMAN connection to a WLAN connection, or its UMTS connection to a Bluetooth connection. - Moving within an IVAN: in a larger IVAN (e.g. in a train) topological hierarchies might be used, involving more than one fixed (with respect to IVAN) or mobile router. Mobile nodes can move around inside the IVAN connecting to the appropriate access router inside the IVAN. Lach, et al. Expires April 2003 [Page 2] =0C Internet Draft OverDRiVE Experiments 23 June 2003 2. Laboratory Experiments Several laboratory experiments in a pure IPv6 network were performed with mobile hosts and mobile networks. In some scenarios, more than one Local Fixed Node and one Correspondent Node were used; for example, in some scenarios there is an additional Mobile Host, or there are two mobile networks each hosting a Local Fixed Node. During all experiments, the mobility management messaging (between MR and HA, or between MH and HA) was not interrupting the end-to-end communication between these entities, even if several changes in Care-of Address were occuring. The end-to-end communications were happening between the LFN and the CN, or between two LFN's, or between one MH and one LFN, or between one MH and one CN. The CN's used were local video streaming servers and other servers connected on other parts of the worldwide IPv6 Internet. A simple mobile network is composed of one Mobile Router and one Local Fixed Node, see Figure 1. The mobile network is initially attached at home and moves subsequently to Access Router AR1 and AR2. ---- CN link =20 --| BR1|------ =20 ---- / ---- | =20 | HA | / ----=20 ---- ----------/ | CN | =20 | ------- | | ---- =20 ----------------| BR |---| Network |-------------- = =20 | home link ------- | | | =20 ---- ----- ----------\ | =20 | MR | | LFN | \ | =20 ---- ----- \ | | | ------ ------ --------- | AR1 | | AR2 | =20 mobile net link ------ ------=20 | | =20 Figure 1: Simple Mobile Network Figure 2 depicts another setting with one Mobile Router, one Mobile Host, same Home Agent. In a first scenario, the mobile network starts at home and then moves under AR1 and AR2. The Mobile Host stays at home. Lach, et al. Expires April 2003 [Page 3] =0C Internet Draft OverDRiVE Experiments 23 June 2003 Related to the same figure, another scenario is that the mobile network and the mobile hosts are first placed at home and then the mobile host moves under the mobile network. Subsequently the mobile network moves together with the mobile host under AR1 and AR2. And still with the same figure, yet another scenario; every entity is at home, then MH moves under AR1, then the mobile network moves too under AR1; then MH moves towards the mobile network and, finally, the mobile network moves to AR2. ---- CN link=20 --| BR1|------ =20 ---- ---- / ---- | =20 | HA | | MH | / ---- =20 ---- ---- ----------/ | CN | =20 | | ------- | | ---- =20 ----------------| BR |---| Network |-------------- =20 | home link ------- | | | =20 ---- ----- ----------\ | =20 | MR | | LFN | \ | =20 ---- ----- \ | =20 | | ------ ------=20 --------- | AR1 | | AR2 | mobile net link ------ ------=20 | | =20 Figure 2: Mobile Router and Mobile Host at Home Figure 3 shows a setting where the mobile router and the mobile host have different Home Agents. Various movements were performed. ---- --| CN | ---- / ---- ---- ---- =20 | HA1| / | HA2| | MH | =20 ---- ----------/ ---- ---- | ------- | | ------- | | =20 ----------------| BR |---| Network |-----| BR |-------------- | home link ------- | | ------- =20 ---- ----- ----------\ =20 | MR | | LFN | \ =20 ---- ----- \ =20 | | ------=20 --------- | AR1 | mobile net link ------=20 | =20 Figure 3: Mobile Network and Mobile Host with Different Homes In figure 4, the Mobile Host and the Mobile Router have two different Home Agents, both situated on the same home link. Various movements were performed. Lach, et al. Expires April 2003 [Page 4] =0C Internet Draft OverDRiVE Experiments 23 June 2003 ---- CN link =20 --| BR1|------ =20 ---- ---- ---- / ---- | =20 | HA1| | HA2| | MH | / ---- =20 ---- ---- ---- ----------/ | CN | =20 | | | ------- | | ---- =20 -------------------| BR |---| Network |-------------- =20 | home link ------- | | | =20 ---- ----- ----------\ | =20 | MR | | LFN | \ | =20 ---- ----- \ | =20 | | ------ ------ =20 --------- | AR1 | | AR2 |=20 mobile net link ------ ------ =20 | | =20 Figure 4: Home Agents on the Same Home Link In figure 5, one Home Agent is placed in the mobile network. Various movements were performed. ---- CN link=20 --| BR1|------ =20 ---- / ---- | =20 | HA1| / ---- =20 ---- ----------/ | CN | =20 | ------- | | ---- =20 ----------------| BR |---| Network |-------------- =20 | home link ------- | | | =20 ---- ----- ----------\ | =20 | MR | | LFN | \ | =20 ---- ----- \ | =20 | | ------ ------=20 --------- | AR1 | | AR2 | | | ------ ------=20 ---- ---- | | =20 | HA2| | MH | ---- ----=20 Figure 5: Home Agent in the Mobile Network An additional range of laboratory experiments were performed and reported in section 2.4 of [8]. Examples include: -a single Home Agent and two similar mobile networks, each composed of one Mobile Router and one Local Fixed Node. -two Home Agents and two Mobile Routers (one Home Agent for one mobile network), but still one home link. -two Home Agents and two Mobile Routers (one Home Agent for one mobile network), but on different home links. -a Home Agent placed inside a mobile network serving another mobile network attached to the first. Lach, et al. Expires April 2003 [Page 5] =0C Internet Draft OverDRiVE Experiments 23 June 2003 The descriptions in section 2.4 of [8] include details of tunnel setup procedures and illustrations of MN-HA encapsulations, as well as packet paths between various entities. The laboratory experiments helped highlighting several areas for protocol improvement of the basic support of network mobility: -Excessive tunnelling ("thick" tunnels): when MH attaches to the mobile network there are two MRHA encapsulating tunnels involved in the CN-MH path. Several levels of mobile networks induce excessive tunnelling that can lead to serious packet loss and worsen stack behaviour due to excessive fragmentation/reassembly. This is especially true in wireless environments. -Crossover tunnels happen when the path between one tunnel's endpoints includes only one of the other tunnel's endpoints . A situation leading to crossover tunnels is depicted in Figure 16 of [8], where a HA is deployed inside a mobile network. The initial configuration is in diagram a and diagrams b, c and d represent snapshots of the movement scenario. The MR2HA2 tunnel setup procedure corresponding for the diagram d is practically impossible to perform. -Externally influenced intra-aggregation communication (or disconnected operation problem): in the MH and MR with same HA case, depicted in diagram c of Figure 12 of [8], the LFN-MH communication (intra-aggregation) is influenced by the communication between MR and AR1 (external). If MR looses connection to AR1, then LFN looses connection to MH, a fact that, as paradoxical as it may seem, is a veritable side effect of tunnelling itself. -Under-optimal paths: when comparing the length of the CN-MH communication path depicted in top-left diagram of Figure 13 of [8] to the CN-MH communication in Figure 15 of [8], it is clear that the path taken by packets is much longer than the optimal. The first diagram can be considered as an ideal to be attained, and the only optimal path that can be achieved is CN-AR-MR-MH (eliminating the BR-HA-BR additional segment). This is not the ideal path (since MH is not physically home) but represents an achievable goal, if employing Route Optimization techniques. -Asymmetric communication paths: outgoing communication paths have different lengths than incoming communication paths, between the same two entities. See example in Figure 14 of [8]. 3. "Field" Experiments "Field" experiments were performed in a typical deployment of wireless networks. An overall picture of the experiments is described in Figure xx. Three wireless access networks are depicted: the home network (hosting the Home Agent), the Orange network (an European Telecom operator for mobile phones) and the Wixos network (a WiFi HotSpot network deployed in a large city). Lach, et al. Expires April 2003 [Page 6] =0C Internet Draft OverDRiVE Experiments 23 June 2003 The three networks are inter-connected at Internet level. The Mobile Network, pictured at the bottom, was obtaining Internet access via one of the three Wireless Access Networks. ------------ ----------- | Internet |-----------| Web Server| /------------\ ----------- / | \ / | \ / | \ -------- -------- ------- |Home Net| | Orange | | Wixos | -------- -------- ------- | | | Wireless Access WLAN GPRS | | ---------- |Mobile Net| ----------> ---------- Figure xx: Overall Picture of Field Experiments 3.2 Mobile Network The mobile network used in the field experiments is a very simple wireless segment (802.11b in ad-hoc mode) linking together an IPv6 Mobile Router and a Local Fixed Node running user applications (notably an http client). In addition, the mobile network contained two boxes helping interconnect the MR to the wireless access networks (FrontBoxes). Inside the mobile network, IPv6 protocols are used exclusively; the Mobile Router runs an implementation of Mobile IPv6 Mobile Router in implicit mode [2]. However, both Orange and Wixos offer IPv4 access exclusively. FrontBoxes help solve this problem. Front boxes are entities connected to the Mobile Router that help differentiate between mobility management tasks and particular link layer/tunnelling functionalities. The GPRS Front Box establishes a GPRS connection (i.e. establishes a PPPv4 connection, through a PDP Context to the GPRS SGSN), configures an IPv4 interface and establishes a UDP tunnel through a NAT box to the home IPv6 network, all over its egress interface. The ingress interface of the FrontBox is assigned an IPv6 address and prefix (deduced from the IPv6 prefixes of the home network); the FrontBox sends IPv6 Router Advertisements over its ingress interface towards the Mobile Router. Tunnelling IPv4 packets into UDP IPv4 streams in order to traverse NAT is proposed in [12]. In these experiments, IPv6 packets were tunneled instead. Similarly, the Wireless LAN Front Box offers native IPv6 connectivity towards the Mobile Router, when the mobile network attaches to the Wixos WiFi HotSpot network. Lach, et al. Expires April 2003 [Page 7] =0C Internet Draft OverDRiVE Experiments 23 June 2003 3.3 Home Network The home network is connected to both IPv4 and IPv6 Internets. It hosts an IPv6 Home Agent, a 6to4 Gateway and a Udptun Gateway. The Home Agent runs Mobile IPv6 with NEMO implicit mode [2]. The Udptun Gateway constitutes the UDPv4 tunnel endpoint for both the GPRS and WLAN FrontBoxes. In addition, the home network offers two WLAN access points towards the mobile network. One of the AP's is connected to the home link (where HA resides); the other AP is attached to another link of the home network. Both AP's offer native IPv6 connectivity towards the Mobile Router; when the MR connects to the home network AP's, it does by bypassing the FrontBoxes. 3.4 Orange Wireless Access (GPRS) The GPRS access system offer IPv4 access with a private addressing scheme. It distributes private non-routable addresses (10.x.y.z) over a PPP connection, addresses being assigned by DHCP servers. This network is connected to the Internet with NAT boxes. 3.5 Wixos Wireless Access (WLAN) Wixos is an 802.11b Metropolitan Area Network. During June 2003, the Wixos network was available for public experimentation. For more information about the Wixos network see [6]. Disclaimer: none of the participants in the IST OverDRiVE project are affiliated, or represent, in any legal or other way the Wixos Network. The Wixos network was used as a public access network. The network offers IPv4 access in several "hotspot" areas. Most of the hotspots are not overlapping (in terms of wireless coverage). The IPv4 network offers private non-routable IPv4 addresses. The network was not using, at the time of testing, any form of Mobile IPv4; an address acquired in one WiFi hotspot is not valid under another WiFi hotspot of the same Wixos network. 3.6 Scenarios and Results In one scenario, the mobile network was first connected to the home network outside the metropolitan area, then moved onto the highway, then entered a metropolitan area hotspot, then went out of the hotspot and entered again another hotspot. During all this trajectory, a continuous IPv6 connection was maintained between the Local Fixed Node and a Correspondent Node (web server kame.net, placed in Japan) connected on the IPv6 Internet. In another scenario, the Local Fixed Node running exclusively IPv6 protocols, browsed an IPv4 web server. This could be accomplished by configuring a "proxy" server on the LFN client. The proxy server is connected to both the IPv6 and IPv4 Internets; it is physically placed at University of Bonn. The proxy server converts http IPv6 requests into IPv4 requests, forwards the request to the IPv4 Internet, and forwards the received IPv4 reply back to the IPv6 client of the LFN. Lach, et al. Expires April 2003 [Page 8] =0C Internet Draft OverDRiVE Experiments 23 June 2003 The first mobility scenario (mentioned above) involved a dynamic change of IP addresses (both v4 and v6) to the Mobile Router. However, the IPv6 address of the LFN was not changing and, as such, the applications running on the LFN were not interrupted. Hiding the change of IP address was performed at two levels of different granularity. The dynamics of address assignment to the Mobile Router and FrontBoxes is depicted in figure xx. AP1 AP2 BS1 BS2 shadow BS3 AP3 BS4 AP4 \______/ \_______|_______/ | | | | No ad ad1 ad2 ad3 ad4 ad5 =20 | | \_______|_______________/ | | | AD1 AD2 AD3 AD4 AD3 AD4 Figure xx: Dynamics of IPv4 and IPv6 Address Assignment The first line in figure xx depicts the sequence of WLAN Access Points and GPRS Base Stations to which the Mobile Router and FrontBoxes attach. AP1 and AP2 are both in the home network (AP1 connects HA). BS1 and BS2 are deployed along the highway segment, and the "shadow" area depicts an uncovered segment along the highway (a tunnel). BS3 is deployed at junction zone between highway and city. AP3 and AP4 are the hotspot areas, separated by BS4. Dynamics of IPv4 address change show a high level of granularity (fine-grained). The IPv4 addresses distributed either by GPRS or by WLAN are pictured on the second line, lower case. When the mobile network connects to the home network, no IPv4 address is assigned. Under BS1 and BS2, the mobile network is assigned IPv4 address ad1. Switching between these two BS's does not incur a change in the IPv4 address, ad1 is kept. Due to the presence of the shadow area (the uncovered tunnel), the mobile network will be assigned a new IPv4 address (ad2) under BS3. Even though GPRS ensures the same IPv4 address assigned to a mobile, there exists no mechanism to assign the same IPv4 address to the same mobile following a short disconnection. Dynamics of IPv6 address change show a lower level of granularity (coarse-grained). Assignment of IPv6 addresses to the Mobile Router (the Care-of Addresses) is pictured on the bottom line. At home, IPv6 addresses AD1 and and AD2 are assigned to the Mobile Router, AD1 being the Home Address. Whenever the GPRS FrontBox is conneted to a BS, AD3 is assigned to the Mobile Router (BS1-4). Whenever the WLAN FrontBox is connected to an AP (AP3-4), AD4 is assigned to MR. Less change in the IPv6 address of the MR reduces the number of binding information exchanges with the Home Agent. For example, when there is a change ad1-ad2, the corresponding address AD3 Care-of Address is stable, no need to inform the Home Agent. During the experimentation, the dynamics of encapsulation (v6-in-v6 and v6-in-v4) was also observed. For further information and lessons learned, see [10]. Lach, et al. Expires April 2003 [Page 9] =0C Internet Draft OverDRiVE Experiments 23 June 2003 4. Conclusions and Future Work This report described laboratory and field experiments with an IPv6 mobile network. A wide range of laboratory experiments showed the viability of NEMO-based network mobility protocols to support scenarios with simple mobile networks, nested mobile networks, and mobile HA's. At the same time, the experiments helped proving the analytical expectations (such as excessive encapsulations) and also raised new problems (such as crossover tunneling). Solving these problems involves developping new protocols for Route Optimization for mobile networks. Field experiments involved accessing two publicly-deployed wireless access systems (GPRS and WLAN) and showed the need for NAT traversal and IPv6 transition mechanisms. These mechanisms were separated from Mobile IPv6 mobility management by means of FrontBoxes. Delivering multicast traffic to hosts inside the mobile network is an important work item identified within the project. Several schemes are currently being considered (home and remote subscriptions). A DVB-T FrontBox would allow the Mobile Router to receive high-speed (broadband) Internet flows (larger bandwidths than with GPRS or WLAN). Developing a DVB-T FrontBox is one of the potential future work items. Acknowledgements This work has been performed in the framework of the IST project IST-2001-35125 OverDRiVE (Spectrum Efficient Uni- and Multicast Over Dynamic Radio Networks in Vehicular Environments), which is partly funded by the European Union. The OverDRiVE consortium consists of Motorola, DaimlerChrysler, France Telecom, Ericsson and Radiotelevisione Italiana as well as Rheinisch-Westf=E4lische Technische Hochschule RWTH Aachen, Universit=E4t Bonn and the University of Surrey. The authors acknowledge the contributions of their colleagues in the OverDRiVE consortium. o Lach, et al. Expires April 2003 [Page 10] =0C Internet Draft OverDRiVE Experiments 23 June 2003 References [1] S. Bradner. Key Words for Use in RFCs to Indicate Requirement Levels. RFC 2119, BCP 0014, IETF. March 1997. [2] V. Devarapalli, R. Wakikawa, A. Petrescu and P. Thubert. Nemo Basic Support Protocol (work in progress). Internet Draft, IETF. draft-ietf-nemo-basic-support-00.txt. June 2003. [3] IST OverDRiVE project on the World Wide Web: http://www.ist-overdrive.org, accessed June 23rd 2003. [4] T. Ernst and H.-Y. Lach. Network Mobility Support Terminology (work in progress). Internet Draft, IETF. draft-ietf-nemo-terminology-00.txt. May 2003. [5] D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6 (work in progress). Internet Draft, IETF. draft-ietf-mobileip-ipv6-22.txt. May 2003. [6] Wixos Wireless LAN Network on the World Wide Web: http://www.wixos.net, Accessed June 22nd 2003. [7] C. Janneteau, ed., "Scenarios, Services and Requirements", OverDRiVE Deliverable D03, September 2002. [8] M. Ronai, ed., "Concept of Mobile Router and Dynamic IVAN Management", OverDRiVE Deliverable D07, March 2003. [9] A. Petrescu, ed., "Issues in Designing Mobile IPv6 Network Mobility with the MR-HA Bi-directional Tunnel (MRHA), draft-petrescu-nemo-mrha-03.txt, (Work in Progress), October 2003. [10] A. Petrescu and H.-Y. Lach, "MR-HA Bidirectional Tunnelling for Network Mobility", Motorola Labs internal tech report, October 2003. [11] H.-Y. Lach, C. Janneteau and A. Petrescu, "Network Mobility in Beyond-3G Systems", IEEE Communications Magazine, July 2003. [12] H. Levkowetz, S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, Proposed Standard, IETF. May 2003. Lach, et al. Expires April 2003 [Page 11] =0C Internet Draft OverDRiVE Experiments 23 June 2003 Authors' Addresses=20 =20 Hong-Yon Lach Christophe Janneteau =20 Motorola Labs Motorola Labs =20 Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin =20 Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 =20 France France =20 Phone: +33 1 69352536 Phone: +33 1 69352548 =20 Hong-Yon.Lach@motorola.com Christophe.Janneteau@motorola.com =20 Alexis Olivereau Alexandru Petrescu =20 Motorola Labs Motorola Labs =20 Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin =20 Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 =20 France France =20 Phone: +33 1 69352516 Phone: +33 1 69354827 =20 Alexis@motorola.com Alexandru.Petrescu@motorola.com =20 Tim Leinmueller Michael M. Wolf =20 DaimlerChrysler AG DaimlerChrysler AG =20 Research Telematics and E-Business Research Telematics and E-Business Communication Systems (RIC/TC) Communication Systems (RIC/TC) =20 HPC: U800 HPC: U800 =20 P.O. Box 2360 P.O. Box 2360 =20 89013 Ulm / Germany 89013 Ulm / Germany =20 Phone: +49 731 505 2379 Phone: +49 731 505 2379 =20 Tim.Leinmueller@daimlerchrysler.comMichael.M.Wolf@daimlerchrysler.com Markus Pilz =20 University of Bonn pilz@cs.uni-bonn.de Changes From version 00 to 01: -improved presentation. -added conclusive remarks of laboratory experiments. -enhanced the section of field experiments. -improved the conclusions section. -changed addresses and affiliations of some authors. Lach, et al. Expires April 2003 [Page 12] =0C Internet Draft OverDRiVE Experiments 23 June 2003 Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Funding for the RFC editor function is currently provided by the Internet Society. Lach, et al. Expires April 2003 [Page 13] --------------060002060205030402040809-- From exim@www1.ietf.org Mon Oct 27 09:56:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17251 for ; Mon, 27 Oct 2003 09:56:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8mu-0002es-E1 for nemo-archive@odin.ietf.org; Mon, 27 Oct 2003 09:56:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9REu8w5010214 for nemo-archive@odin.ietf.org; Mon, 27 Oct 2003 09:56:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8mu-0002ef-8d for nemo-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 09:56:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17219 for ; Mon, 27 Oct 2003 09:55:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE8ms-000685-00 for nemo-web-archive@ietf.org; Mon, 27 Oct 2003 09:56:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE8mr-000682-00 for nemo-web-archive@ietf.org; Mon, 27 Oct 2003 09:56:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8mo-0002du-Jc; Mon, 27 Oct 2003 09:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8mb-0002ci-IW for nemo@optimus.ietf.org; Mon, 27 Oct 2003 09:55:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17205 for ; Mon, 27 Oct 2003 09:55:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE8mZ-00067t-00 for nemo@ietf.org; Mon, 27 Oct 2003 09:55:47 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1AE8mY-00067q-00 for nemo@ietf.org; Mon, 27 Oct 2003 09:55:46 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h9REtjEI005370 for ; Mon, 27 Oct 2003 07:55:45 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h9REs8Qe004499 for ; Mon, 27 Oct 2003 08:54:09 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 707052EC98; Mon, 27 Oct 2003 15:41:47 +0100 (CET) Message-ID: <3F9D2EAB.2070505@motorola.com> Date: Mon, 27 Oct 2003 15:41:47 +0100 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@ietf.org Cc: Hong-Yon Lach X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------060002060205030402040809" Subject: [nemo] draft on Experiments with NEMO Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------060002060205030402040809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello to NEMO WG, We've just submitted a draft update on experiments with an IPv6 mobile network attaching to HotSpot WLAN and Orange GPRS, for vehicular environments. draft-lach-nemo-experiments-overdrive-01.txt I attach the draft, and will put it on the website soon. We would like to request a short slot at the meeting (5-7 minutes); in case it is approved HYL might present. Thanks in advance, Alex GBU --------------060002060205030402040809 Content-Type: text/plain; name="draft-lach-nemo-experiments-overdrive-01.txt" Content-Disposition: inline; filename="draft-lach-nemo-experiments-overdrive-01.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by motgate.mot.com id h9REtjEI005370 Content-Transfer-Encoding: quoted-printable Internet Draft Hong-Yon Lach draft-lach-nemo-experiments-overdrive-01.txt Christophe Janneteau Expires: April 2003 Alexis Olivereau = =20 Alexandru Petrescu Motorola Tim Leinmueller Michael M. Wolf DaimlerChrysler Markus Pilz University of Bonn =20 October 2003 =20 =20 Laboratory and "Field" Experiments with IPv6 Mobile Networks in Vehicular Environments =20 Status of this Nemo=20 =20 This document is an Internet-Draft and is in full conformance=20 with all provisions of Section 10 of RFC2026.=20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that =20 other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as=20 reference material or to cite them other than as "work in progress." =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 Abstract=20 This document gives a short high-level overview of experiments performed with IPv6 mobile networks using Mobile IPv6-based NEMO extensions in the context of the IST OverDRiVE project. Laboratory experiments include simple and nested mobile networks in a pure IPv6 environment while "field" experiments demonstrated continuous IPv6 vehicular connectivity over two publicly deployed IPv4 networks: 2.5G (GPRS) and Wireless LAN 802.11b deployed around and inside a metropolitan area. Lessons learned included the necessity for Route Optimization protocols for mobile networks, NAT traversal and IPv4-to-IPv6 transition protocols in public access wireless networks. Lach, et al. Expires April 2003 [Page 1] =0C Internet Draft OverDRiVE Experiments 23 June 2003 Table of Contents=20 =20 Status of this Nemo................................................1 Abstract...........................................................1 Conventions Used in this Document..................................2 1. IST OverDRiVE Project...........................................2 2. Laboratory Experiments..........................................3 3. "Field" Experiments.............................................6 4. Conclusions and Future Work....................................10 Acknowledgements..................................................10 References........................................................11 Authors' Addresses................................................12 Changes...........................................................12 Copyright Notice..................................................13 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC-2119 [1].=20 =20 1. IST OverDRiVE Project Work Package 3 of the European research project OverDRiVE [3] aims at developing IPv6 protocol mechanisms to support mobility of hosts, as well as of networks, that are deployed in vehicular environments. The scenarios envision that future vehicular environments in trains, ships or vehicles provide on-line information to the driver and passengers; provide even access to the vehicular communication components from the outside world (e.g. allow for software downloads be pushed to car computers). All electronic devices deployed in a vehicle (PCs, head screens, engine computers and sensors) are connected together with IPv6 protocols, and to the IPv6 Internet; the connection is realized either directly or through other IPv4 tunneling and gatewaying means. The project has defined a set of scenarios which should be supported by a mobility (and security) solution [8]. The following two major characteristics are valid for all scenarios: - Session continuity while changing the point of attachment to the Internet. - Reachability of the mobile nodes regardless of the current point of attachment. Thus, several functional scenarios become relevant: - Moving of an Intra-Vehicular Area Network (IVAN): the IVAN moves homogeneously (network entities stay together) using a mobile router to provide the Internet connectivity for nodes within the IVAN. - Moving into an IVAN with a mobile device. The mobile host moves into an IVAN and changes its WMAN connection to a WLAN connection, or its UMTS connection to a Bluetooth connection. - Moving within an IVAN: in a larger IVAN (e.g. in a train) topological hierarchies might be used, involving more than one fixed (with respect to IVAN) or mobile router. Mobile nodes can move around inside the IVAN connecting to the appropriate access router inside the IVAN. Lach, et al. Expires April 2003 [Page 2] =0C Internet Draft OverDRiVE Experiments 23 June 2003 2. Laboratory Experiments Several laboratory experiments in a pure IPv6 network were performed with mobile hosts and mobile networks. In some scenarios, more than one Local Fixed Node and one Correspondent Node were used; for example, in some scenarios there is an additional Mobile Host, or there are two mobile networks each hosting a Local Fixed Node. During all experiments, the mobility management messaging (between MR and HA, or between MH and HA) was not interrupting the end-to-end communication between these entities, even if several changes in Care-of Address were occuring. The end-to-end communications were happening between the LFN and the CN, or between two LFN's, or between one MH and one LFN, or between one MH and one CN. The CN's used were local video streaming servers and other servers connected on other parts of the worldwide IPv6 Internet. A simple mobile network is composed of one Mobile Router and one Local Fixed Node, see Figure 1. The mobile network is initially attached at home and moves subsequently to Access Router AR1 and AR2. ---- CN link =20 --| BR1|------ =20 ---- / ---- | =20 | HA | / ----=20 ---- ----------/ | CN | =20 | ------- | | ---- =20 ----------------| BR |---| Network |-------------- = =20 | home link ------- | | | =20 ---- ----- ----------\ | =20 | MR | | LFN | \ | =20 ---- ----- \ | | | ------ ------ --------- | AR1 | | AR2 | =20 mobile net link ------ ------=20 | | =20 Figure 1: Simple Mobile Network Figure 2 depicts another setting with one Mobile Router, one Mobile Host, same Home Agent. In a first scenario, the mobile network starts at home and then moves under AR1 and AR2. The Mobile Host stays at home. Lach, et al. Expires April 2003 [Page 3] =0C Internet Draft OverDRiVE Experiments 23 June 2003 Related to the same figure, another scenario is that the mobile network and the mobile hosts are first placed at home and then the mobile host moves under the mobile network. Subsequently the mobile network moves together with the mobile host under AR1 and AR2. And still with the same figure, yet another scenario; every entity is at home, then MH moves under AR1, then the mobile network moves too under AR1; then MH moves towards the mobile network and, finally, the mobile network moves to AR2. ---- CN link=20 --| BR1|------ =20 ---- ---- / ---- | =20 | HA | | MH | / ---- =20 ---- ---- ----------/ | CN | =20 | | ------- | | ---- =20 ----------------| BR |---| Network |-------------- =20 | home link ------- | | | =20 ---- ----- ----------\ | =20 | MR | | LFN | \ | =20 ---- ----- \ | =20 | | ------ ------=20 --------- | AR1 | | AR2 | mobile net link ------ ------=20 | | =20 Figure 2: Mobile Router and Mobile Host at Home Figure 3 shows a setting where the mobile router and the mobile host have different Home Agents. Various movements were performed. ---- --| CN | ---- / ---- ---- ---- =20 | HA1| / | HA2| | MH | =20 ---- ----------/ ---- ---- | ------- | | ------- | | =20 ----------------| BR |---| Network |-----| BR |-------------- | home link ------- | | ------- =20 ---- ----- ----------\ =20 | MR | | LFN | \ =20 ---- ----- \ =20 | | ------=20 --------- | AR1 | mobile net link ------=20 | =20 Figure 3: Mobile Network and Mobile Host with Different Homes In figure 4, the Mobile Host and the Mobile Router have two different Home Agents, both situated on the same home link. Various movements were performed. Lach, et al. Expires April 2003 [Page 4] =0C Internet Draft OverDRiVE Experiments 23 June 2003 ---- CN link =20 --| BR1|------ =20 ---- ---- ---- / ---- | =20 | HA1| | HA2| | MH | / ---- =20 ---- ---- ---- ----------/ | CN | =20 | | | ------- | | ---- =20 -------------------| BR |---| Network |-------------- =20 | home link ------- | | | =20 ---- ----- ----------\ | =20 | MR | | LFN | \ | =20 ---- ----- \ | =20 | | ------ ------ =20 --------- | AR1 | | AR2 |=20 mobile net link ------ ------ =20 | | =20 Figure 4: Home Agents on the Same Home Link In figure 5, one Home Agent is placed in the mobile network. Various movements were performed. ---- CN link=20 --| BR1|------ =20 ---- / ---- | =20 | HA1| / ---- =20 ---- ----------/ | CN | =20 | ------- | | ---- =20 ----------------| BR |---| Network |-------------- =20 | home link ------- | | | =20 ---- ----- ----------\ | =20 | MR | | LFN | \ | =20 ---- ----- \ | =20 | | ------ ------=20 --------- | AR1 | | AR2 | | | ------ ------=20 ---- ---- | | =20 | HA2| | MH | ---- ----=20 Figure 5: Home Agent in the Mobile Network An additional range of laboratory experiments were performed and reported in section 2.4 of [8]. Examples include: -a single Home Agent and two similar mobile networks, each composed of one Mobile Router and one Local Fixed Node. -two Home Agents and two Mobile Routers (one Home Agent for one mobile network), but still one home link. -two Home Agents and two Mobile Routers (one Home Agent for one mobile network), but on different home links. -a Home Agent placed inside a mobile network serving another mobile network attached to the first. Lach, et al. Expires April 2003 [Page 5] =0C Internet Draft OverDRiVE Experiments 23 June 2003 The descriptions in section 2.4 of [8] include details of tunnel setup procedures and illustrations of MN-HA encapsulations, as well as packet paths between various entities. The laboratory experiments helped highlighting several areas for protocol improvement of the basic support of network mobility: -Excessive tunnelling ("thick" tunnels): when MH attaches to the mobile network there are two MRHA encapsulating tunnels involved in the CN-MH path. Several levels of mobile networks induce excessive tunnelling that can lead to serious packet loss and worsen stack behaviour due to excessive fragmentation/reassembly. This is especially true in wireless environments. -Crossover tunnels happen when the path between one tunnel's endpoints includes only one of the other tunnel's endpoints . A situation leading to crossover tunnels is depicted in Figure 16 of [8], where a HA is deployed inside a mobile network. The initial configuration is in diagram a and diagrams b, c and d represent snapshots of the movement scenario. The MR2HA2 tunnel setup procedure corresponding for the diagram d is practically impossible to perform. -Externally influenced intra-aggregation communication (or disconnected operation problem): in the MH and MR with same HA case, depicted in diagram c of Figure 12 of [8], the LFN-MH communication (intra-aggregation) is influenced by the communication between MR and AR1 (external). If MR looses connection to AR1, then LFN looses connection to MH, a fact that, as paradoxical as it may seem, is a veritable side effect of tunnelling itself. -Under-optimal paths: when comparing the length of the CN-MH communication path depicted in top-left diagram of Figure 13 of [8] to the CN-MH communication in Figure 15 of [8], it is clear that the path taken by packets is much longer than the optimal. The first diagram can be considered as an ideal to be attained, and the only optimal path that can be achieved is CN-AR-MR-MH (eliminating the BR-HA-BR additional segment). This is not the ideal path (since MH is not physically home) but represents an achievable goal, if employing Route Optimization techniques. -Asymmetric communication paths: outgoing communication paths have different lengths than incoming communication paths, between the same two entities. See example in Figure 14 of [8]. 3. "Field" Experiments "Field" experiments were performed in a typical deployment of wireless networks. An overall picture of the experiments is described in Figure xx. Three wireless access networks are depicted: the home network (hosting the Home Agent), the Orange network (an European Telecom operator for mobile phones) and the Wixos network (a WiFi HotSpot network deployed in a large city). Lach, et al. Expires April 2003 [Page 6] =0C Internet Draft OverDRiVE Experiments 23 June 2003 The three networks are inter-connected at Internet level. The Mobile Network, pictured at the bottom, was obtaining Internet access via one of the three Wireless Access Networks. ------------ ----------- | Internet |-----------| Web Server| /------------\ ----------- / | \ / | \ / | \ -------- -------- ------- |Home Net| | Orange | | Wixos | -------- -------- ------- | | | Wireless Access WLAN GPRS | | ---------- |Mobile Net| ----------> ---------- Figure xx: Overall Picture of Field Experiments 3.2 Mobile Network The mobile network used in the field experiments is a very simple wireless segment (802.11b in ad-hoc mode) linking together an IPv6 Mobile Router and a Local Fixed Node running user applications (notably an http client). In addition, the mobile network contained two boxes helping interconnect the MR to the wireless access networks (FrontBoxes). Inside the mobile network, IPv6 protocols are used exclusively; the Mobile Router runs an implementation of Mobile IPv6 Mobile Router in implicit mode [2]. However, both Orange and Wixos offer IPv4 access exclusively. FrontBoxes help solve this problem. Front boxes are entities connected to the Mobile Router that help differentiate between mobility management tasks and particular link layer/tunnelling functionalities. The GPRS Front Box establishes a GPRS connection (i.e. establishes a PPPv4 connection, through a PDP Context to the GPRS SGSN), configures an IPv4 interface and establishes a UDP tunnel through a NAT box to the home IPv6 network, all over its egress interface. The ingress interface of the FrontBox is assigned an IPv6 address and prefix (deduced from the IPv6 prefixes of the home network); the FrontBox sends IPv6 Router Advertisements over its ingress interface towards the Mobile Router. Tunnelling IPv4 packets into UDP IPv4 streams in order to traverse NAT is proposed in [12]. In these experiments, IPv6 packets were tunneled instead. Similarly, the Wireless LAN Front Box offers native IPv6 connectivity towards the Mobile Router, when the mobile network attaches to the Wixos WiFi HotSpot network. Lach, et al. Expires April 2003 [Page 7] =0C Internet Draft OverDRiVE Experiments 23 June 2003 3.3 Home Network The home network is connected to both IPv4 and IPv6 Internets. It hosts an IPv6 Home Agent, a 6to4 Gateway and a Udptun Gateway. The Home Agent runs Mobile IPv6 with NEMO implicit mode [2]. The Udptun Gateway constitutes the UDPv4 tunnel endpoint for both the GPRS and WLAN FrontBoxes. In addition, the home network offers two WLAN access points towards the mobile network. One of the AP's is connected to the home link (where HA resides); the other AP is attached to another link of the home network. Both AP's offer native IPv6 connectivity towards the Mobile Router; when the MR connects to the home network AP's, it does by bypassing the FrontBoxes. 3.4 Orange Wireless Access (GPRS) The GPRS access system offer IPv4 access with a private addressing scheme. It distributes private non-routable addresses (10.x.y.z) over a PPP connection, addresses being assigned by DHCP servers. This network is connected to the Internet with NAT boxes. 3.5 Wixos Wireless Access (WLAN) Wixos is an 802.11b Metropolitan Area Network. During June 2003, the Wixos network was available for public experimentation. For more information about the Wixos network see [6]. Disclaimer: none of the participants in the IST OverDRiVE project are affiliated, or represent, in any legal or other way the Wixos Network. The Wixos network was used as a public access network. The network offers IPv4 access in several "hotspot" areas. Most of the hotspots are not overlapping (in terms of wireless coverage). The IPv4 network offers private non-routable IPv4 addresses. The network was not using, at the time of testing, any form of Mobile IPv4; an address acquired in one WiFi hotspot is not valid under another WiFi hotspot of the same Wixos network. 3.6 Scenarios and Results In one scenario, the mobile network was first connected to the home network outside the metropolitan area, then moved onto the highway, then entered a metropolitan area hotspot, then went out of the hotspot and entered again another hotspot. During all this trajectory, a continuous IPv6 connection was maintained between the Local Fixed Node and a Correspondent Node (web server kame.net, placed in Japan) connected on the IPv6 Internet. In another scenario, the Local Fixed Node running exclusively IPv6 protocols, browsed an IPv4 web server. This could be accomplished by configuring a "proxy" server on the LFN client. The proxy server is connected to both the IPv6 and IPv4 Internets; it is physically placed at University of Bonn. The proxy server converts http IPv6 requests into IPv4 requests, forwards the request to the IPv4 Internet, and forwards the received IPv4 reply back to the IPv6 client of the LFN. Lach, et al. Expires April 2003 [Page 8] =0C Internet Draft OverDRiVE Experiments 23 June 2003 The first mobility scenario (mentioned above) involved a dynamic change of IP addresses (both v4 and v6) to the Mobile Router. However, the IPv6 address of the LFN was not changing and, as such, the applications running on the LFN were not interrupted. Hiding the change of IP address was performed at two levels of different granularity. The dynamics of address assignment to the Mobile Router and FrontBoxes is depicted in figure xx. AP1 AP2 BS1 BS2 shadow BS3 AP3 BS4 AP4 \______/ \_______|_______/ | | | | No ad ad1 ad2 ad3 ad4 ad5 =20 | | \_______|_______________/ | | | AD1 AD2 AD3 AD4 AD3 AD4 Figure xx: Dynamics of IPv4 and IPv6 Address Assignment The first line in figure xx depicts the sequence of WLAN Access Points and GPRS Base Stations to which the Mobile Router and FrontBoxes attach. AP1 and AP2 are both in the home network (AP1 connects HA). BS1 and BS2 are deployed along the highway segment, and the "shadow" area depicts an uncovered segment along the highway (a tunnel). BS3 is deployed at junction zone between highway and city. AP3 and AP4 are the hotspot areas, separated by BS4. Dynamics of IPv4 address change show a high level of granularity (fine-grained). The IPv4 addresses distributed either by GPRS or by WLAN are pictured on the second line, lower case. When the mobile network connects to the home network, no IPv4 address is assigned. Under BS1 and BS2, the mobile network is assigned IPv4 address ad1. Switching between these two BS's does not incur a change in the IPv4 address, ad1 is kept. Due to the presence of the shadow area (the uncovered tunnel), the mobile network will be assigned a new IPv4 address (ad2) under BS3. Even though GPRS ensures the same IPv4 address assigned to a mobile, there exists no mechanism to assign the same IPv4 address to the same mobile following a short disconnection. Dynamics of IPv6 address change show a lower level of granularity (coarse-grained). Assignment of IPv6 addresses to the Mobile Router (the Care-of Addresses) is pictured on the bottom line. At home, IPv6 addresses AD1 and and AD2 are assigned to the Mobile Router, AD1 being the Home Address. Whenever the GPRS FrontBox is conneted to a BS, AD3 is assigned to the Mobile Router (BS1-4). Whenever the WLAN FrontBox is connected to an AP (AP3-4), AD4 is assigned to MR. Less change in the IPv6 address of the MR reduces the number of binding information exchanges with the Home Agent. For example, when there is a change ad1-ad2, the corresponding address AD3 Care-of Address is stable, no need to inform the Home Agent. During the experimentation, the dynamics of encapsulation (v6-in-v6 and v6-in-v4) was also observed. For further information and lessons learned, see [10]. Lach, et al. Expires April 2003 [Page 9] =0C Internet Draft OverDRiVE Experiments 23 June 2003 4. Conclusions and Future Work This report described laboratory and field experiments with an IPv6 mobile network. A wide range of laboratory experiments showed the viability of NEMO-based network mobility protocols to support scenarios with simple mobile networks, nested mobile networks, and mobile HA's. At the same time, the experiments helped proving the analytical expectations (such as excessive encapsulations) and also raised new problems (such as crossover tunneling). Solving these problems involves developping new protocols for Route Optimization for mobile networks. Field experiments involved accessing two publicly-deployed wireless access systems (GPRS and WLAN) and showed the need for NAT traversal and IPv6 transition mechanisms. These mechanisms were separated from Mobile IPv6 mobility management by means of FrontBoxes. Delivering multicast traffic to hosts inside the mobile network is an important work item identified within the project. Several schemes are currently being considered (home and remote subscriptions). A DVB-T FrontBox would allow the Mobile Router to receive high-speed (broadband) Internet flows (larger bandwidths than with GPRS or WLAN). Developing a DVB-T FrontBox is one of the potential future work items. Acknowledgements This work has been performed in the framework of the IST project IST-2001-35125 OverDRiVE (Spectrum Efficient Uni- and Multicast Over Dynamic Radio Networks in Vehicular Environments), which is partly funded by the European Union. The OverDRiVE consortium consists of Motorola, DaimlerChrysler, France Telecom, Ericsson and Radiotelevisione Italiana as well as Rheinisch-Westf=E4lische Technische Hochschule RWTH Aachen, Universit=E4t Bonn and the University of Surrey. The authors acknowledge the contributions of their colleagues in the OverDRiVE consortium. o Lach, et al. Expires April 2003 [Page 10] =0C Internet Draft OverDRiVE Experiments 23 June 2003 References [1] S. Bradner. Key Words for Use in RFCs to Indicate Requirement Levels. RFC 2119, BCP 0014, IETF. March 1997. [2] V. Devarapalli, R. Wakikawa, A. Petrescu and P. Thubert. Nemo Basic Support Protocol (work in progress). Internet Draft, IETF. draft-ietf-nemo-basic-support-00.txt. June 2003. [3] IST OverDRiVE project on the World Wide Web: http://www.ist-overdrive.org, accessed June 23rd 2003. [4] T. Ernst and H.-Y. Lach. Network Mobility Support Terminology (work in progress). Internet Draft, IETF. draft-ietf-nemo-terminology-00.txt. May 2003. [5] D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6 (work in progress). Internet Draft, IETF. draft-ietf-mobileip-ipv6-22.txt. May 2003. [6] Wixos Wireless LAN Network on the World Wide Web: http://www.wixos.net, Accessed June 22nd 2003. [7] C. Janneteau, ed., "Scenarios, Services and Requirements", OverDRiVE Deliverable D03, September 2002. [8] M. Ronai, ed., "Concept of Mobile Router and Dynamic IVAN Management", OverDRiVE Deliverable D07, March 2003. [9] A. Petrescu, ed., "Issues in Designing Mobile IPv6 Network Mobility with the MR-HA Bi-directional Tunnel (MRHA), draft-petrescu-nemo-mrha-03.txt, (Work in Progress), October 2003. [10] A. Petrescu and H.-Y. Lach, "MR-HA Bidirectional Tunnelling for Network Mobility", Motorola Labs internal tech report, October 2003. [11] H.-Y. Lach, C. Janneteau and A. Petrescu, "Network Mobility in Beyond-3G Systems", IEEE Communications Magazine, July 2003. [12] H. Levkowetz, S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, Proposed Standard, IETF. May 2003. Lach, et al. Expires April 2003 [Page 11] =0C Internet Draft OverDRiVE Experiments 23 June 2003 Authors' Addresses=20 =20 Hong-Yon Lach Christophe Janneteau =20 Motorola Labs Motorola Labs =20 Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin =20 Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 =20 France France =20 Phone: +33 1 69352536 Phone: +33 1 69352548 =20 Hong-Yon.Lach@motorola.com Christophe.Janneteau@motorola.com =20 Alexis Olivereau Alexandru Petrescu =20 Motorola Labs Motorola Labs =20 Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin =20 Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 =20 France France =20 Phone: +33 1 69352516 Phone: +33 1 69354827 =20 Alexis@motorola.com Alexandru.Petrescu@motorola.com =20 Tim Leinmueller Michael M. Wolf =20 DaimlerChrysler AG DaimlerChrysler AG =20 Research Telematics and E-Business Research Telematics and E-Business Communication Systems (RIC/TC) Communication Systems (RIC/TC) =20 HPC: U800 HPC: U800 =20 P.O. Box 2360 P.O. Box 2360 =20 89013 Ulm / Germany 89013 Ulm / Germany =20 Phone: +49 731 505 2379 Phone: +49 731 505 2379 =20 Tim.Leinmueller@daimlerchrysler.comMichael.M.Wolf@daimlerchrysler.com Markus Pilz =20 University of Bonn pilz@cs.uni-bonn.de Changes From version 00 to 01: -improved presentation. -added conclusive remarks of laboratory experiments. -enhanced the section of field experiments. -improved the conclusions section. -changed addresses and affiliations of some authors. Lach, et al. Expires April 2003 [Page 12] =0C Internet Draft OverDRiVE Experiments 23 June 2003 Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Funding for the RFC editor function is currently provided by the Internet Society. Lach, et al. Expires April 2003 [Page 13] --------------060002060205030402040809-- From nemo-admin@ietf.org Tue Oct 28 22:17:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19162 for ; Tue, 28 Oct 2003 22:17:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEgpQ-0000UV-KI; Tue, 28 Oct 2003 22:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEgor-0000RM-6j for nemo@optimus.ietf.org; Tue, 28 Oct 2003 22:16:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18921 for ; Tue, 28 Oct 2003 22:16:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEgon-00072C-00 for nemo@ietf.org; Tue, 28 Oct 2003 22:16:21 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AEgoi-00071T-00 for nemo@ietf.org; Tue, 28 Oct 2003 22:16:16 -0500 Received: from [64.36.73.242] (home2.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h9T3GjMU001592; Tue, 28 Oct 2003 19:16:45 -0800 (PST) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 28 Oct 2003 19:16:08 -0800 From: "T.J. Kniveton" To: , Margaret Wasserman , Thomas Narten , Erik Nordmark Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Nemo IPR / Cisco Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi folks, Thierry and I sent some questions to Cisco attorneys about their IPR with respect to NEMO. I want to share the results of that inquiry. Also, note that Cisco was issued patent 6636498 last week. Please go to www.uspto.gov and look up this patent and familiarize yourself with it. Also, please take a moment to read Cisco's response, and form an opinion about these IPR issues and how Cisco's and Nokia's IPR licensing policies will effect our NEMO work. It would be highly encouraged to start a dialog on the list before the IETF, so we can process people's comments and opinions. ---- >> [These are our questions] > [These are Cisco's responses] >> The NEMO working group members are concerned about the claims of >> Intellectual Property regarding the NEMO specification, and would like >> more information about the specific claims as well as licensing terms >> proposed by Cisco. Please keep in mind that any response to >> this letter >> will be deemed public information and may be shared with the >> NEMO working >> group. >> >> Here are the questions which remain open; any information you could >> provide regarding this matter will be appreciated. >> >> 1. What is(are) the status of the patent application or >> applications >> mentioned in your IPR disclosure: >> http://ietf.org/ietf/IPR/cisco-ipr-draft-ietf-nemo-basic-support.txt? > > One application issued last week as US Patent No. 6,636,498. Other > applications are pending in the US Patent Office. > > >> a. Is the application(s) published, and if so what is(are) >> the publication >> number/application number(s) of the patent application(s)? > > The pending applcations have not been published. > >> b. Does your disclosure relate to an unpublished pending patent >> application(s)? > > The pending applications have not been published. > > >> c. What countries has(have) these applications been filed >> in, and on what >> dates? > > In the United States. The filing dates of the unpublished applications are > confidential. > > >> 2. Are you willing to amend the licensing terms of your >> IPR disclosure? > > We believe the IPR disclosure is in compliance with IETF IPR rules, > including RFC 2026. If you disagree please let me know. > > >> a. Would you be willing to match your licensing terms in >> the direction of >> what is currently the only other IPR disclosure for the same draft >> (http://ietf.org/ietf/IPR/nokia-ipr-draft-ietf-nemo-basic-supp >> ort.txt)? > > No, we cannot do so without assurances from IETF that the licensing terms in > this disclosure are nondiscriminatory. > > >> 3. If you can not give publication number(s) of the >> application(s), what >> parts of the NEMO-basic-support Internet Draft are affected by your >> disclosure >> >> In all cases, we request that you state which sections are >> affected by the >> disclosure. This was a concern clearly raised amongst the >> working group >> members at the last IETF meeting. > > The following sections are affected: > > Section 4 - Message formats > Section 5.2 - Implicit, Implicit Network, and Explicit Prefix Length; > (3 Modes of Mobile Router operation) > Section 6.4 - Bi-directional tunnel > Section 6.5 - forwarding packets > Section 6.7 - De-registration > Section 7 - Dynamic routing protocols (e.g., routing protocol updates) > From exim@www1.ietf.org Tue Oct 28 22:17:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19189 for ; Tue, 28 Oct 2003 22:17:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEgpc-0000Y5-VC for nemo-archive@odin.ietf.org; Tue, 28 Oct 2003 22:17:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T3HCGq002105 for nemo-archive@odin.ietf.org; Tue, 28 Oct 2003 22:17:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEgpc-0000Xs-Oy for nemo-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 22:17:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19058 for ; Tue, 28 Oct 2003 22:17:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEgpY-000766-00 for nemo-web-archive@ietf.org; Tue, 28 Oct 2003 22:17:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEgpY-00075F-00 for nemo-web-archive@ietf.org; Tue, 28 Oct 2003 22:17:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEgpQ-0000UV-KI; Tue, 28 Oct 2003 22:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEgor-0000RM-6j for nemo@optimus.ietf.org; Tue, 28 Oct 2003 22:16:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18921 for ; Tue, 28 Oct 2003 22:16:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEgon-00072C-00 for nemo@ietf.org; Tue, 28 Oct 2003 22:16:21 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AEgoi-00071T-00 for nemo@ietf.org; Tue, 28 Oct 2003 22:16:16 -0500 Received: from [64.36.73.242] (home2.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h9T3GjMU001592; Tue, 28 Oct 2003 19:16:45 -0800 (PST) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 28 Oct 2003 19:16:08 -0800 From: "T.J. Kniveton" To: , Margaret Wasserman , Thomas Narten , Erik Nordmark Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Nemo IPR / Cisco Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi folks, Thierry and I sent some questions to Cisco attorneys about their IPR with respect to NEMO. I want to share the results of that inquiry. Also, note that Cisco was issued patent 6636498 last week. Please go to www.uspto.gov and look up this patent and familiarize yourself with it. Also, please take a moment to read Cisco's response, and form an opinion about these IPR issues and how Cisco's and Nokia's IPR licensing policies will effect our NEMO work. It would be highly encouraged to start a dialog on the list before the IETF, so we can process people's comments and opinions. ---- >> [These are our questions] > [These are Cisco's responses] >> The NEMO working group members are concerned about the claims of >> Intellectual Property regarding the NEMO specification, and would like >> more information about the specific claims as well as licensing terms >> proposed by Cisco. Please keep in mind that any response to >> this letter >> will be deemed public information and may be shared with the >> NEMO working >> group. >> >> Here are the questions which remain open; any information you could >> provide regarding this matter will be appreciated. >> >> 1. What is(are) the status of the patent application or >> applications >> mentioned in your IPR disclosure: >> http://ietf.org/ietf/IPR/cisco-ipr-draft-ietf-nemo-basic-support.txt? > > One application issued last week as US Patent No. 6,636,498. Other > applications are pending in the US Patent Office. > > >> a. Is the application(s) published, and if so what is(are) >> the publication >> number/application number(s) of the patent application(s)? > > The pending applcations have not been published. > >> b. Does your disclosure relate to an unpublished pending patent >> application(s)? > > The pending applications have not been published. > > >> c. What countries has(have) these applications been filed >> in, and on what >> dates? > > In the United States. The filing dates of the unpublished applications are > confidential. > > >> 2. Are you willing to amend the licensing terms of your >> IPR disclosure? > > We believe the IPR disclosure is in compliance with IETF IPR rules, > including RFC 2026. If you disagree please let me know. > > >> a. Would you be willing to match your licensing terms in >> the direction of >> what is currently the only other IPR disclosure for the same draft >> (http://ietf.org/ietf/IPR/nokia-ipr-draft-ietf-nemo-basic-supp >> ort.txt)? > > No, we cannot do so without assurances from IETF that the licensing terms in > this disclosure are nondiscriminatory. > > >> 3. If you can not give publication number(s) of the >> application(s), what >> parts of the NEMO-basic-support Internet Draft are affected by your >> disclosure >> >> In all cases, we request that you state which sections are >> affected by the >> disclosure. This was a concern clearly raised amongst the >> working group >> members at the last IETF meeting. > > The following sections are affected: > > Section 4 - Message formats > Section 5.2 - Implicit, Implicit Network, and Explicit Prefix Length; > (3 Modes of Mobile Router operation) > Section 6.4 - Bi-directional tunnel > Section 6.5 - forwarding packets > Section 6.7 - De-registration > Section 7 - Dynamic routing protocols (e.g., routing protocol updates) > From nemo-admin@ietf.org Wed Oct 29 00:46:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26063 for ; Wed, 29 Oct 2003 00:46:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEj9d-0002Or-UT; Wed, 29 Oct 2003 00:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEj9O-0002NR-D0 for nemo@optimus.ietf.org; Wed, 29 Oct 2003 00:45:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26031 for ; Wed, 29 Oct 2003 00:45:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEj9L-0001yD-00 for nemo@ietf.org; Wed, 29 Oct 2003 00:45:43 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AEj9F-0001yA-00 for nemo@ietf.org; Wed, 29 Oct 2003 00:45:38 -0500 Received: from [64.36.73.242] (home2.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h9T5k8MU002061; Tue, 28 Oct 2003 21:46:08 -0800 (PST) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 28 Oct 2003 21:45:30 -0800 From: "T.J. Kniveton" To: , Margaret Wasserman , Thomas Narten , Erik Nordmark Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO IPR / Cisco / Nokia (2) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In terms of the IPR discussion, any group or company who has claimed some IPR on NEMO specs (Cisco/Nokia at present) should be part of this discussion. So, we can continue the past dialog, if necessary, about Nokia's license as well. Cisco had some comments about Nokia's license, and about Cisco's patent assertion practices. Here is that text, which directly followed the list of "affected sections": >> >> Please note that the working group is concerned about >> licensing terms for >> basic technology that may be part of the NEMO basic support draft. The >> presence of patent claims without a free license for >> implementation may >> hinder or preclude further work on this technology without substantial >> rework of the underlying mechanisms. Any help you can provide towards >> making this draft viable would be gratefully received. > > Please note that the license at > (http://ietf.org/ietf/IPR/nokia-ipr-draft-ietf-nemo-basic-support.txt) > > is not a "free license for implementation" for those who do not use the > specific licenses referred to therein. > > Please note further that Cisco has never asserted a patent against anyone > for implementing an IETF standard except in response to patent assertions > against Cisco from another party. >> >> >> Sincerely, >> >> T.J. Kniveton for Thierry Ernst >> Nokia WIDE / KEIO University >> >> NEMO Working Group Chairs >> >> -TJ From exim@www1.ietf.org Wed Oct 29 00:46:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26078 for ; Wed, 29 Oct 2003 00:46:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEj9g-0002QW-R9 for nemo-archive@odin.ietf.org; Wed, 29 Oct 2003 00:46:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T5k4WM009327 for nemo-archive@odin.ietf.org; Wed, 29 Oct 2003 00:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEj9g-0002QM-JX for nemo-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 00:46:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26047 for ; Wed, 29 Oct 2003 00:45:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEj9d-0001yi-00 for nemo-web-archive@ietf.org; Wed, 29 Oct 2003 00:46:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEj9d-0001yf-00 for nemo-web-archive@ietf.org; Wed, 29 Oct 2003 00:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEj9d-0002Or-UT; Wed, 29 Oct 2003 00:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEj9O-0002NR-D0 for nemo@optimus.ietf.org; Wed, 29 Oct 2003 00:45:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26031 for ; Wed, 29 Oct 2003 00:45:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEj9L-0001yD-00 for nemo@ietf.org; Wed, 29 Oct 2003 00:45:43 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AEj9F-0001yA-00 for nemo@ietf.org; Wed, 29 Oct 2003 00:45:38 -0500 Received: from [64.36.73.242] (home2.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h9T5k8MU002061; Tue, 28 Oct 2003 21:46:08 -0800 (PST) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 28 Oct 2003 21:45:30 -0800 From: "T.J. Kniveton" To: , Margaret Wasserman , Thomas Narten , Erik Nordmark Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO IPR / Cisco / Nokia (2) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In terms of the IPR discussion, any group or company who has claimed some IPR on NEMO specs (Cisco/Nokia at present) should be part of this discussion. So, we can continue the past dialog, if necessary, about Nokia's license as well. Cisco had some comments about Nokia's license, and about Cisco's patent assertion practices. Here is that text, which directly followed the list of "affected sections": >> >> Please note that the working group is concerned about >> licensing terms for >> basic technology that may be part of the NEMO basic support draft. The >> presence of patent claims without a free license for >> implementation may >> hinder or preclude further work on this technology without substantial >> rework of the underlying mechanisms. Any help you can provide towards >> making this draft viable would be gratefully received. > > Please note that the license at > (http://ietf.org/ietf/IPR/nokia-ipr-draft-ietf-nemo-basic-support.txt) > > is not a "free license for implementation" for those who do not use the > specific licenses referred to therein. > > Please note further that Cisco has never asserted a patent against anyone > for implementing an IETF standard except in response to patent assertions > against Cisco from another party. >> >> >> Sincerely, >> >> T.J. Kniveton for Thierry Ernst >> Nokia WIDE / KEIO University >> >> NEMO Working Group Chairs >> >> -TJ From nemo-admin@ietf.org Wed Oct 29 03:13:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27652 for ; Wed, 29 Oct 2003 03:13:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AElRs-0006Le-Da; Wed, 29 Oct 2003 03:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AElR4-0006Ez-Qi for nemo@optimus.ietf.org; Wed, 29 Oct 2003 03:12:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27607 for ; Wed, 29 Oct 2003 03:12:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AElR2-000407-00 for nemo@ietf.org; Wed, 29 Oct 2003 03:12:08 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AElR1-000403-00 for nemo@ietf.org; Wed, 29 Oct 2003 03:12:07 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h9T8C7BO006825; Wed, 29 Oct 2003 01:12:08 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h9T8C52M005900; Wed, 29 Oct 2003 02:12:07 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1007B2EC95; Wed, 29 Oct 2003 09:12:05 +0100 (CET) Message-ID: <3F9F7654.9060301@motorola.com> Date: Wed, 29 Oct 2003 09:12:04 +0100 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: "T.J. Kniveton" Cc: nemo@ietf.org, Margaret Wasserman , Thomas Narten , Erik Nordmark Subject: Re: [nemo] NEMO IPR / Cisco / Nokia (2) References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit T.J. Kniveton wrote: > In terms of the IPR discussion, any group or company who has claimed > some IPR on NEMO specs (Cisco/Nokia at present) should be part of > this discussion. What do you call "NEMO specs"? Is it the WG items exclusively? Is it all the drafts that have -nemo- in name? Is it all the drafts that are published on the mobilenetworks.org/nemo site? Alex GBU From exim@www1.ietf.org Wed Oct 29 03:13:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27668 for ; Wed, 29 Oct 2003 03:13:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AElS0-0006N4-2c for nemo-archive@odin.ietf.org; Wed, 29 Oct 2003 03:13:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T8D73h024485 for nemo-archive@odin.ietf.org; Wed, 29 Oct 2003 03:13:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AElRy-0006Mq-UM for nemo-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 03:13:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27638 for ; Wed, 29 Oct 2003 03:12:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AElRw-00040l-00 for nemo-web-archive@ietf.org; Wed, 29 Oct 2003 03:13:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AElRw-00040g-00 for nemo-web-archive@ietf.org; Wed, 29 Oct 2003 03:13:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AElRs-0006Le-Da; Wed, 29 Oct 2003 03:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AElR4-0006Ez-Qi for nemo@optimus.ietf.org; Wed, 29 Oct 2003 03:12:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27607 for ; Wed, 29 Oct 2003 03:12:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AElR2-000407-00 for nemo@ietf.org; Wed, 29 Oct 2003 03:12:08 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AElR1-000403-00 for nemo@ietf.org; Wed, 29 Oct 2003 03:12:07 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h9T8C7BO006825; Wed, 29 Oct 2003 01:12:08 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h9T8C52M005900; Wed, 29 Oct 2003 02:12:07 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1007B2EC95; Wed, 29 Oct 2003 09:12:05 +0100 (CET) Message-ID: <3F9F7654.9060301@motorola.com> Date: Wed, 29 Oct 2003 09:12:04 +0100 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: "T.J. Kniveton" Cc: nemo@ietf.org, Margaret Wasserman , Thomas Narten , Erik Nordmark Subject: Re: [nemo] NEMO IPR / Cisco / Nokia (2) References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit T.J. Kniveton wrote: > In terms of the IPR discussion, any group or company who has claimed > some IPR on NEMO specs (Cisco/Nokia at present) should be part of > this discussion. What do you call "NEMO specs"? Is it the WG items exclusively? Is it all the drafts that have -nemo- in name? Is it all the drafts that are published on the mobilenetworks.org/nemo site? Alex GBU From nemo-admin@ietf.org Wed Oct 29 04:39:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00193 for ; Wed, 29 Oct 2003 04:39:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEmn8-0000zc-WA; Wed, 29 Oct 2003 04:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEmmS-0000m1-1b for nemo@optimus.ietf.org; Wed, 29 Oct 2003 04:38:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00151 for ; Wed, 29 Oct 2003 04:38:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEmmO-00052r-00 for nemo@ietf.org; Wed, 29 Oct 2003 04:38:16 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AEmmO-000529-00 for nemo@ietf.org; Wed, 29 Oct 2003 04:38:16 -0500 Received: from [64.36.73.242] (home2.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h9T9brMU002804; Wed, 29 Oct 2003 01:37:53 -0800 (PST) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 29 Oct 2003 01:37:14 -0800 Subject: Re: [nemo] NEMO IPR / Cisco / Nokia (2) From: "T.J. Kniveton" To: Alexandru Petrescu CC: , Margaret Wasserman , Thomas Narten Message-ID: In-Reply-To: <3F9F7654.9060301@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 10/29/03 12:12 AM, "Alexandru Petrescu" wrote: > T.J. Kniveton wrote: >> In terms of the IPR discussion, any group or company who has claimed >> some IPR on NEMO specs (Cisco/Nokia at present) should be part of >> this discussion. > > What do you call "NEMO specs"? Is it the WG items exclusively? Is it > all the drafts that have -nemo- in name? Is it all the drafts that are > published on the mobilenetworks.org/nemo site? > > Alex > GBU > > Good question. I think we only need to discuss WG documents, with highest priority to most mature drafts (i.e. basic support). And when additional drafts become WG documents, we can discuss IPR aspects of those in turn. ADs can add additional comments here if necessary. TJ From exim@www1.ietf.org Wed Oct 29 04:39:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00208 for ; Wed, 29 Oct 2003 04:39:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEmnC-000111-G1 for nemo-archive@odin.ietf.org; Wed, 29 Oct 2003 04:39:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T9d6kj003897 for nemo-archive@odin.ietf.org; Wed, 29 Oct 2003 04:39:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEmnC-00010e-1U for nemo-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 04:39:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00190 for ; Wed, 29 Oct 2003 04:38:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEmn8-00053R-00 for nemo-web-archive@ietf.org; Wed, 29 Oct 2003 04:39:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEmn8-00053O-00 for nemo-web-archive@ietf.org; Wed, 29 Oct 2003 04:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEmn8-0000zc-WA; Wed, 29 Oct 2003 04:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEmmS-0000m1-1b for nemo@optimus.ietf.org; Wed, 29 Oct 2003 04:38:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00151 for ; Wed, 29 Oct 2003 04:38:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEmmO-00052r-00 for nemo@ietf.org; Wed, 29 Oct 2003 04:38:16 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AEmmO-000529-00 for nemo@ietf.org; Wed, 29 Oct 2003 04:38:16 -0500 Received: from [64.36.73.242] (home2.kniveton.com [64.36.73.242]) by multihop.net (8.12.9/8.12.9) with ESMTP id h9T9brMU002804; Wed, 29 Oct 2003 01:37:53 -0800 (PST) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 29 Oct 2003 01:37:14 -0800 Subject: Re: [nemo] NEMO IPR / Cisco / Nokia (2) From: "T.J. Kniveton" To: Alexandru Petrescu CC: , Margaret Wasserman , Thomas Narten Message-ID: In-Reply-To: <3F9F7654.9060301@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 10/29/03 12:12 AM, "Alexandru Petrescu" wrote: > T.J. Kniveton wrote: >> In terms of the IPR discussion, any group or company who has claimed >> some IPR on NEMO specs (Cisco/Nokia at present) should be part of >> this discussion. > > What do you call "NEMO specs"? Is it the WG items exclusively? Is it > all the drafts that have -nemo- in name? Is it all the drafts that are > published on the mobilenetworks.org/nemo site? > > Alex > GBU > > Good question. I think we only need to discuss WG documents, with highest priority to most mature drafts (i.e. basic support). And when additional drafts become WG documents, we can discuss IPR aspects of those in turn. ADs can add additional comments here if necessary. TJ From nemo-admin@ietf.org Wed Oct 29 15:34:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04642 for ; Wed, 29 Oct 2003 15:34:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEx0z-0000uW-9O; Wed, 29 Oct 2003 15:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwxp-0000lX-IB for nemo@optimus.ietf.org; Wed, 29 Oct 2003 15:30:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04507 for ; Wed, 29 Oct 2003 15:30:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEwxo-0002jc-00 for nemo@ietf.org; Wed, 29 Oct 2003 15:30:44 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AEwxn-0002jX-00 for nemo@ietf.org; Wed, 29 Oct 2003 15:30:43 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h9TKUgBO022472; Wed, 29 Oct 2003 13:30:42 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h9TKUbsB020146; Wed, 29 Oct 2003 14:30:39 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id B371A2EC95; Wed, 29 Oct 2003 21:30:37 +0100 (CET) Message-ID: <3FA0236D.3000005@nal.motlabs.com> Date: Wed, 29 Oct 2003 21:30:37 +0100 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: "T.J. Kniveton" , nemo@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: IPRs on base solution Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Let me me bring back this thread on IPR, now that more info on actual claims is available. Erik Nordmark wrote: > - Is there any information what the claimed IPR might actually cover? > I used US2003/0117965A1 and US6636498B1 that I'll call A and B in the following. I have some interpretations below, but those are of course not of a professional lawyer, disclaimers apply. Both A and B have claims relating to the way NEMO basic (non-RO) works: B is on methods for Mobile IPv4 while A is for Mobile IPv6 (B has some text on an MR-specific FA while B obviously hasn't). Both A and B claim that HA will modify its routing table and binding cache or mobility binding table upon reception of BU or RReq. B claims that, in addition to the CoA in the RReq, there might be prefixes in the RReq. A only claims there's a CoA in the BU. Both A and B claim that dynamic routing information exchanges might happen between MR and HA, through the bidir tunnel, whenever MR changes CoA. A mentions nested mobile networks while B doesn't. One thing in the NEMO base draft that is not covered by A and B is probably the "explicit prefix len" mode. Another thing that is not covered neither by A nor by B is probably the HA learning host-based routes via ICMP redirects (this particular aspect is not in the NEMO base WG item but it is in some nemo related draft). Probably those two details are very narrow with respect to the overall nemo workings, or I'd rather say that both A and B have very wide claims. If one wants to go further, other means to do network mobility with Mobile IPv6 and bidir tunnel are always possible, such that they don't fall under A and B's claims; for example one might want to avoid modifying the routing table. Also, in a different context and with different purposes, one might be able to identify relevant prior art preceding A's filing date (and probably a bit of B's too) and challenge the patents directly, instead of fighting over the licensing scheme (I'm not sure which approach is cheaper). That's very easy: consider that A and B are filed and published at different dates, so they are surely preceding one another somehow and neither one mentions the other. > This is useful for the WG if there is a desire to proceed even though > there is IPR, something which the WG is free to choose, or try to > work around the IPR. Right. Alex From exim@www1.ietf.org Wed Oct 29 15:34:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04657 for ; Wed, 29 Oct 2003 15:34:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEx13-0000vd-QG for nemo-archive@odin.ietf.org; Wed, 29 Oct 2003 15:34:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TKY5SO003564 for nemo-archive@odin.ietf.org; Wed, 29 Oct 2003 15:34:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEx13-0000vL-Iv for nemo-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 15:34:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04638 for ; Wed, 29 Oct 2003 15:33:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEx12-0002nB-00 for nemo-web-archive@ietf.org; Wed, 29 Oct 2003 15:34:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEx12-0002n8-00 for nemo-web-archive@ietf.org; Wed, 29 Oct 2003 15:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEx0z-0000uW-9O; Wed, 29 Oct 2003 15:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwxp-0000lX-IB for nemo@optimus.ietf.org; Wed, 29 Oct 2003 15:30:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04507 for ; Wed, 29 Oct 2003 15:30:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEwxo-0002jc-00 for nemo@ietf.org; Wed, 29 Oct 2003 15:30:44 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AEwxn-0002jX-00 for nemo@ietf.org; Wed, 29 Oct 2003 15:30:43 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h9TKUgBO022472; Wed, 29 Oct 2003 13:30:42 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h9TKUbsB020146; Wed, 29 Oct 2003 14:30:39 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id B371A2EC95; Wed, 29 Oct 2003 21:30:37 +0100 (CET) Message-ID: <3FA0236D.3000005@nal.motlabs.com> Date: Wed, 29 Oct 2003 21:30:37 +0100 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: "T.J. Kniveton" , nemo@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: IPRs on base solution Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Let me me bring back this thread on IPR, now that more info on actual claims is available. Erik Nordmark wrote: > - Is there any information what the claimed IPR might actually cover? > I used US2003/0117965A1 and US6636498B1 that I'll call A and B in the following. I have some interpretations below, but those are of course not of a professional lawyer, disclaimers apply. Both A and B have claims relating to the way NEMO basic (non-RO) works: B is on methods for Mobile IPv4 while A is for Mobile IPv6 (B has some text on an MR-specific FA while B obviously hasn't). Both A and B claim that HA will modify its routing table and binding cache or mobility binding table upon reception of BU or RReq. B claims that, in addition to the CoA in the RReq, there might be prefixes in the RReq. A only claims there's a CoA in the BU. Both A and B claim that dynamic routing information exchanges might happen between MR and HA, through the bidir tunnel, whenever MR changes CoA. A mentions nested mobile networks while B doesn't. One thing in the NEMO base draft that is not covered by A and B is probably the "explicit prefix len" mode. Another thing that is not covered neither by A nor by B is probably the HA learning host-based routes via ICMP redirects (this particular aspect is not in the NEMO base WG item but it is in some nemo related draft). Probably those two details are very narrow with respect to the overall nemo workings, or I'd rather say that both A and B have very wide claims. If one wants to go further, other means to do network mobility with Mobile IPv6 and bidir tunnel are always possible, such that they don't fall under A and B's claims; for example one might want to avoid modifying the routing table. Also, in a different context and with different purposes, one might be able to identify relevant prior art preceding A's filing date (and probably a bit of B's too) and challenge the patents directly, instead of fighting over the licensing scheme (I'm not sure which approach is cheaper). That's very easy: consider that A and B are filed and published at different dates, so they are surely preceding one another somehow and neither one mentions the other. > This is useful for the WG if there is a desire to proceed even though > there is IPR, something which the WG is free to choose, or try to > work around the IPR. Right. Alex From nemo-admin@ietf.org Wed Oct 29 17:06:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09512 for ; Wed, 29 Oct 2003 17:06:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEyS1-0001cy-O0; Wed, 29 Oct 2003 17:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEyRc-0001bA-9k for nemo@optimus.ietf.org; Wed, 29 Oct 2003 17:05:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09484 for ; Wed, 29 Oct 2003 17:05:24 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEyRa-0004hC-00 for nemo@ietf.org; Wed, 29 Oct 2003 17:05:34 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AEyRZ-0004h3-00 for nemo@ietf.org; Wed, 29 Oct 2003 17:05:33 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9TM5WG09059 for ; Thu, 30 Oct 2003 00:05:32 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 Oct 2003 00:05:32 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 29 Oct 2003 16:05:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] NEMO IPR / Cisco / Nokia (2) Date: Wed, 29 Oct 2003 17:05:21 -0500 Message-ID: Thread-Topic: [nemo] NEMO IPR / Cisco / Nokia (2) Thread-Index: AcOeAaOYqxQp0xF2SjOToijngPvpXAAZpdKg To: , Cc: , X-OriginalArrivalTime: 29 Oct 2003 22:05:25.0022 (UTC) FILETIME=[C11D5BE0:01C39E68] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Good question. I think we only need to discuss WG documents,=20 > with highest priority to most mature drafts (i.e. basic=20 > support). And when additional drafts become WG documents, we=20 > can discuss IPR aspects of those in turn. >=20 > ADs can add additional comments here if necessary. I agree that it is the highest priority to make sure=20 that the WG is okay with the IPR claims on the items=20 that you have mentioned above. However, all NEMO participants should be disclosing any IPR that they (or their companies) have that is=20 associated with any NEMO contribution. That means that folks should have already disclosed any IPR that they are aware of that relates to any published/discussed=20 I-D, whether or not it has been accepted as a WG work=20 item, and any ideas that are posted to the mailing lists or presented in meetings. Margaret From exim@www1.ietf.org Wed Oct 29 17:06:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09527 for ; Wed, 29 Oct 2003 17:06:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEyS4-0001dt-TG for nemo-archive@odin.ietf.org; Wed, 29 Oct 2003 17:06:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TM64uV006311 for nemo-archive@odin.ietf.org; Wed, 29 Oct 2003 17:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEyS4-0001di-LN for nemo-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 17:06:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09502 for ; Wed, 29 Oct 2003 17:05:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEyS2-0004i0-00 for nemo-web-archive@ietf.org; Wed, 29 Oct 2003 17:06:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEyS2-0004hx-00 for nemo-web-archive@ietf.org; Wed, 29 Oct 2003 17:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEyS1-0001cy-O0; Wed, 29 Oct 2003 17:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEyRc-0001bA-9k for nemo@optimus.ietf.org; Wed, 29 Oct 2003 17:05:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09484 for ; Wed, 29 Oct 2003 17:05:24 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEyRa-0004hC-00 for nemo@ietf.org; Wed, 29 Oct 2003 17:05:34 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AEyRZ-0004h3-00 for nemo@ietf.org; Wed, 29 Oct 2003 17:05:33 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9TM5WG09059 for ; Thu, 30 Oct 2003 00:05:32 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 Oct 2003 00:05:32 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 29 Oct 2003 16:05:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] NEMO IPR / Cisco / Nokia (2) Date: Wed, 29 Oct 2003 17:05:21 -0500 Message-ID: Thread-Topic: [nemo] NEMO IPR / Cisco / Nokia (2) Thread-Index: AcOeAaOYqxQp0xF2SjOToijngPvpXAAZpdKg To: , Cc: , X-OriginalArrivalTime: 29 Oct 2003 22:05:25.0022 (UTC) FILETIME=[C11D5BE0:01C39E68] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Good question. I think we only need to discuss WG documents,=20 > with highest priority to most mature drafts (i.e. basic=20 > support). And when additional drafts become WG documents, we=20 > can discuss IPR aspects of those in turn. >=20 > ADs can add additional comments here if necessary. I agree that it is the highest priority to make sure=20 that the WG is okay with the IPR claims on the items=20 that you have mentioned above. However, all NEMO participants should be disclosing any IPR that they (or their companies) have that is=20 associated with any NEMO contribution. That means that folks should have already disclosed any IPR that they are aware of that relates to any published/discussed=20 I-D, whether or not it has been accepted as a WG work=20 item, and any ideas that are posted to the mailing lists or presented in meetings. Margaret From nemo-admin@ietf.org Thu Oct 30 02:49:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12886 for ; Thu, 30 Oct 2003 02:49:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF7YE-0002SH-CK; Thu, 30 Oct 2003 02:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF7Xc-0002Pp-I2 for nemo@optimus.ietf.org; Thu, 30 Oct 2003 02:48:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12867 for ; Thu, 30 Oct 2003 02:48:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF7XY-0006zb-00 for nemo@ietf.org; Thu, 30 Oct 2003 02:48:20 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AF7XM-0006z6-00 for nemo@ietf.org; Thu, 30 Oct 2003 02:48:09 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h9U7dqRn009276 for ; Thu, 30 Oct 2003 15:39:56 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 005C810E95DA for ; Thu, 30 Oct 2003 15:48:43 +0800 (SGT) Subject: Multihoming Discussion (was Re: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt]) From: Chan-Wah NG To: IETF NEMO WG In-Reply-To: <1067253929.2748.2.camel@localhost> References: <1067253929.2748.2.camel@localhost> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1067500123.1990.25.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 30 Oct 2003 15:48:43 +0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, NEMO WG, Here is a quick summary of changes to the new draft (differences between -01 and -02). taxonomy: I have included Erik's insights on subscriptions-based versus single ownership of NEMO and its home domain(s). Analysis: Have tried to incorporate ideas from Julien's evaluation draft, and describe the benefits of multihoming, grouped into 2 main categories: Fault Tolerance, Load Sharing. Like to seek comments from the WG on the draft, especially on the following points: - Are the scenarios/taxonomy representative enough? - Or are they too complex, too many of them? If so, what can be dropped? The objective is to merge the multihoming drafts as one WG draft. The question now is the scope and objectives of the WG draft. Presently, this is my initial take. - To capture the different scenarios for multihoming in Basic NEMO - To specify what are the scenarios supported by basic NEMO - To identify issues in these scenarios I am sure there is more to add. Do add in your thoughts on this so that we can formalized them in the Minneapolis Meeting. /rgds /cwng On Mon, 2003-10-27 at 19:25, Chan-Wah Ng wrote: > Hello, NEMO ML, > > see the forwarded message for the new version of multihoming draft. > Please take a look at it, and in a very short while, I will post a seed > mail to gather comments and suggestions for moving forward. > > Thanks > > /rgds > /cwng > > > -----Forwarded Message----- > From: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt > Date: Fri, 24 Oct 2003 10:37:04 -0400 > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Multi-Homing Issues in Bi-Directional Tunneling > Author(s) : C. Ng, J. Charbon > Filename : draft-ng-nemo-multihoming-issues-02.txt > Pages : 32 > Date : 2003-10-23 > > This document describes deployment scenario of multi-homed Network in > Motion (NEMO) and attempts to identify issues that arises when > supporting multi-homing in NEMO. It is also the objective of this > document to build a full taxonomy covering multi-homed scenarios in > NEMO, so as to facilitate explorations into this aspect of NEMO. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-02.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-ng-nemo-multihoming-issues-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ng-nemo-multihoming-issues-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ________________________________________________________________________ > Content-Type: text/plain > Content-ID: <2003-10-24102152.I-D@ietf.org> > > ______________________________________________________________________ > Content-Type: text/plain > Content-ID: <2003-10-24102152.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ng-nemo-multihoming-issues-02.txt > > ______________________________________________________________________ > Content-Type: text/plain > Content-ID: <2003-10-24102152.I-D@ietf.org> From exim@www1.ietf.org Thu Oct 30 02:49:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12913 for ; Thu, 30 Oct 2003 02:49:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF7YL-0002TA-7a for nemo-archive@odin.ietf.org; Thu, 30 Oct 2003 02:49:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U7n9Lu009490 for nemo-archive@odin.ietf.org; Thu, 30 Oct 2003 02:49:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF7YJ-0002Sy-DF for nemo-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 02:49:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12883 for ; Thu, 30 Oct 2003 02:48:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF7YF-00070B-00 for nemo-web-archive@ietf.org; Thu, 30 Oct 2003 02:49:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AF7YE-000706-00 for nemo-web-archive@ietf.org; Thu, 30 Oct 2003 02:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF7YE-0002SH-CK; Thu, 30 Oct 2003 02:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF7Xc-0002Pp-I2 for nemo@optimus.ietf.org; Thu, 30 Oct 2003 02:48:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12867 for ; Thu, 30 Oct 2003 02:48:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF7XY-0006zb-00 for nemo@ietf.org; Thu, 30 Oct 2003 02:48:20 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AF7XM-0006z6-00 for nemo@ietf.org; Thu, 30 Oct 2003 02:48:09 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id h9U7dqRn009276 for ; Thu, 30 Oct 2003 15:39:56 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 005C810E95DA for ; Thu, 30 Oct 2003 15:48:43 +0800 (SGT) Subject: Multihoming Discussion (was Re: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt]) From: Chan-Wah NG To: IETF NEMO WG In-Reply-To: <1067253929.2748.2.camel@localhost> References: <1067253929.2748.2.camel@localhost> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1067500123.1990.25.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 30 Oct 2003 15:48:43 +0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, NEMO WG, Here is a quick summary of changes to the new draft (differences between -01 and -02). taxonomy: I have included Erik's insights on subscriptions-based versus single ownership of NEMO and its home domain(s). Analysis: Have tried to incorporate ideas from Julien's evaluation draft, and describe the benefits of multihoming, grouped into 2 main categories: Fault Tolerance, Load Sharing. Like to seek comments from the WG on the draft, especially on the following points: - Are the scenarios/taxonomy representative enough? - Or are they too complex, too many of them? If so, what can be dropped? The objective is to merge the multihoming drafts as one WG draft. The question now is the scope and objectives of the WG draft. Presently, this is my initial take. - To capture the different scenarios for multihoming in Basic NEMO - To specify what are the scenarios supported by basic NEMO - To identify issues in these scenarios I am sure there is more to add. Do add in your thoughts on this so that we can formalized them in the Minneapolis Meeting. /rgds /cwng On Mon, 2003-10-27 at 19:25, Chan-Wah Ng wrote: > Hello, NEMO ML, > > see the forwarded message for the new version of multihoming draft. > Please take a look at it, and in a very short while, I will post a seed > mail to gather comments and suggestions for moving forward. > > Thanks > > /rgds > /cwng > > > -----Forwarded Message----- > From: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt > Date: Fri, 24 Oct 2003 10:37:04 -0400 > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Multi-Homing Issues in Bi-Directional Tunneling > Author(s) : C. Ng, J. Charbon > Filename : draft-ng-nemo-multihoming-issues-02.txt > Pages : 32 > Date : 2003-10-23 > > This document describes deployment scenario of multi-homed Network in > Motion (NEMO) and attempts to identify issues that arises when > supporting multi-homing in NEMO. It is also the objective of this > document to build a full taxonomy covering multi-homed scenarios in > NEMO, so as to facilitate explorations into this aspect of NEMO. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-02.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-ng-nemo-multihoming-issues-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ng-nemo-multihoming-issues-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ________________________________________________________________________ > Content-Type: text/plain > Content-ID: <2003-10-24102152.I-D@ietf.org> > > ______________________________________________________________________ > Content-Type: text/plain > Content-ID: <2003-10-24102152.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ng-nemo-multihoming-issues-02.txt > > ______________________________________________________________________ > Content-Type: text/plain > Content-ID: <2003-10-24102152.I-D@ietf.org> From nemo-admin@ietf.org Thu Oct 30 05:50:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17111 for ; Thu, 30 Oct 2003 05:50:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFANN-0004Kc-Sv; Thu, 30 Oct 2003 05:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFAMZ-0004GV-Su for nemo@optimus.ietf.org; Thu, 30 Oct 2003 05:49:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17047 for ; Thu, 30 Oct 2003 05:49:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFAMW-0001Ci-00 for nemo@ietf.org; Thu, 30 Oct 2003 05:49:08 -0500 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 1AFAMV-0001Ce-00 for nemo@ietf.org; Thu, 30 Oct 2003 05:49:07 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h9UAn6Y3024854; Thu, 30 Oct 2003 03:49:07 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h9UAn32M013110; Thu, 30 Oct 2003 04:49:05 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 480842EC95; Thu, 30 Oct 2003 11:49:03 +0100 (CET) Message-ID: <3FA0EC9F.5080105@motorola.com> Date: Thu, 30 Oct 2003 11:49:03 +0100 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: Chan-Wah NG Cc: IETF NEMO WG References: <1067253929.2748.2.camel@localhost> <1067500123.1990.25.camel@localhost> In-Reply-To: <1067500123.1990.25.camel@localhost> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Multihoming Discussion (was I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > The objective is to merge the multihoming drafts as one WG draft. Hello Chan-Wah, I agree that it would be good to join all the NEMO multi-homing drafts together into only one. This would consolidate the common multi-homing issues and present the reader a simpler view of multi-homing related to moving networks. One should also consider that there was some proposal for multi-homing discussion in the MIP6 WG as well. Do you know whether a "multi-homing" slot was allocated for the forthcoming MIP6 meeting? What would be the interactions between the MIP6 multi-homing work and the NEMO multi-homing work. At the same time, I've noticed a DT was working in the Multi6 WG multi-homing and two drafts are out now. How would NEMO WG multi-homing position itself with respect to this multi6 effort? And, finally, I believe that the HIP BoF is also looking forward to working on multi-homing aspects for mobility. Now coming back to the NEMO WG Charter, I find that it does mention "multi-homed network" in the opening statements, but I don't think it has multi-homing action points in the "will" and "will work on". So I'm not sure about the NEMO supposedly unique multi-homing document to become a WG item. I mean I would oppose that, unless charter modified. I'm not saying that that document is not useful, it's just about being or not being NEMO WG item. Alex GBU Chan-Wah NG wrote: > Hello, NEMO WG, > > Here is a quick summary of changes to the new draft (differences > between -01 and -02). > > taxonomy: I have included Erik's insights on subscriptions-based > versus single ownership of NEMO and its home domain(s). > > > Like to seek comments from the WG on the draft, especially on the > following points: > > - Are the scenarios/taxonomy representative enough? > > - Or are they too complex, too many of them? If so, what can be > dropped? > The > question now is the scope and objectives of the WG draft. Presently, > this is my initial take. > > - To capture the different scenarios for multihoming in Basic NEMO - > To specify what are the scenarios supported by basic NEMO - To > identify issues in these scenarios > > I am sure there is more to add. Do add in your thoughts on this so > that we can formalized them in the Minneapolis Meeting. > > /rgds /cwng > > > On Mon, 2003-10-27 at 19:25, Chan-Wah Ng wrote: > >> Hello, NEMO ML, >> >> see the forwarded message for the new version of multihoming draft. >> Please take a look at it, and in a very short while, I will post a >> seed mail to gather comments and suggestions for moving forward. >> >> Thanks >> >> /rgds /cwng >> >> >> -----Forwarded Message----- From: Internet-Drafts@ietf.org Subject: >> I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt Date: Fri, 24 >> Oct 2003 10:37:04 -0400 >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Multi-Homing Issues in Bi-Directional Tunneling Author(s) >> : C. Ng, J. Charbon Filename : >> draft-ng-nemo-multihoming-issues-02.txt Pages : 32 Date : >> 2003-10-23 This document describes deployment scenario of >> multi-homed Network in Motion (NEMO) and attempts to identify >> issues that arises when supporting multi-homing in NEMO. It is also >> the objective of this document to build a full taxonomy covering >> multi-homed scenarios in NEMO, so as to facilitate explorations >> into this aspect of NEMO. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-02.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-ng-nemo-multihoming-issues-02.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: mailserv@ietf.org. In the body type: "FILE >> /internet-drafts/draft-ng-nemo-multihoming-issues-02.txt". NOTE: >> The mail server at ietf.org can return the document in MIME-encoded >> form by using the "mpack" utility. To use this feature, insert >> the command "ENCODING mime" before the "FILE" command. To decode >> the response(s), you will need "munpack" or a MIME-compliant mail >> reader. Different MIME-compliant mail readers exhibit different >> behavior, especially when dealing with "multipart" MIME messages >> (i.e. documents which have been split up into multiple messages), >> so check your local documentation on how to manipulate these >> messages. Below is the data which will enable a MIME compliant >> mail reader implementation to automatically retrieve the ASCII >> version of the Internet-Draft. >> >> ________________________________________________________________________ >> Content-Type: text/plain Content-ID: >> <2003-10-24102152.I-D@ietf.org> >> >> ______________________________________________________________________ >> Content-Type: text/plain Content-ID: >> <2003-10-24102152.I-D@ietf.org> >> >> ENCODING mime FILE >> /internet-drafts/draft-ng-nemo-multihoming-issues-02.txt >> >> ______________________________________________________________________ >> Content-Type: text/plain Content-ID: >> <2003-10-24102152.I-D@ietf.org> > > > From exim@www1.ietf.org Thu Oct 30 05:50:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17126 for ; Thu, 30 Oct 2003 05:50:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFANQ-0004La-TU for nemo-archive@odin.ietf.org; Thu, 30 Oct 2003 05:50:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UAo40n016706 for nemo-archive@odin.ietf.org; Thu, 30 Oct 2003 05:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFANQ-0004LM-OD for nemo-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 05:50:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17093 for ; Thu, 30 Oct 2003 05:49:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFANN-0001Do-00 for nemo-web-archive@ietf.org; Thu, 30 Oct 2003 05:50:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFANM-0001Dl-00 for nemo-web-archive@ietf.org; Thu, 30 Oct 2003 05:50:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFANN-0004Kc-Sv; Thu, 30 Oct 2003 05:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFAMZ-0004GV-Su for nemo@optimus.ietf.org; Thu, 30 Oct 2003 05:49:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17047 for ; Thu, 30 Oct 2003 05:49:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFAMW-0001Ci-00 for nemo@ietf.org; Thu, 30 Oct 2003 05:49:08 -0500 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 1AFAMV-0001Ce-00 for nemo@ietf.org; Thu, 30 Oct 2003 05:49:07 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h9UAn6Y3024854; Thu, 30 Oct 2003 03:49:07 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h9UAn32M013110; Thu, 30 Oct 2003 04:49:05 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 480842EC95; Thu, 30 Oct 2003 11:49:03 +0100 (CET) Message-ID: <3FA0EC9F.5080105@motorola.com> Date: Thu, 30 Oct 2003 11:49:03 +0100 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: Chan-Wah NG Cc: IETF NEMO WG References: <1067253929.2748.2.camel@localhost> <1067500123.1990.25.camel@localhost> In-Reply-To: <1067500123.1990.25.camel@localhost> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Multihoming Discussion (was I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > The objective is to merge the multihoming drafts as one WG draft. Hello Chan-Wah, I agree that it would be good to join all the NEMO multi-homing drafts together into only one. This would consolidate the common multi-homing issues and present the reader a simpler view of multi-homing related to moving networks. One should also consider that there was some proposal for multi-homing discussion in the MIP6 WG as well. Do you know whether a "multi-homing" slot was allocated for the forthcoming MIP6 meeting? What would be the interactions between the MIP6 multi-homing work and the NEMO multi-homing work. At the same time, I've noticed a DT was working in the Multi6 WG multi-homing and two drafts are out now. How would NEMO WG multi-homing position itself with respect to this multi6 effort? And, finally, I believe that the HIP BoF is also looking forward to working on multi-homing aspects for mobility. Now coming back to the NEMO WG Charter, I find that it does mention "multi-homed network" in the opening statements, but I don't think it has multi-homing action points in the "will" and "will work on". So I'm not sure about the NEMO supposedly unique multi-homing document to become a WG item. I mean I would oppose that, unless charter modified. I'm not saying that that document is not useful, it's just about being or not being NEMO WG item. Alex GBU Chan-Wah NG wrote: > Hello, NEMO WG, > > Here is a quick summary of changes to the new draft (differences > between -01 and -02). > > taxonomy: I have included Erik's insights on subscriptions-based > versus single ownership of NEMO and its home domain(s). > > > Like to seek comments from the WG on the draft, especially on the > following points: > > - Are the scenarios/taxonomy representative enough? > > - Or are they too complex, too many of them? If so, what can be > dropped? > The > question now is the scope and objectives of the WG draft. Presently, > this is my initial take. > > - To capture the different scenarios for multihoming in Basic NEMO - > To specify what are the scenarios supported by basic NEMO - To > identify issues in these scenarios > > I am sure there is more to add. Do add in your thoughts on this so > that we can formalized them in the Minneapolis Meeting. > > /rgds /cwng > > > On Mon, 2003-10-27 at 19:25, Chan-Wah Ng wrote: > >> Hello, NEMO ML, >> >> see the forwarded message for the new version of multihoming draft. >> Please take a look at it, and in a very short while, I will post a >> seed mail to gather comments and suggestions for moving forward. >> >> Thanks >> >> /rgds /cwng >> >> >> -----Forwarded Message----- From: Internet-Drafts@ietf.org Subject: >> I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt Date: Fri, 24 >> Oct 2003 10:37:04 -0400 >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Multi-Homing Issues in Bi-Directional Tunneling Author(s) >> : C. Ng, J. Charbon Filename : >> draft-ng-nemo-multihoming-issues-02.txt Pages : 32 Date : >> 2003-10-23 This document describes deployment scenario of >> multi-homed Network in Motion (NEMO) and attempts to identify >> issues that arises when supporting multi-homing in NEMO. It is also >> the objective of this document to build a full taxonomy covering >> multi-homed scenarios in NEMO, so as to facilitate explorations >> into this aspect of NEMO. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-02.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-ng-nemo-multihoming-issues-02.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: mailserv@ietf.org. In the body type: "FILE >> /internet-drafts/draft-ng-nemo-multihoming-issues-02.txt". NOTE: >> The mail server at ietf.org can return the document in MIME-encoded >> form by using the "mpack" utility. To use this feature, insert >> the command "ENCODING mime" before the "FILE" command. To decode >> the response(s), you will need "munpack" or a MIME-compliant mail >> reader. Different MIME-compliant mail readers exhibit different >> behavior, especially when dealing with "multipart" MIME messages >> (i.e. documents which have been split up into multiple messages), >> so check your local documentation on how to manipulate these >> messages. Below is the data which will enable a MIME compliant >> mail reader implementation to automatically retrieve the ASCII >> version of the Internet-Draft. >> >> ________________________________________________________________________ >> Content-Type: text/plain Content-ID: >> <2003-10-24102152.I-D@ietf.org> >> >> ______________________________________________________________________ >> Content-Type: text/plain Content-ID: >> <2003-10-24102152.I-D@ietf.org> >> >> ENCODING mime FILE >> /internet-drafts/draft-ng-nemo-multihoming-issues-02.txt >> >> ______________________________________________________________________ >> Content-Type: text/plain Content-ID: >> <2003-10-24102152.I-D@ietf.org> > > > From nemo-admin@ietf.org Thu Oct 30 06:32:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18144 for ; Thu, 30 Oct 2003 06:32:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFB21-0000C3-PC; Thu, 30 Oct 2003 06:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFB1C-00007g-A8 for nemo@optimus.ietf.org; Thu, 30 Oct 2003 06:31:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18111 for ; Thu, 30 Oct 2003 06:30:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFB18-0001hG-00 for nemo@ietf.org; Thu, 30 Oct 2003 06:31:06 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AFB17-0001h8-00 for nemo@ietf.org; Thu, 30 Oct 2003 06:31:05 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 48C6A5D0A4; Thu, 30 Oct 2003 20:30:33 +0900 (JST) Date: Thu, 30 Oct 2003 20:25:02 +0900 From: Thierry Ernst To: Alexandru Petrescu Cc: cwng@psl.com.sg, nemo@ietf.org Subject: Re: [nemo] Re: Multihoming Discussion (was I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt) Message-Id: <20031030202502.24aa0242.ernst@sfc.wide.ad.jp> In-Reply-To: <3FA0EC9F.5080105@motorola.com> References: <1067253929.2748.2.camel@localhost> <1067500123.1990.25.camel@localhost> <3FA0EC9F.5080105@motorola.com> 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 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Alex, Alexandru Petrescu wrote: > > The objective is to merge the multihoming drafts as one WG draft. > > Hello Chan-Wah, > > I agree that it would be good to join all the NEMO multi-homing drafts > together into only one. This would consolidate the common multi-homing > issues and present the reader a simpler view of multi-homing related to > moving networks. > One should also consider that there was some proposal for multi-homing > discussion in the MIP6 WG as well. Do you know whether a "multi-homing" > slot was allocated for the forthcoming MIP6 meeting? What would be the > interactions between the MIP6 multi-homing work and the NEMO > multi-homing work. Chairs of the MIP6 don't agree to discuss multihoming although we requested (and insisted) for a slot and that a few drafts are out on this matter: - draft-wakikawa-mobileip-multiplecoa-02.txt - draft-montavont-mip6-mmi-01.txt - draft-montavont-mobileip-multihoming-pb-statement-00.txt - draft-montavont-mobileip-ha-filtering-v6-00.txt and others. So, there is going to be an unformal bar BOF to discuss multihoming and filtering aspects (see James Kempf announcement in the MIP6 WG). > At the same time, I've noticed a DT was working in the Multi6 WG > multi-homing and two drafts are out now. How would NEMO WG > multi-homing position itself with respect to this multi6 effort? This is different, terminology may be common, but the MULTI6 WG mostly addresses scalability issues when a network route is announced in multiple ISPs. Route table entries grows with the number of network a subnetwork is connected to. > And, finally, I believe that the HIP BoF is also looking forward to > working on multi-homing aspects for mobility. Let's say the mobility and multihoming have similar problems and thus probably similar solutions; a solution for multihoming may be mobility while a solution for mobility may be multihoming. The HIP BOF is to investigate a new addressing architecture and ways to better support open issues such as mobility and multihoming. > Now coming back to the NEMO WG Charter, I find that it does mention > "multi-homed network" in the opening statements, but I don't think it > has multi-homing action points in the "will" and "will work on". So I'm > not sure about the NEMO supposedly unique multi-homing document to > become a WG item. I mean I would oppose that, unless charter modified. > I'm not saying that that document is not useful, it's just about being > or not being NEMO WG item. The WG has agreed that it needs to devise a document on the multihoming issue at last IETF. But, so far, we haven't decided what will be put in the document. Also, it was pointed out during the meeting that we need to list what are the multihoming scenarios relevant to NEMO. Thierry. From exim@www1.ietf.org Thu Oct 30 06:32:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18159 for ; Thu, 30 Oct 2003 06:32:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFB24-0000DY-QW for nemo-archive@odin.ietf.org; Thu, 30 Oct 2003 06:32:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UBW4GA000829 for nemo-archive@odin.ietf.org; Thu, 30 Oct 2003 06:32:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFB24-0000DI-KT for nemo-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 06:32:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18138 for ; Thu, 30 Oct 2003 06:31:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFB20-0001hf-00 for nemo-web-archive@ietf.org; Thu, 30 Oct 2003 06:32:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFB20-0001hc-00 for nemo-web-archive@ietf.org; Thu, 30 Oct 2003 06:32:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFB21-0000C3-PC; Thu, 30 Oct 2003 06:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFB1C-00007g-A8 for nemo@optimus.ietf.org; Thu, 30 Oct 2003 06:31:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18111 for ; Thu, 30 Oct 2003 06:30:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFB18-0001hG-00 for nemo@ietf.org; Thu, 30 Oct 2003 06:31:06 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AFB17-0001h8-00 for nemo@ietf.org; Thu, 30 Oct 2003 06:31:05 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 48C6A5D0A4; Thu, 30 Oct 2003 20:30:33 +0900 (JST) Date: Thu, 30 Oct 2003 20:25:02 +0900 From: Thierry Ernst To: Alexandru Petrescu Cc: cwng@psl.com.sg, nemo@ietf.org Subject: Re: [nemo] Re: Multihoming Discussion (was I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt) Message-Id: <20031030202502.24aa0242.ernst@sfc.wide.ad.jp> In-Reply-To: <3FA0EC9F.5080105@motorola.com> References: <1067253929.2748.2.camel@localhost> <1067500123.1990.25.camel@localhost> <3FA0EC9F.5080105@motorola.com> 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 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Alex, Alexandru Petrescu wrote: > > The objective is to merge the multihoming drafts as one WG draft. > > Hello Chan-Wah, > > I agree that it would be good to join all the NEMO multi-homing drafts > together into only one. This would consolidate the common multi-homing > issues and present the reader a simpler view of multi-homing related to > moving networks. > One should also consider that there was some proposal for multi-homing > discussion in the MIP6 WG as well. Do you know whether a "multi-homing" > slot was allocated for the forthcoming MIP6 meeting? What would be the > interactions between the MIP6 multi-homing work and the NEMO > multi-homing work. Chairs of the MIP6 don't agree to discuss multihoming although we requested (and insisted) for a slot and that a few drafts are out on this matter: - draft-wakikawa-mobileip-multiplecoa-02.txt - draft-montavont-mip6-mmi-01.txt - draft-montavont-mobileip-multihoming-pb-statement-00.txt - draft-montavont-mobileip-ha-filtering-v6-00.txt and others. So, there is going to be an unformal bar BOF to discuss multihoming and filtering aspects (see James Kempf announcement in the MIP6 WG). > At the same time, I've noticed a DT was working in the Multi6 WG > multi-homing and two drafts are out now. How would NEMO WG > multi-homing position itself with respect to this multi6 effort? This is different, terminology may be common, but the MULTI6 WG mostly addresses scalability issues when a network route is announced in multiple ISPs. Route table entries grows with the number of network a subnetwork is connected to. > And, finally, I believe that the HIP BoF is also looking forward to > working on multi-homing aspects for mobility. Let's say the mobility and multihoming have similar problems and thus probably similar solutions; a solution for multihoming may be mobility while a solution for mobility may be multihoming. The HIP BOF is to investigate a new addressing architecture and ways to better support open issues such as mobility and multihoming. > Now coming back to the NEMO WG Charter, I find that it does mention > "multi-homed network" in the opening statements, but I don't think it > has multi-homing action points in the "will" and "will work on". So I'm > not sure about the NEMO supposedly unique multi-homing document to > become a WG item. I mean I would oppose that, unless charter modified. > I'm not saying that that document is not useful, it's just about being > or not being NEMO WG item. The WG has agreed that it needs to devise a document on the multihoming issue at last IETF. But, so far, we haven't decided what will be put in the document. Also, it was pointed out during the meeting that we need to list what are the multihoming scenarios relevant to NEMO. Thierry. From nemo-admin@ietf.org Thu Oct 30 06:50:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18731 for ; Thu, 30 Oct 2003 06:50:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBJS-00020d-1Y; Thu, 30 Oct 2003 06:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBIT-0001pK-RE for nemo@optimus.ietf.org; Thu, 30 Oct 2003 06:49:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18681 for ; Thu, 30 Oct 2003 06:48:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFBIP-0001u9-00 for nemo@ietf.org; Thu, 30 Oct 2003 06:48:57 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1AFBIO-0001u2-00 for nemo@ietf.org; Thu, 30 Oct 2003 06:48:57 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h9UBmq9x020937; Thu, 30 Oct 2003 04:48:56 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h9UBmm2M014571; Thu, 30 Oct 2003 05:48:49 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id CD4392EC98; Thu, 30 Oct 2003 12:48:47 +0100 (CET) Message-ID: <3FA0FA9F.5090604@motorola.com> Date: Thu, 30 Oct 2003 12:48:47 +0100 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: Thierry Ernst Cc: Alexandru Petrescu , cwng@psl.com.sg, nemo@ietf.org Subject: Re: [nemo] Re: Multihoming Discussion (was I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt) References: <1067253929.2748.2.camel@localhost> <1067500123.1990.25.camel@localhost> <3FA0EC9F.5080105@motorola.com> <20031030202502.24aa0242.ernst@sfc.wide.ad.jp> In-Reply-To: <20031030202502.24aa0242.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thierry Ernst wrote: >> One should also consider that there was some proposal for >> multi-homing discussion in the MIP6 WG as well. Do you know >> whether a "multi-homing" slot was allocated for the forthcoming >> MIP6 meeting? What would be the interactions between the MIP6 >> multi-homing work and the NEMO multi-homing work. > > Chairs of the MIP6 don't agree to discuss multihoming although we > requested (and insisted) for a slot and that a few drafts are out on > this matter: - draft-wakikawa-mobileip-multiplecoa-02.txt - > draft-montavont-mip6-mmi-01.txt - > draft-montavont-mobileip-multihoming-pb-statement-00.txt - > draft-montavont-mobileip-ha-filtering-v6-00.txt and others. Lack of consistency between MIP6 and NEMO? MIP6 won't treat of multi-homing but NEMO would? Isn't NEMO entirely based on Mobile IPv6? > So, there is going to be an unformal bar BOF to discuss multihoming > and filtering aspects (see James Kempf announcement in the MIP6 WG). So if the James Kempf bar BoF takes multi-homing (and filtering and switching) seriously, maybe they'd take on the NEMO multi-homing as well. >> At the same time, I've noticed a DT was working in the Multi6 WG >> multi-homing and two drafts are out now. How would NEMO WG >> multi-homing position itself with respect to this multi6 effort? > > > This is different, terminology may be common, but the MULTI6 WG > mostly addresses scalability issues when a network route is announced > in multiple ISPs. Route table entries grows with the number of > network a subnetwork is connected to. A-ha. And the mobile network being connected by several interfaces to a same home link (through the bidir tunnels) would not involve similar growth in the routing tables of the routers in the home domain? To me it's the same problem. >> And, finally, I believe that the HIP BoF is also looking forward to >> working on multi-homing aspects for mobility. > > > Let's say the mobility and multihoming have similar problems and thus > probably similar solutions; a solution for multihoming may be > mobility while a solution for mobility may be multihoming. The HIP > BOF is to investigate a new addressing architecture and ways to > better support open issues such as mobility and multihoming. A-ha. >> Now coming back to the NEMO WG Charter, I find that it does mention >> "multi-homed network" in the opening statements, but I don't think >> it has multi-homing action points in the "will" and "will work on". >> So I'm not sure about the NEMO supposedly unique multi-homing >> document to become a WG item. I mean I would oppose that, unless >> charter modified. I'm not saying that that document is not useful, >> it's just about being or not being NEMO WG item. > > > The WG has agreed that it needs to devise a document on the > multihoming issue at last IETF. But, so far, we haven't decided what > will be put in the document. Also, it was pointed out during the > meeting that we need to list what are the multihoming scenarios > relevant to NEMO. Ok that. So if the question about it becoming a WG item comes out I would oppose it unless Charter modified. Alex GBU From exim@www1.ietf.org Thu Oct 30 06:50:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18746 for ; Thu, 30 Oct 2003 06:50:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBJU-00021b-CA for nemo-archive@odin.ietf.org; Thu, 30 Oct 2003 06:50:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UBo472007777 for nemo-archive@odin.ietf.org; Thu, 30 Oct 2003 06:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBJU-00021M-19 for nemo-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 06:50:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18712 for ; Thu, 30 Oct 2003 06:49:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFBJP-0001uf-00 for nemo-web-archive@ietf.org; Thu, 30 Oct 2003 06:49:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFBJP-0001uc-00 for nemo-web-archive@ietf.org; Thu, 30 Oct 2003 06:49:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBJS-00020d-1Y; Thu, 30 Oct 2003 06:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBIT-0001pK-RE for nemo@optimus.ietf.org; Thu, 30 Oct 2003 06:49:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18681 for ; Thu, 30 Oct 2003 06:48:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFBIP-0001u9-00 for nemo@ietf.org; Thu, 30 Oct 2003 06:48:57 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1AFBIO-0001u2-00 for nemo@ietf.org; Thu, 30 Oct 2003 06:48:57 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h9UBmq9x020937; Thu, 30 Oct 2003 04:48:56 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h9UBmm2M014571; Thu, 30 Oct 2003 05:48:49 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id CD4392EC98; Thu, 30 Oct 2003 12:48:47 +0100 (CET) Message-ID: <3FA0FA9F.5090604@motorola.com> Date: Thu, 30 Oct 2003 12:48:47 +0100 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: Thierry Ernst Cc: Alexandru Petrescu , cwng@psl.com.sg, nemo@ietf.org Subject: Re: [nemo] Re: Multihoming Discussion (was I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt) References: <1067253929.2748.2.camel@localhost> <1067500123.1990.25.camel@localhost> <3FA0EC9F.5080105@motorola.com> <20031030202502.24aa0242.ernst@sfc.wide.ad.jp> In-Reply-To: <20031030202502.24aa0242.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thierry Ernst wrote: >> One should also consider that there was some proposal for >> multi-homing discussion in the MIP6 WG as well. Do you know >> whether a "multi-homing" slot was allocated for the forthcoming >> MIP6 meeting? What would be the interactions between the MIP6 >> multi-homing work and the NEMO multi-homing work. > > Chairs of the MIP6 don't agree to discuss multihoming although we > requested (and insisted) for a slot and that a few drafts are out on > this matter: - draft-wakikawa-mobileip-multiplecoa-02.txt - > draft-montavont-mip6-mmi-01.txt - > draft-montavont-mobileip-multihoming-pb-statement-00.txt - > draft-montavont-mobileip-ha-filtering-v6-00.txt and others. Lack of consistency between MIP6 and NEMO? MIP6 won't treat of multi-homing but NEMO would? Isn't NEMO entirely based on Mobile IPv6? > So, there is going to be an unformal bar BOF to discuss multihoming > and filtering aspects (see James Kempf announcement in the MIP6 WG). So if the James Kempf bar BoF takes multi-homing (and filtering and switching) seriously, maybe they'd take on the NEMO multi-homing as well. >> At the same time, I've noticed a DT was working in the Multi6 WG >> multi-homing and two drafts are out now. How would NEMO WG >> multi-homing position itself with respect to this multi6 effort? > > > This is different, terminology may be common, but the MULTI6 WG > mostly addresses scalability issues when a network route is announced > in multiple ISPs. Route table entries grows with the number of > network a subnetwork is connected to. A-ha. And the mobile network being connected by several interfaces to a same home link (through the bidir tunnels) would not involve similar growth in the routing tables of the routers in the home domain? To me it's the same problem. >> And, finally, I believe that the HIP BoF is also looking forward to >> working on multi-homing aspects for mobility. > > > Let's say the mobility and multihoming have similar problems and thus > probably similar solutions; a solution for multihoming may be > mobility while a solution for mobility may be multihoming. The HIP > BOF is to investigate a new addressing architecture and ways to > better support open issues such as mobility and multihoming. A-ha. >> Now coming back to the NEMO WG Charter, I find that it does mention >> "multi-homed network" in the opening statements, but I don't think >> it has multi-homing action points in the "will" and "will work on". >> So I'm not sure about the NEMO supposedly unique multi-homing >> document to become a WG item. I mean I would oppose that, unless >> charter modified. I'm not saying that that document is not useful, >> it's just about being or not being NEMO WG item. > > > The WG has agreed that it needs to devise a document on the > multihoming issue at last IETF. But, so far, we haven't decided what > will be put in the document. Also, it was pointed out during the > meeting that we need to list what are the multihoming scenarios > relevant to NEMO. Ok that. So if the question about it becoming a WG item comes out I would oppose it unless Charter modified. Alex GBU From nemo-admin@ietf.org Thu Oct 30 07:21:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19518 for ; Thu, 30 Oct 2003 07:21:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBnR-0005lD-Oz; Thu, 30 Oct 2003 07:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBmp-0005jy-74 for nemo@optimus.ietf.org; Thu, 30 Oct 2003 07:20:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19501 for ; Thu, 30 Oct 2003 07:20:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFBmo-0002Gx-00 for nemo@ietf.org; Thu, 30 Oct 2003 07:20:22 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AFBmn-0002Gc-00 for nemo@ietf.org; Thu, 30 Oct 2003 07:20:21 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 496F45D084; Thu, 30 Oct 2003 21:19:27 +0900 (JST) Date: Thu, 30 Oct 2003 21:13:55 +0900 From: Thierry Ernst To: Alexandru Petrescu Cc: alexandru.petrescu@motorola.com, cwng@psl.com.sg, nemo@ietf.org Subject: Re: [nemo] Re: Multihoming Discussion (was I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt) Message-Id: <20031030211355.38b8b3a5.ernst@sfc.wide.ad.jp> In-Reply-To: <3FA0FA9F.5090604@motorola.com> References: <1067253929.2748.2.camel@localhost> <1067500123.1990.25.camel@localhost> <3FA0EC9F.5080105@motorola.com> <20031030202502.24aa0242.ernst@sfc.wide.ad.jp> <3FA0FA9F.5090604@motorola.com> 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 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > > Chairs of the MIP6 don't agree to discuss multihoming although we > > requested (and insisted) for a slot and that a few drafts are out on > > this matter: - draft-wakikawa-mobileip-multiplecoa-02.txt - > > draft-montavont-mip6-mmi-01.txt - > > draft-montavont-mobileip-multihoming-pb-statement-00.txt - > > draft-montavont-mobileip-ha-filtering-v6-00.txt and others. > > Lack of consistency between MIP6 and NEMO? MIP6 won't treat of > multi-homing but NEMO would? Isn't NEMO entirely based on Mobile IPv6? Asks this to the NEMO chairs. They said that if there is active discussion on the ML they might consider a slot to discuss the question. > > So, there is going to be an unformal bar BOF to discuss multihoming > > and filtering aspects (see James Kempf announcement in the MIP6 WG). > > So if the James Kempf bar BoF takes multi-homing (and filtering and > switching) seriously, maybe they'd take on the NEMO multi-homing as well. The issue will be raised if someone raise it; at least I will. But it's just a BAR bof. Just a discussion. No body knows how the discussion may turn to. > >> At the same time, I've noticed a DT was working in the Multi6 WG > >> multi-homing and two drafts are out now. How would NEMO WG > >> multi-homing position itself with respect to this multi6 effort? > > > > > > This is different, terminology may be common, but the MULTI6 WG > > mostly addresses scalability issues when a network route is announced > > in multiple ISPs. Route table entries grows with the number of > > network a subnetwork is connected to. > > A-ha. And the mobile network being connected by several interfaces to a > same home link (through the bidir tunnels) would not involve similar > growth in the routing tables of the routers in the home domain? To me > it's the same problem. A mobile network being multihomed does not necesserily make the routing tables growing. It may, and this case is covered by multi6. But multi6 does not consider the other issues which arise for multihomed hosts and networks. > >> Now coming back to the NEMO WG Charter, I find that it does mention > >> "multi-homed network" in the opening statements, but I don't think > >> it has multi-homing action points in the "will" and "will work on". > >> So I'm not sure about the NEMO supposedly unique multi-homing > >> document to become a WG item. I mean I would oppose that, unless > >> charter modified. I'm not saying that that document is not useful, > >> it's just about being or not being NEMO WG item. > > > > > > The WG has agreed that it needs to devise a document on the > > multihoming issue at last IETF. But, so far, we haven't decided what > > will be put in the document. Also, it was pointed out during the > > meeting that we need to list what are the multihoming scenarios > > relevant to NEMO. > > Ok that. So if the question about it becoming a WG item comes out I > would oppose it unless Charter modified. The working group has agreed to have a draft-ietf-nemo-multihoming-something. The something is not clear yet. Once it's clear it will be listed as a WG milestone. So, of course the charter will be updated to list the new item. Thierry. From exim@www1.ietf.org Thu Oct 30 07:21:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19533 for ; Thu, 30 Oct 2003 07:21:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBnU-0005mX-JY for nemo-archive@odin.ietf.org; Thu, 30 Oct 2003 07:21:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UCL4Ye022219 for nemo-archive@odin.ietf.org; Thu, 30 Oct 2003 07:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBnU-0005mI-EV for nemo-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 07:21:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19512 for ; Thu, 30 Oct 2003 07:20:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFBnU-0002HB-00 for nemo-web-archive@ietf.org; Thu, 30 Oct 2003 07:21:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFBnT-0002H8-00 for nemo-web-archive@ietf.org; Thu, 30 Oct 2003 07:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBnR-0005lD-Oz; Thu, 30 Oct 2003 07:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFBmp-0005jy-74 for nemo@optimus.ietf.org; Thu, 30 Oct 2003 07:20:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19501 for ; Thu, 30 Oct 2003 07:20:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFBmo-0002Gx-00 for nemo@ietf.org; Thu, 30 Oct 2003 07:20:22 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AFBmn-0002Gc-00 for nemo@ietf.org; Thu, 30 Oct 2003 07:20:21 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 496F45D084; Thu, 30 Oct 2003 21:19:27 +0900 (JST) Date: Thu, 30 Oct 2003 21:13:55 +0900 From: Thierry Ernst To: Alexandru Petrescu Cc: alexandru.petrescu@motorola.com, cwng@psl.com.sg, nemo@ietf.org Subject: Re: [nemo] Re: Multihoming Discussion (was I-D ACTION:draft-ng-nemo-multihoming-issues-02.txt) Message-Id: <20031030211355.38b8b3a5.ernst@sfc.wide.ad.jp> In-Reply-To: <3FA0FA9F.5090604@motorola.com> References: <1067253929.2748.2.camel@localhost> <1067500123.1990.25.camel@localhost> <3FA0EC9F.5080105@motorola.com> <20031030202502.24aa0242.ernst@sfc.wide.ad.jp> <3FA0FA9F.5090604@motorola.com> 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 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > > Chairs of the MIP6 don't agree to discuss multihoming although we > > requested (and insisted) for a slot and that a few drafts are out on > > this matter: - draft-wakikawa-mobileip-multiplecoa-02.txt - > > draft-montavont-mip6-mmi-01.txt - > > draft-montavont-mobileip-multihoming-pb-statement-00.txt - > > draft-montavont-mobileip-ha-filtering-v6-00.txt and others. > > Lack of consistency between MIP6 and NEMO? MIP6 won't treat of > multi-homing but NEMO would? Isn't NEMO entirely based on Mobile IPv6? Asks this to the NEMO chairs. They said that if there is active discussion on the ML they might consider a slot to discuss the question. > > So, there is going to be an unformal bar BOF to discuss multihoming > > and filtering aspects (see James Kempf announcement in the MIP6 WG). > > So if the James Kempf bar BoF takes multi-homing (and filtering and > switching) seriously, maybe they'd take on the NEMO multi-homing as well. The issue will be raised if someone raise it; at least I will. But it's just a BAR bof. Just a discussion. No body knows how the discussion may turn to. > >> At the same time, I've noticed a DT was working in the Multi6 WG > >> multi-homing and two drafts are out now. How would NEMO WG > >> multi-homing position itself with respect to this multi6 effort? > > > > > > This is different, terminology may be common, but the MULTI6 WG > > mostly addresses scalability issues when a network route is announced > > in multiple ISPs. Route table entries grows with the number of > > network a subnetwork is connected to. > > A-ha. And the mobile network being connected by several interfaces to a > same home link (through the bidir tunnels) would not involve similar > growth in the routing tables of the routers in the home domain? To me > it's the same problem. A mobile network being multihomed does not necesserily make the routing tables growing. It may, and this case is covered by multi6. But multi6 does not consider the other issues which arise for multihomed hosts and networks. > >> Now coming back to the NEMO WG Charter, I find that it does mention > >> "multi-homed network" in the opening statements, but I don't think > >> it has multi-homing action points in the "will" and "will work on". > >> So I'm not sure about the NEMO supposedly unique multi-homing > >> document to become a WG item. I mean I would oppose that, unless > >> charter modified. I'm not saying that that document is not useful, > >> it's just about being or not being NEMO WG item. > > > > > > The WG has agreed that it needs to devise a document on the > > multihoming issue at last IETF. But, so far, we haven't decided what > > will be put in the document. Also, it was pointed out during the > > meeting that we need to list what are the multihoming scenarios > > relevant to NEMO. > > Ok that. So if the question about it becoming a WG item comes out I > would oppose it unless Charter modified. The working group has agreed to have a draft-ietf-nemo-multihoming-something. The something is not clear yet. Once it's clear it will be listed as a WG milestone. So, of course the charter will be updated to list the new item. Thierry. From nemo-admin@ietf.org Thu Oct 30 07:55:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20416 for ; Thu, 30 Oct 2003 07:55:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFCKM-00017E-P3; Thu, 30 Oct 2003 07:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFCJN-0000lp-GC for nemo@optimus.ietf.org; Thu, 30 Oct 2003 07:54:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20324 for ; Thu, 30 Oct 2003 07:53:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFCJM-0002fp-00 for nemo@ietf.org; Thu, 30 Oct 2003 07:54:00 -0500 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx with esmtp (Exim 4.12) id 1AFCJL-0002fm-00 for nemo@ietf.org; Thu, 30 Oct 2003 07:53:59 -0500 Received: (from eun@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id h9UCrpA11471; Thu, 30 Oct 2003 21:53:51 +0900 (KST) (envelope-from eun) Date: Thu, 30 Oct 2003 21:53:51 +0900 From: Eun Kyoung Paik To: nemo@ietf.org Message-ID: <20031030215351.A11376@mmlab.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [nemo] new draft on multihoming Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi all, A New Internet-Draft is available from the on-line Internet-Drafts directories. Your comments on this draft are very welcome. Title : Multihomed Mobile Networks Problem Statements Author(s) : E. Paik, et. al. Filename : draft-paik-nemo-multihoming-problem-00.txt Pages : 5 Date : 2003-10-20 This document describes the needs for multihoming support in network mobility (NEMO). Issues from designing and implementing multihomed mobile networks are analyzed in terms of mutiple connections management and usage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-paik-nemo-multihoming-problem-00.txt Regards, Eun Kyoung From exim@www1.ietf.org Thu Oct 30 07:55:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20431 for ; Thu, 30 Oct 2003 07:55:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFCKQ-00018F-7s for nemo-archive@odin.ietf.org; Thu, 30 Oct 2003 07:55:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UCt61a004350 for nemo-archive@odin.ietf.org; Thu, 30 Oct 2003 07:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFCKQ-000185-0e for nemo-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 07:55:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20400 for ; Thu, 30 Oct 2003 07:54:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFCKP-0002hD-00 for nemo-web-archive@ietf.org; Thu, 30 Oct 2003 07:55:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFCKO-0002hA-00 for nemo-web-archive@ietf.org; Thu, 30 Oct 2003 07:55:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFCKM-00017E-P3; Thu, 30 Oct 2003 07:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFCJN-0000lp-GC for nemo@optimus.ietf.org; Thu, 30 Oct 2003 07:54:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20324 for ; Thu, 30 Oct 2003 07:53:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFCJM-0002fp-00 for nemo@ietf.org; Thu, 30 Oct 2003 07:54:00 -0500 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx with esmtp (Exim 4.12) id 1AFCJL-0002fm-00 for nemo@ietf.org; Thu, 30 Oct 2003 07:53:59 -0500 Received: (from eun@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id h9UCrpA11471; Thu, 30 Oct 2003 21:53:51 +0900 (KST) (envelope-from eun) Date: Thu, 30 Oct 2003 21:53:51 +0900 From: Eun Kyoung Paik To: nemo@ietf.org Message-ID: <20031030215351.A11376@mmlab.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [nemo] new draft on multihoming Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi all, A New Internet-Draft is available from the on-line Internet-Drafts directories. Your comments on this draft are very welcome. Title : Multihomed Mobile Networks Problem Statements Author(s) : E. Paik, et. al. Filename : draft-paik-nemo-multihoming-problem-00.txt Pages : 5 Date : 2003-10-20 This document describes the needs for multihoming support in network mobility (NEMO). Issues from designing and implementing multihomed mobile networks are analyzed in terms of mutiple connections management and usage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-paik-nemo-multihoming-problem-00.txt Regards, Eun Kyoung From nemo-admin@ietf.org Fri Oct 31 08:13:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26960 for ; Fri, 31 Oct 2003 08:13:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZ5K-0002c4-34; Fri, 31 Oct 2003 08:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZ4S-0002Un-Sq for nemo@optimus.ietf.org; Fri, 31 Oct 2003 08:12:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26924 for ; Fri, 31 Oct 2003 08:11:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFZ4R-0007Yv-00 for nemo@ietf.org; Fri, 31 Oct 2003 08:12:07 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AFZ4R-0007YO-00 for nemo@ietf.org; Fri, 31 Oct 2003 08:12:07 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2003 14:09:28 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h9VDAoi9002853; Fri, 31 Oct 2003 14:11:28 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 31 Oct 2003 13:11:08 +0000 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" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Oct 2003 12:22:53 -0000 Message-ID: Thread-Topic: May I ask some questions? Thread-Index: AcOdO6SrtXBCiJInSFyLCpINqyAZAACbXvyA From: "Pascal Thubert (pthubert)" To: "???" Cc: X-OriginalArrivalTime: 31 Oct 2003 13:11:08.0291 (UTC) FILETIME=[72A3E530:01C39FB0] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: May I ask some questions? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Kim, These are identifiers used to recognize the tree TLMR as a uid and a gid. This allows a MR to select a tree to join based on whom the TLMR is (TLMR Identifier) or which group it belongs to. Pascal=20 > -----Original Message----- > From: iris1993@ewha.ac.kr [mailto:iris1993@ewha.ac.kr] > Sent: mardi 28 octobre 2003 11:11 > To: Pascal Thubert (pthubert) > Subject: May I ask some questions? >=20 > Dear Sir >=20 > I am writing to ask some questions of your NEMO draft, named IPv6 Reverse Routing Header and > its application to Mobile Network >=20 > I shortly introduce myself to you. I am a master student of Ewha Institute of Science and > Technology in Korea Republic. >=20 > When I was reading your draft, I couldn't understand difference between Tree TLMR Identifier > and Tree Group in New Tree Information Option Format >=20 > I hope you will consider my question and also to hear from you at your earliest convenience. >=20 > Yours sincerely >=20 > Soo Jeong Kim, Master Student. > Information Communications and Network Security Lab. > Dept. of Computer Science & Engineering > Ewha Womans University > 11-1, Daehyun-Dong, Seodaemun-Ku > Seoul 120-750, Korea > Tel: +82-2-3277-3506 > Fax: +82-2-3277-2306 > E-mail: iris1993@ewha.ac.kr > http://net.ewha.ac.kr From nemo-admin@ietf.org Fri Oct 31 08:13:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26961 for ; Fri, 31 Oct 2003 08:13:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZ5J-0002bv-HW; Fri, 31 Oct 2003 08:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZ4T-0002Uo-BN for nemo@optimus.ietf.org; Fri, 31 Oct 2003 08:12:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26927 for ; Fri, 31 Oct 2003 08:11:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFZ4S-0007Z0-00 for nemo@ietf.org; Fri, 31 Oct 2003 08:12:08 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AFZ4R-0007YO-01 for nemo@ietf.org; Fri, 31 Oct 2003 08:12:07 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2003 14:09:31 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h9VDAoiD002853 for ; Fri, 31 Oct 2003 14:11:30 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 31 Oct 2003 13:11:38 +0000 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" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Oct 2003 12:29:26 -0000 Message-ID: Thread-Topic: Question on NEMO Thread-Index: AcOcU9hpxt0lWk/2TXWzPhsCBC6LFADVcKPg From: "Pascal Thubert (pthubert)" To: "Alvin Wo" Cc: X-OriginalArrivalTime: 31 Oct 2003 13:11:38.0792 (UTC) FILETIME=[84D1FA80:01C39FB0] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Question on NEMO Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Alvin, Well, by definition it will not be a LFN any more, but a 'nemo aware' node. The answer may depend on the RO technology. With RRH, the LFN can send an 'empty' RRH with its packets. Means that all fields are zeroed out, no home address in it. The result is that the packet flows straight to the CN, and if the CN accepts to reverse the RRH into a RH2,the responses flow right back. Obviously, there should be some RR test added somewhere in the picture, but that gives you an idea. We use that for instance to perform DHAAD, this allows complex nested configurations to come up, when HAs are also MRs and form an arbitrary tree. Pascal > -----Original Message----- > From: Alvin Wo [mailto:alvinwwp@hotmail.com] > Sent: lundi 27 octobre 2003 07:30 > To: Pascal Thubert (pthubert) > Subject: Question on NEMO >=20 > Dear Sir, >=20 > According to NEMO, LFN only has IPv6 and not MIPv6 capabilities, so is > unable to perform Route Optimization to MN (currently is MN perform RO to > LFN?). Is that if there is any way that I can incoporate Mobile IPv6 > capabilities into LFN without increasing the signal overheads, and carry out > RO? >=20 > Thank you. >=20 > Cheers, > Alvin >=20 > _________________________________________________________________ > Take a break! Find destinations on MSN Travel. http://www.msn.com.sg/travel/ From exim@www1.ietf.org Fri Oct 31 08:13:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26977 for ; Fri, 31 Oct 2003 08:13:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZ5N-0002dl-6s for nemo-archive@odin.ietf.org; Fri, 31 Oct 2003 08:13:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VDD5wL010144 for nemo-archive@odin.ietf.org; Fri, 31 Oct 2003 08:13:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZ5N-0002dX-0b for nemo-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 08:13:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26944 for ; Fri, 31 Oct 2003 08:12:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFZ5L-0007Zm-00 for nemo-web-archive@ietf.org; Fri, 31 Oct 2003 08:13:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFZ5L-0007Zg-00 for nemo-web-archive@ietf.org; Fri, 31 Oct 2003 08:13:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZ5J-0002bv-HW; Fri, 31 Oct 2003 08:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZ4T-0002Uo-BN for nemo@optimus.ietf.org; Fri, 31 Oct 2003 08:12:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26927 for ; Fri, 31 Oct 2003 08:11:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFZ4S-0007Z0-00 for nemo@ietf.org; Fri, 31 Oct 2003 08:12:08 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AFZ4R-0007YO-01 for nemo@ietf.org; Fri, 31 Oct 2003 08:12:07 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2003 14:09:31 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h9VDAoiD002853 for ; Fri, 31 Oct 2003 14:11:30 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 31 Oct 2003 13:11:38 +0000 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" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Oct 2003 12:29:26 -0000 Message-ID: Thread-Topic: Question on NEMO Thread-Index: AcOcU9hpxt0lWk/2TXWzPhsCBC6LFADVcKPg From: "Pascal Thubert (pthubert)" To: "Alvin Wo" Cc: X-OriginalArrivalTime: 31 Oct 2003 13:11:38.0792 (UTC) FILETIME=[84D1FA80:01C39FB0] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Question on NEMO Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Alvin, Well, by definition it will not be a LFN any more, but a 'nemo aware' node. The answer may depend on the RO technology. With RRH, the LFN can send an 'empty' RRH with its packets. Means that all fields are zeroed out, no home address in it. The result is that the packet flows straight to the CN, and if the CN accepts to reverse the RRH into a RH2,the responses flow right back. Obviously, there should be some RR test added somewhere in the picture, but that gives you an idea. We use that for instance to perform DHAAD, this allows complex nested configurations to come up, when HAs are also MRs and form an arbitrary tree. Pascal > -----Original Message----- > From: Alvin Wo [mailto:alvinwwp@hotmail.com] > Sent: lundi 27 octobre 2003 07:30 > To: Pascal Thubert (pthubert) > Subject: Question on NEMO >=20 > Dear Sir, >=20 > According to NEMO, LFN only has IPv6 and not MIPv6 capabilities, so is > unable to perform Route Optimization to MN (currently is MN perform RO to > LFN?). Is that if there is any way that I can incoporate Mobile IPv6 > capabilities into LFN without increasing the signal overheads, and carry out > RO? >=20 > Thank you. >=20 > Cheers, > Alvin >=20 > _________________________________________________________________ > Take a break! Find destinations on MSN Travel. http://www.msn.com.sg/travel/ From exim@www1.ietf.org Fri Oct 31 09:00:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26978 for ; Fri, 31 Oct 2003 08:13:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZ5N-0002eA-BR for nemo-archive@odin.ietf.org; Fri, 31 Oct 2003 08:13:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VDD5XP010160 for nemo-archive@odin.ietf.org; Fri, 31 Oct 2003 08:13:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZ5N-0002de-5Y for nemo-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 08:13:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26946 for ; Fri, 31 Oct 2003 08:12:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFZ5L-0007Zq-00 for nemo-web-archive@ietf.org; Fri, 31 Oct 2003 08:13:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFZ5L-0007Zh-00 for nemo-web-archive@ietf.org; Fri, 31 Oct 2003 08:13:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZ5K-0002c4-34; Fri, 31 Oct 2003 08:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZ4S-0002Un-Sq for nemo@optimus.ietf.org; Fri, 31 Oct 2003 08:12:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26924 for ; Fri, 31 Oct 2003 08:11:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFZ4R-0007Yv-00 for nemo@ietf.org; Fri, 31 Oct 2003 08:12:07 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AFZ4R-0007YO-00 for nemo@ietf.org; Fri, 31 Oct 2003 08:12:07 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2003 14:09:28 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h9VDAoi9002853; Fri, 31 Oct 2003 14:11:28 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 31 Oct 2003 13:11:08 +0000 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" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Oct 2003 12:22:53 -0000 Message-ID: Thread-Topic: May I ask some questions? Thread-Index: AcOdO6SrtXBCiJInSFyLCpINqyAZAACbXvyA From: "Pascal Thubert (pthubert)" To: "???" Cc: X-OriginalArrivalTime: 31 Oct 2003 13:11:08.0291 (UTC) FILETIME=[72A3E530:01C39FB0] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: May I ask some questions? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Kim, These are identifiers used to recognize the tree TLMR as a uid and a gid. This allows a MR to select a tree to join based on whom the TLMR is (TLMR Identifier) or which group it belongs to. Pascal=20 > -----Original Message----- > From: iris1993@ewha.ac.kr [mailto:iris1993@ewha.ac.kr] > Sent: mardi 28 octobre 2003 11:11 > To: Pascal Thubert (pthubert) > Subject: May I ask some questions? >=20 > Dear Sir >=20 > I am writing to ask some questions of your NEMO draft, named IPv6 Reverse Routing Header and > its application to Mobile Network >=20 > I shortly introduce myself to you. I am a master student of Ewha Institute of Science and > Technology in Korea Republic. >=20 > When I was reading your draft, I couldn't understand difference between Tree TLMR Identifier > and Tree Group in New Tree Information Option Format >=20 > I hope you will consider my question and also to hear from you at your earliest convenience. >=20 > Yours sincerely >=20 > Soo Jeong Kim, Master Student. > Information Communications and Network Security Lab. > Dept. of Computer Science & Engineering > Ewha Womans University > 11-1, Daehyun-Dong, Seodaemun-Ku > Seoul 120-750, Korea > Tel: +82-2-3277-3506 > Fax: +82-2-3277-2306 > E-mail: iris1993@ewha.ac.kr > http://net.ewha.ac.kr