From dna-owner@webcamserver.eng.monash.edu.au Fri Oct 1 15:54:30 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11379 for ; Fri, 1 Oct 2004 15:54:28 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LFJN3988HK9EGFI1@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 02 Oct 2004 05:52:36 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7C5DAAB543; Sat, 02 Oct 2004 05:52:09 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 839A34FB07; Sat, 02 Oct 2004 05:52:03 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i91Joh719223 for dna-list; Sat, 02 Oct 2004 05:50:43 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i91JoX619218 for ; Sat, 02 Oct 2004 05:50:34 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LFJN139EMK9X41EJ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 02 Oct 2004 05:50:25 +1000 Received: by localhost (Postfix, from userid 510) id 75D0F80003; Sat, 02 Oct 2004 05:50:25 +1000 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by larry.its.monash.edu.au (Postfix) with ESMTP id F0F473C005 for ; Sat, 02 Oct 2004 05:50:22 +1000 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11033; Fri, 01 Oct 2004 15:50:19 -0400 (EDT) Date: Fri, 01 Oct 2004 15:50:19 -0400 From: Internet-Drafts@ietf.org Subject: [DNA] I-D ACTION:draft-ietf-dna-goals-02.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: i-d-announce@ietf.org Cc: dna@eng.monash.edu.au Message-id: <200410011950.PAA11033@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_IxiwhQu+PdgAxaCwWs7Sxg)" Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) --Boundary_(ID_IxiwhQu+PdgAxaCwWs7Sxg) Content-type: TEXT/PLAIN Content-Transfer-Encoding: 7BIT A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Detecting Network Attachment Working Group of the IETF. Title : Detecting Network Attachment in IPv6 Goals Author(s) : J. Choi, G. Daley Filename : draft-ietf-dna-goals-02.txt Pages : 15 Date : 2004-10-1 At the time a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change, i.e. determine whether a link change has occurred, and then, based on the result, it can automatically decide whether its IP configuration is still valid or not. During link identity detection, the host may also collect necessary information to initiate a new IP configuration for the case that the IP subnet has changed. In this memo, this procedure is called Detecting Network Attachment (DNA). DNA schemes should be precise, sufficiently fast, secure and of limited signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dna-goals-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dna-goals-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-ietf-dna-goals-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. --Boundary_(ID_IxiwhQu+PdgAxaCwWs7Sxg) Content-type: multipart/alternative; boundary="Boundary_(ID_vS2ftlGSG4YkSO4dnEAHsQ)" --Boundary_(ID_vS2ftlGSG4YkSO4dnEAHsQ) Content-type: Message/External-body; access-type=mail-server; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-1153531.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dna-goals-02.txt --Boundary_(ID_vS2ftlGSG4YkSO4dnEAHsQ) Content-type: Message/External-body; name=draft-ietf-dna-goals-02.txt; site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts Content-disposition: attachment; filename=draft-ietf-dna-goals-02.txt Content-Type: text/plain Content-ID: <2004-10-1153531.I-D@ietf.org> --Boundary_(ID_vS2ftlGSG4YkSO4dnEAHsQ)-- --Boundary_(ID_IxiwhQu+PdgAxaCwWs7Sxg)-- From dna-owner@webcamserver.eng.monash.edu.au Fri Oct 1 20:21:33 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12754 for ; Fri, 1 Oct 2004 20:21:31 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LFJWGZMSU68ZE8OV@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 2 Oct 2004 10:20:40 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E502980004; Sat, 02 Oct 2004 10:20:32 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 9E8423C007; Sat, 02 Oct 2004 10:20:32 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i920Jt521703 for dna-list; Sat, 02 Oct 2004 10:19:55 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i920Jr621699 for ; Sat, 02 Oct 2004 10:19:53 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LFJWG041UA9EGFGS@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 02 Oct 2004 10:19:45 +1000 Received: by localhost (Postfix, from userid 510) id AAD52AB571; Sat, 02 Oct 2004 10:19:09 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by moe.its.monash.edu.au (Postfix) with ESMTP id EB33A4FB05; Sat, 02 Oct 2004 10:19:07 +1000 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I4X00L01KVSAV@mailout2.samsung.com>; Sat, 02 Oct 2004 09:19:04 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I4X00BHJKVSK7@mailout2.samsung.com>; Sat, 02 Oct 2004 09:19:04 +0900 (KST) Received: from jinchoe ([75.2.91.231]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I4X00HHYKVSYU@mmp2.samsung.com>; Sat, 02 Oct 2004 09:19:04 +0900 (KST) Date: Sat, 02 Oct 2004 09:19:03 +0900 From: JinHyeock Choi Subject: [DNA] [Announce] DNA in IPv6 Goals 02 I-D Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander , JinHyeock Choi , Greg Daley Cc: Dna Message-id: <006701c4a815$6c7f05e0$e75b024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <9C422444DE99BC46B3AD3C6EAFC9711B0766082B@tayexc13.americas.cpqcorp.net> <2D999597-0D3B-11D9-A57E-000D9331AFB0@nomadiclab.com> <011301c4a1d5$c3742010$e95b024b@jinchoe> <000e01c4a2f6$505d1ab0$e95b024b@jinchoe> <2E0EE4FA-1057-11D9-9F77-000D9331AFB0@nomadiclab.com> <41584347.4010200@sun.com> <17E2D104-1130-11D9-9F77-000D9331AFB0@nomadiclab.com> <92e919fb040928061478934620@mail.gmail.com> <25A7E532-12D7-11D9-A1D1-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7BIT Dear DNA Group We incorporated the feedback from WG LC to update the draft. The draft is available at http://www.ietf.org/internet-drafts/draft-ietf-dna-goals-02.txt We believe that all WG LC issues have been addressed. Accordingly we have updated the issue list at http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNAGoals to add five more issues with their resolutions. 009 DNA per interface (Alper Yegin) 010 The relation between a link and a subnet (Alper Yegin) 011 IPv6 Only (Pekka Nikander) 012 Modify Section 3 (Pekka Nikander) 013 Minor edits (Pekka Nikander) Kindly check them out to see everything is properly resolved. In case anything is wrong or missing, kindly let us know. Thanks in advance for your kind consideration. Best Regards JinHyeock Choi and Greg Daley (Authors) From dna-owner@webcamserver.eng.monash.edu.au Tue Oct 5 01:27:15 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04128 for ; Tue, 5 Oct 2004 01:27:13 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LFODUWFVYE8X48TI@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 5 Oct 2004 15:22:16 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 175CEAB546; Tue, 05 Oct 2004 15:22:05 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id A0C074FB0B; Tue, 05 Oct 2004 15:22:04 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i955L4V07958 for dna-list; Tue, 05 Oct 2004 15:21:04 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i955L3607954 for ; Tue, 05 Oct 2004 15:21:03 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LFODTD02O28ZEBMF@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Tue, 05 Oct 2004 15:20:51 +1000 Received: by localhost (Postfix, from userid 510) id A4803AB543; Tue, 05 Oct 2004 15:20:49 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by curly.its.monash.edu.au (Postfix) with ESMTP id 224134FB0B; Tue, 05 Oct 2004 15:20:47 +1000 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0I530004NIUKC6@mailout1.samsung.com>; Tue, 05 Oct 2004 14:20:45 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I5300E4IIU3I4@mailout1.samsung.com>; Tue, 05 Oct 2004 14:20:27 +0900 (KST) Received: from LocalHost ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I5300MFZIU2ZS@mmp2.samsung.com>; Tue, 05 Oct 2004 14:20:27 +0900 (KST) Date: Tue, 05 Oct 2004 14:21:49 +0900 From: Soohong Daniel Park Subject: RE: [DNA] [Announce] DNA in IPv6 Goals 02 I-D In-reply-to: <006701c4a815$6c7f05e0$e75b024b@jinchoe> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , Pekka Nikander , JinHyeock Choi , Greg Daley Cc: Dna Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT You missed my indication described below http://webcamserver.eng.monash.edu.au/~warchive/dna/2004-09/msg00033.html This work can be done by RFC-Editor of course, but if you can, clarification would be better I believe. Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics. > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au > [mailto:owner-dna@ecselists.eng.monash.edu.au]On Behalf Of JinHyeock Choi > Sent: Saturday, October 02, 2004 9:19 AM > To: Pekka Nikander; JinHyeock Choi; Greg Daley > Cc: Dna > Subject: [DNA] [Announce] DNA in IPv6 Goals 02 I-D > > > Dear DNA Group > > We incorporated the feedback from WG LC to update the draft. > The draft is available at > > http://www.ietf.org/internet-drafts/draft-ietf-dna-goals-02.txt > > We believe that all WG LC issues have been addressed. > Accordingly we have updated the issue list at > > http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNAGoals > > to add five more issues with their resolutions. > > 009 DNA per interface (Alper Yegin) > 010 The relation between a link and a subnet (Alper Yegin) > 011 IPv6 Only (Pekka Nikander) > 012 Modify Section 3 (Pekka Nikander) > 013 Minor edits (Pekka Nikander) > > Kindly check them out to see everything is properly resolved. > In case anything is wrong or missing, kindly let us know. > > Thanks in advance for your kind consideration. > > Best Regards > > JinHyeock Choi and Greg Daley > (Authors) > From dna-owner@webcamserver.eng.monash.edu.au Tue Oct 5 09:42:35 2004 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27772 for ; Tue, 5 Oct 2004 09:42:34 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LFOVBJ3K6A9EGRFM@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 05 Oct 2004 23:42:11 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DB2AA80004; Tue, 05 Oct 2004 23:41:51 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 932DC3C008; Tue, 05 Oct 2004 23:41:51 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i95DfK913968 for dna-list; Tue, 05 Oct 2004 23:41:20 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i95DfK613964 for ; Tue, 05 Oct 2004 23:41:20 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LFOVAJIOX4A0UJVF@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 05 Oct 2004 23:41:04 +1000 Received: by localhost (Postfix, from userid 510) id 3AF8EAB542; Tue, 05 Oct 2004 23:41:04 +1000 (EST) Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by curly.its.monash.edu.au (Postfix) with ESMTP id 887734FB08 for ; Tue, 05 Oct 2004 23:41:02 +1000 (EST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id AF922220009 for ; Tue, 05 Oct 2004 16:40:58 +0300 (EEST) Received: from [IPv6:::1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 1E1398 for ; Tue, 05 Oct 2004 16:40:59 +0300 (EEST) Date: Tue, 05 Oct 2004 16:41:05 +0300 From: Pekka Nikander Subject: Re: [DNA] Preparing Washington D.C. agenda In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <34AD13E0-16D4-11D9-A0F5-000D9331AFB0@nomadiclab.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: Content-Transfer-Encoding: 7BIT > I am starting to prepare agenda for the D.C. meeting. As we > have made good progress with the goals draft, it looks like > that the time is ripe for starting work on the new solution(s). > Hence, I am soliciting for revised and new drafts in the > solutions space so that we get discussion going. If needed, > we can then form a design team later on. I haven't got any requests so far. Hence, I'm inclined to request for a one hour slot. The agenda would be as follows: > 5 min Introduction & Agenda bashing > 5 min Documents status > 10 min Link information draft > 15 min Best Current Practise draft > 15 min Solutions work > 10 min Wrap up So, if you have any solutions space work that you would to take up at DC, speak up now, or otherwise we have to live with the one hour slot. --Pekka From dna-owner@webcamserver.eng.monash.edu.au Wed Oct 6 04:03:48 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29703 for ; Wed, 6 Oct 2004 04:03:46 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LFPXOP55GU8ZECL3@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 6 Oct 2004 18:00:40 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 503A0AB5B1; Wed, 06 Oct 2004 17:59:05 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id E83F64FB0F; Wed, 06 Oct 2004 17:59:04 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i967uIv26290 for dna-list; Wed, 06 Oct 2004 17:56:18 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i967uH626286 for ; Wed, 06 Oct 2004 17:56:17 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LFPXIWJG2KA3CBO4@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 06 Oct 2004 17:55:52 +1000 Received: by localhost (Postfix, from userid 510) id 36AF28004F; Wed, 06 Oct 2004 17:54:22 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by larry.its.monash.edu.au (Postfix) with ESMTP id 9A1313C00D for ; Wed, 06 Oct 2004 17:54:20 +1000 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0I5500L2NKMID8@mailout1.samsung.com> for dna@eng.monash.edu.au; Wed, 06 Oct 2004 16:54:18 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I550005JKLCVK@mailout1.samsung.com> for dna@eng.monash.edu.au; Wed, 06 Oct 2004 16:53:36 +0900 (KST) Received: from jinchoe ([168.219.231.248]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I5500DW8KLCS0@mmp1.samsung.com> for dna@eng.monash.edu.au; Wed, 06 Oct 2004 16:53:36 +0900 (KST) Date: Wed, 06 Oct 2004 16:53:38 +0900 From: JinHyeock Choi Subject: Re: [DNA] [Announce] DNA in IPv6 Goals 02 I-D Sender: owner-dna@ecselists.eng.monash.edu.au To: Soohong Daniel Park , JinHyeock Choi Cc: Dna Message-id: <01dc01c4ab79$9755c670$f8e7dba8@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: Content-Transfer-Encoding: 7BIT Dear Daniel I had incorporated your comments to remove a few items, such as an expired one, from the Reference. However, I left a few I assumed useful, though not cited in the text. I wonder whether the Reference should exclusively contain the items that are explicitly cited in the draft. If you kindly enlighten me that it really is the case, it would be of help. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Oct 6 06:23:40 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09269 for ; Wed, 6 Oct 2004 06:23:39 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LFQ2MOI7BQA3CCHX@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 06 Oct 2004 20:22:03 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4B9AEAB543; Wed, 06 Oct 2004 20:21:41 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 0488A4FB03; Wed, 06 Oct 2004 20:21:41 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i96AL6028000 for dna-list; Wed, 06 Oct 2004 20:21:06 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i96AL6627996 for ; Wed, 06 Oct 2004 20:21:06 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LFQ2LV8JT68X4PDC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Wed, 06 Oct 2004 20:21:02 +1000 Received: by localhost (Postfix, from userid 510) id 0CEA0AB54F; Wed, 06 Oct 2004 20:21:01 +1000 (EST) Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by moe.its.monash.edu.au (Postfix) with ESMTP id 6AEA54FB03 for ; Wed, 06 Oct 2004 20:21:01 +1000 (EST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 67EEB22000A for ; Wed, 06 Oct 2004 13:20:59 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id EEABD8 for ; Wed, 06 Oct 2004 13:20:59 +0300 (EEST) Date: Wed, 06 Oct 2004 13:21:07 +0300 From: Pekka Nikander Subject: Re: [DNA] Preparing Washington D.C. agenda In-reply-to: <34AD13E0-16D4-11D9-A0F5-000D9331AFB0@nomadiclab.com> Sender: owner-dna@ecselists.eng.monash.edu.au Cc: Dna Message-id: <6F52B650-1781-11D9-A0F5-000D9331AFB0@nomadiclab.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <34AD13E0-16D4-11D9-A0F5-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7BIT > So, if you have any solutions space work that you would to > take up at DC, speak up now, or otherwise we have to live > with the one hour slot. I got a number of proposals, and as a result sent a request for a 2 or 2.5 hour slot. --Pekka From dna-owner@webcamserver.eng.monash.edu.au Fri Oct 8 05:15:12 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06114 for ; Fri, 8 Oct 2004 05:15:10 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LFSSOSV8ZI8X463G@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 8 Oct 2004 19:09:30 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 997F3AB54D; Fri, 08 Oct 2004 19:09:26 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 4858F4FB07; Fri, 08 Oct 2004 19:09:26 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9898Hp22250 for dna-list; Fri, 08 Oct 2004 19:08:17 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9898G622244 for ; Fri, 08 Oct 2004 19:08:16 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LFSSN0WLLO8ZEDQ6@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 08 Oct 2004 19:08:01 +1000 Received: by localhost (Postfix, from userid 510) id BFC5680003; Fri, 08 Oct 2004 19:08:00 +1000 (EST) Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by larry.its.monash.edu.au (Postfix) with ESMTP id 2FFDF3C00C for ; Fri, 08 Oct 2004 19:08:00 +1000 (EST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 1EAF8220003; Fri, 08 Oct 2004 12:07:58 +0300 (EEST) Received: from [127.0.0.1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id C9AE18; Fri, 08 Oct 2004 12:07:58 +0300 (EEST) Date: Fri, 08 Oct 2004 12:08:07 +0300 From: Pekka Nikander Subject: Re: [DNA] [Announce] DNA in IPv6 Goals 02 I-D In-reply-to: <01dc01c4ab79$9755c670$f8e7dba8@jinchoe> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: JinHyeock Choi , Soohong Daniel Park , Dna Message-id: <91890AE8-1909-11D9-BF2A-000D9331AFB0@nomadiclab.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: <01dc01c4ab79$9755c670$f8e7dba8@jinchoe> Content-Transfer-Encoding: 7BIT > I wonder whether the Reference should exclusively contain the items > that are explicitly cited in the draft. If you kindly enlighten me that > it really is the case, it would be of help. This is an Informational draft, and AFAIK you therefore have considerable freedom in what you refer to. It is stricter with Standard Track documents. --Pekka From dna-owner@webcamserver.eng.monash.edu.au Mon Oct 11 12:39:22 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20558 for ; Mon, 11 Oct 2004 12:39:21 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LFX6DXDTAE8X4X7M@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 11 Oct 2004 22:24:47 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7F5EFAB543; Mon, 11 Oct 2004 22:24:42 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 34AD84FB0A; Mon, 11 Oct 2004 22:24:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9BCN3103974 for dna-list; Mon, 11 Oct 2004 22:23:03 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9BCN3603970 for ; Mon, 11 Oct 2004 22:23:03 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LFX6BJNOUM8ZEHET@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Mon, 11 Oct 2004 22:22:47 +1000 Received: by localhost (Postfix, from userid 510) id 668CB80002; Mon, 11 Oct 2004 22:22:47 +1000 (EST) Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by larry.its.monash.edu.au (Postfix) with ESMTP id C53AB3C019 for ; Mon, 11 Oct 2004 22:22:45 +1000 (EST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 03D11220004 for ; Mon, 11 Oct 2004 15:22:43 +0300 (EEST) Received: from [127.0.0.1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id A774D8 for ; Mon, 11 Oct 2004 15:22:43 +0300 (EEST) Date: Mon, 11 Oct 2004 15:22:42 +0300 From: Pekka Nikander Subject: [DNA] Initial agenda for DC meeting Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <401D24EC-1B80-11D9-97E8-000D9331AFB0@nomadiclab.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) Content-Transfer-Encoding: 7BIT Current agenda proposal, to be revised: 5 min Introduction & Agenda bashing 5 min Documents status draft-ietf-dna-goals-XX.txt draft-ietf-dna-link-information-XX.txt (the BCP draft if in time) 10 min Link information draft draft-ietf-dna-link-information-XX.txt 30 min Best Current Practise draft (the BCP draft if in time) 60 min Solutions work (We are working out how to structure this session.) draft-jinchoi-dna-soln-frame-00.txt draft-narayanan-dna-rrd-00.txt draft-jinchoi-dna-cpl-00.txt draft-jinchoi-dna-frd-00.txt 10 min Wrap up (I hope I haven't missed anything. If I have, please let me know.) --Pekka From dna-owner@webcamserver.eng.monash.edu.au Mon Oct 11 21:23:00 2004 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17973 for ; Mon, 11 Oct 2004 21:22:59 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LFXXGY3VAU8WWIKJ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 12 Oct 2004 11:21:31 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9C7D2AB54F; Tue, 12 Oct 2004 11:20:37 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 289434FB10; Tue, 12 Oct 2004 11:20:37 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9C1I4O12512 for dna-list; Tue, 12 Oct 2004 11:18:04 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9C1I4612508 for ; Tue, 12 Oct 2004 11:18:04 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LFXXDFKFZM8WWIKI@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 12 Oct 2004 11:17:48 +1000 Received: by localhost (Postfix, from userid 510) id 95F07AB544; Tue, 12 Oct 2004 11:17:47 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id 625C64FB08 for ; Tue, 12 Oct 2004 11:17:45 +1000 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id i9C1HhnH021510 for ; Mon, 11 Oct 2004 21:17:43 -0400 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 1BD283C80E8 for ; Mon, 11 Oct 2004 21:16:29 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id F1D583C80E6for ; Mon, 11 Oct 2004 21:16:28 -0400 (EDT) Date: Mon, 11 Oct 2004 21:17:23 -0400 From: Sathya Narayanan Subject: [DNA] Solutions draft: draft-narayanan-dna-rrd-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <416B30A3.4010602@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:9.81819 C:22 M:1 S:5 R:5 X-imss-settings: Baseline:4 C:3 M:3 S:4 R:3 (1.0000 3.0000) X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT Dear DNA group: I submitted the following draft as input for the DNA solutions work. "Recommendations to achieve efficient Router Reachability Detection in IPv6 networks" http://www.ietf.org/internet-drafts/draft-narayanan-dna-rrd-00.txt Please take a look at it and provide me with your comments/thoughts. thanks & regards, Sathya From dna-owner@webcamserver.eng.monash.edu.au Wed Oct 13 16:38:48 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04211 for ; Wed, 13 Oct 2004 16:38:46 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LG0G2FTZLW8ZE7IM@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 14 Oct 2004 06:34:17 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 15FE3AB54D; Thu, 14 Oct 2004 06:34:09 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 248C14FB07; Thu, 14 Oct 2004 06:34:03 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9DKWfm07483 for dna-list; Thu, 14 Oct 2004 06:32:41 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9DKWW607478 for ; Thu, 14 Oct 2004 06:32:32 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LG0G0AX3R28ZEI80@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 14 Oct 2004 06:32:26 +1000 Received: by localhost (Postfix, from userid 510) id E5D0D80004; Thu, 14 Oct 2004 06:32:25 +1000 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by larry.its.monash.edu.au (Postfix) with ESMTP id 6A70F3C00A for ; Thu, 14 Oct 2004 06:32:22 +1000 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03710; Wed, 13 Oct 2004 16:32:20 -0400 (EDT) Date: Wed, 13 Oct 2004 16:32:20 -0400 From: Internet-Drafts@ietf.org Subject: [DNA] I-D ACTION:draft-ietf-dna-goals-03.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: i-d-announce@ietf.org Cc: dna@eng.monash.edu.au Message-id: <200410132032.QAA03710@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_c+ArthY6fg2j8PZveWBWLw)" Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) --Boundary_(ID_c+ArthY6fg2j8PZveWBWLw) Content-type: TEXT/PLAIN Content-Transfer-Encoding: 7BIT A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Detecting Network Attachment Working Group of the IETF. Title : Detecting Network Attachment in IPv6 Goals Author(s) : J. Choi, G. Daley Filename : draft-ietf-dna-goals-03.txt Pages : 15 Date : 2004-10-13 At the time a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change, i.e. determine whether a link change has occurred, and then, based on the result, it can automatically decide whether its IP configuration is still valid or not. During link identity detection, the host may also collect necessary information to initiate a new IP configuration for the case that the IP subnet has changed. In this memo, this procedure is called Detecting Network Attachment (DNA). DNA schemes should be precise, sufficiently fast, secure and of limited signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dna-goals-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dna-goals-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dna-goals-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_c+ArthY6fg2j8PZveWBWLw) Content-type: multipart/alternative; boundary="Boundary_(ID_QCCf0630Pb6tPYO08XHKCw)" --Boundary_(ID_QCCf0630Pb6tPYO08XHKCw) Content-type: Message/External-body; server="mailserv@ietf.org"; access-type=mail-server Content-Type: text/plain Content-ID: <2004-10-13164658.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dna-goals-03.txt --Boundary_(ID_QCCf0630Pb6tPYO08XHKCw) Content-type: Message/External-body; directory=internet-drafts; access-type=anon-ftp; site=ftp.ietf.org; name=draft-ietf-dna-goals-03.txt Content-disposition: attachment; filename=draft-ietf-dna-goals-03.txt Content-Type: text/plain Content-ID: <2004-10-13164658.I-D@ietf.org> --Boundary_(ID_QCCf0630Pb6tPYO08XHKCw)-- --Boundary_(ID_c+ArthY6fg2j8PZveWBWLw)-- From dna-owner@webcamserver.eng.monash.edu.au Thu Oct 14 11:19:43 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29438 for ; Thu, 14 Oct 2004 11:19:41 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LG1J9NVR848ZED18@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 15 Oct 2004 01:17:14 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9F6FE80002; Fri, 15 Oct 2004 01:17:03 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 585F53C009; Fri, 15 Oct 2004 01:17:03 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9EFGGs20147 for dna-list; Fri, 15 Oct 2004 01:16:16 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9EFGF620143 for ; Fri, 15 Oct 2004 01:16:15 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LG1J8BF29A8WX9UD@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 15 Oct 2004 01:15:59 +1000 Received: by localhost (Postfix, from userid 510) id 93DC7AB542; Fri, 15 Oct 2004 01:15:58 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id 86F404FB10 for ; Fri, 15 Oct 2004 01:15:54 +1000 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id i9EFFqqv013218 for ; Thu, 14 Oct 2004 11:15:52 -0400 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 1BD2F3C80EB for ; Thu, 14 Oct 2004 11:14:37 -0400 (EDT) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id 062AD3C80EAfor ; Thu, 14 Oct 2004 11:14:37 -0400 (EDT) Date: Thu, 14 Oct 2004 11:15:37 -0400 From: Sathya Narayanan Subject: [DNA] DNA BCP Submission Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <416E9819.1020705@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:9.85621 C:22 M:1 S:5 R:5 X-imss-settings: Baseline:4 C:3 M:3 S:4 R:3 (1.0000 3.0000) X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT Dear DNA group: We submitted the -01 of the BCP to the IETF Secretariat. It should appear in the intenet-drafts directory soon. Meanwhile, the document can be found at: http://utopia.poly.edu/~snaray01/draft-narayanan-dna-bcp-01.txt Please let us know your comments. We need feedback from the group to make progress in this work. Since the document is kinda long, even if you could read parts of it and provide feedback on those parts alone, it will be very helpful for us to assess the quality and usefulness of the document. thanks, Sathya for Sathya Narayanan Greg Daley Nicolas Montavont (Authors) From dna-owner@webcamserver.eng.monash.edu.au Fri Oct 15 03:23:30 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01531 for ; Fri, 15 Oct 2004 03:23:29 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LG2GWVN4II8X637T@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 15 Oct 2004 17:20:46 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E31C5AB5A2; Fri, 15 Oct 2004 17:18:56 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8D4C14FB14; Fri, 15 Oct 2004 17:18:56 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9F7Gt229444 for dna-list; Fri, 15 Oct 2004 17:16:55 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9F7Gs629440 for ; Fri, 15 Oct 2004 17:16:54 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LG2GO2UTZ68ZEIVF@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 15 Oct 2004 17:13:11 +1000 Received: by localhost (Postfix, from userid 510) id 229FEAB55D; Fri, 15 Oct 2004 17:11:58 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by curly.its.monash.edu.au (Postfix) with ESMTP id 321824FBF8 for ; Fri, 15 Oct 2004 17:11:03 +1000 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I5M00KLF6MAPG@mailout3.samsung.com> for dna@eng.monash.edu.au; Fri, 15 Oct 2004 16:10:58 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I5M006416JDVP@mailout3.samsung.com> for dna@eng.monash.edu.au; Fri, 15 Oct 2004 16:09:14 +0900 (KST) Received: from jinchoe ([75.2.91.231]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I5M009HA6JDIX@mmp1.samsung.com> for dna@eng.monash.edu.au; Fri, 15 Oct 2004 16:09:13 +0900 (KST) Date: Fri, 15 Oct 2004 16:09:13 +0900 From: JinHyeock Choi Subject: Re: [DNA] Initial agenda for DC meeting Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander , Dna Message-id: <00b501c4b285$e08b8150$e75b024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <401D24EC-1B80-11D9-97E8-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7BIT Dear Pekka Thanks for preparing the agenda. Especially I like that something is not in it. :-) > Current agenda proposal, to be revised: > > 5 min Introduction & Agenda bashing > > 5 min Documents status > draft-ietf-dna-goals-XX.txt > draft-ietf-dna-link-information-XX.txt > (the BCP draft if in time) > > 10 min Link information draft > draft-ietf-dna-link-information-XX.txt > > 30 min Best Current Practise draft > (the BCP draft if in time) > > 60 min Solutions work > > (We are working out how to structure this session.) > > draft-jinchoi-dna-soln-frame-00.txt I would like WG to decide on what it will do with the draft, especially whether it will take the direction the draft suggests. After Erik's presentation at San Diego, people voted that the draft is useful for WG, but few decision is made yet. :-( > draft-narayanan-dna-rrd-00.txt > draft-jinchoi-dna-cpl-00.txt Erik and I proposed CPL as a BCP work. In my opinion, folks showed interests on CPL but it still is not clear how the draft will be included into BCP work. At D.C. meeting, I wish that WG decides on whether CPL is accepted as a WG item or not. > draft-jinchoi-dna-frd-00.txt Though FRD was originally submitted as a solution work, we wonder whether it is more of a BCP work. The draft describe a way to quickly deliver RA to a host without a standard change. I already talked this with Greg. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Oct 18 22:09:54 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18918 for ; Mon, 18 Oct 2004 22:09:53 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LG7R0I9K768ZENO4@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Oct 2004 12:03:37 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B7BC3AB548; Tue, 19 Oct 2004 12:03:29 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 56BFE4FB12; Tue, 19 Oct 2004 12:03:29 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9J22Y223554 for dna-list; Tue, 19 Oct 2004 12:02:34 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9J22Y623550 for ; Tue, 19 Oct 2004 12:02:34 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LG7QZ6MBJY8ZFCWM@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Oct 2004 12:02:26 +1000 Received: by localhost (Postfix, from userid 510) id 5F277AB544; Tue, 19 Oct 2004 12:02:24 +1000 (EST) Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.114.50]) by curly.its.monash.edu.au (Postfix) with ESMTP id 014F24FB10 for ; Tue, 19 Oct 2004 12:02:22 +1000 (EST) Received: from yghongnb (yghong1.etri.re.kr [129.254.112.199]) by pec.etri.re.kr (8.12.10/8.12.10) with ESMTP id i9J2LWlm024214; Tue, 19 Oct 2004 11:21:32 +0900 (KST) Date: Tue, 19 Oct 2004 11:02:09 +0900 From: Yong-Geun Hong Subject: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Cc: ??? , ??? , ??? Reply-to: yghong@etri.re.kr Message-id: <200410190221.i9J2LWlm024214@pec.etri.re.kr> Organization: ETRI/PEC MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Precedence: bulk Thread-Index: AcS1f6PSwPP0irCcSpen736yeR9alw== X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT Dear DNA Group.. We submitted the following draft to the IETF Secretariat. It should appear in the internet-drafts in the internet-drafts directory soon. "Considerations for DNA Schemes with Multiple Interfaces and Layer 2 Technologies" http://pec.etri.re.kr/~yghong/draft-hong-dna-if-l2-00.txt Currently, we are developing multiple interfaces node. (one is 802.11g, the other is CDMA2000 1x) While we are developing, current DNA schemes are enough for a single interface and WLAN. When we consider multiple interfaces and other link-layer technology, we think that current DNA schemes may be insufficient. In this document, we consider and analyze various environments for applying DNA schemes. Please let us know your comments/thoughts. Thanks.. Yong-Geun.. From dna-owner@webcamserver.eng.monash.edu.au Mon Oct 18 22:36:37 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21316 for ; Mon, 18 Oct 2004 22:36:36 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LG7S3DV2828ZENW2@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Oct 2004 12:34:20 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 77574AB551; Tue, 19 Oct 2004 12:34:03 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 1A82C4FB0B; Tue, 19 Oct 2004 12:34:03 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9J2Xss23926 for dna-list; Tue, 19 Oct 2004 12:33:54 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9J2Xs623922 for ; Tue, 19 Oct 2004 12:33:54 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LG7S2VI3J48ZFDE8@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Oct 2004 12:33:41 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D926E80007; Tue, 19 Oct 2004 12:33:38 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 5169A3C00B; Tue, 19 Oct 2004 12:33:38 +1000 (EST) Date: Tue, 19 Oct 2004 12:33:38 +1000 From: Greg Daley Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies In-reply-to: <200410190221.i9J2LWlm024214@pec.etri.re.kr> Sender: owner-dna@ecselists.eng.monash.edu.au To: yghong@etri.re.kr Cc: dna@eng.monash.edu.au, ??? , ??? Reply-to: greg.daley@eng.monash.edu.au Message-id: <41747D02.20408@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us References: <200410190221.i9J2LWlm024214@pec.etri.re.kr> Content-Transfer-Encoding: 7BIT Hi Youn-Geun, I have some questions. Yong-Geun Hong wrote: > > Dear DNA Group.. > > We submitted the following draft to the IETF Secretariat. > It should appear in the internet-drafts in the internet-drafts directory > soon. > > "Considerations for DNA Schemes with Multiple Interfaces > and Layer 2 Technologies" > http://pec.etri.re.kr/~yghong/draft-hong-dna-if-l2-00.txt > > Currently, we are developing multiple interfaces node. > (one is 802.11g, the other is CDMA2000 1x) > While we are developing, current DNA schemes are enough for a single > interface > and WLAN. > When we consider multiple interfaces and other link-layer technology, we > think that > current DNA schemes may be insufficient. In this document, we consider and > analyze > various environments for applying DNA schemes. > > Please let us know your comments/thoughts. in section 3.3 (page 4) there's a statement: If each link-layer technology of each interface is the same and each interface is in the same link, this scenario may not be very much different with case 3.1. Because each interface is in the same link, link information on each interface may be the same. In this scenario, multiple interfaces do not have any effect on detecting any link changes. What do you mean by technology here? MAC/PHY combination or something else? It may be that two wireless devices have the same MAC capabilities and same PHY encoding, but have different sensitivities, policy, antennae (antennas), and physical locations. In this case, a condition affecting the IP layer connectivity of one may not affect another. It may actually be why you'd want to have both interfaces. Do you have any papers or tech-reports which illustrate the situation as you described? There are a lot of statements about connection of another L2 medium, but limited correlation of these processes to DNA. I think that if there's work needed for CDMA systems, it may be necessary to be specific as to the actual issues. Is it possible to work out a succinct problem statement for these issues? Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Oct 19 02:14:34 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18024 for ; Tue, 19 Oct 2004 02:14:33 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LG7ZITM6BU8X6KMI@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 19 Oct 2004 16:07:30 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4987B80006; Tue, 19 Oct 2004 16:07:19 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id DD7C33C00F; Tue, 19 Oct 2004 16:07:18 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9J66ka26179 for dna-list; Tue, 19 Oct 2004 16:06:46 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9J66k626175 for ; Tue, 19 Oct 2004 16:06:46 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LG7ZHSKZW68WYJ8U@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 19 Oct 2004 16:06:30 +1000 Received: by localhost (Postfix, from userid 510) id 021EDAB54C; Tue, 19 Oct 2004 16:06:29 +1000 (EST) Received: from cms5.etri.re.kr (cms5.etri.re.kr [129.254.16.15]) by moe.its.monash.edu.au (Postfix) with ESMTP id 587E14FB05; Tue, 19 Oct 2004 16:06:27 +1000 (EST) Received: by cms5 with Internet Mail Service (5.5.2657.72) id ; Tue, 19 Oct 2004 15:12:05 +0900 Date: Tue, 19 Oct 2004 15:12:01 +0900 From: YGHONG Subject: RE: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au, ??? , ??? , yghong@etri.re.kr Message-id: <30388A145972BC428B56434C562AE177019CCE02@cms5> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT Hi..Greg.. My answers are in lines.. > -----Original Message----- > From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] > Sent: Tuesday, October 19, 2004 11:34 AM > To: yghong@etri.re.kr > Cc: dna@eng.monash.edu.au; ???; ??? > Subject: Re: [DNA] Considerations for DNA Schemes with > multiple Interface and Layer 2 Technologies > > > Hi Youn-Geun, > > I have some questions. > > Yong-Geun Hong wrote: > > > > Dear DNA Group.. > > > > We submitted the following draft to the IETF Secretariat. > > It should appear in the internet-drafts in the internet-drafts > > directory soon. > > > > "Considerations for DNA Schemes with Multiple Interfaces > and Layer 2 > > Technologies" > > http://pec.etri.re.kr/~yghong/draft-hong-dna-if-l2-00.txt > > > > Currently, we are developing multiple interfaces node. > > (one is 802.11g, the other is CDMA2000 1x) While we are developing, > > current DNA schemes are enough for a single interface and WLAN. > > When we consider multiple interfaces and other link-layer > technology, > > we think that current DNA schemes may be insufficient. In this > > document, we consider and analyze various environments for applying > > DNA schemes. > > > > Please let us know your comments/thoughts. > > in section 3.3 (page 4) there's a statement: > > > If each link-layer technology of each interface is the same and > each interface is in the same link, this scenario may > not be very > much different with case 3.1. Because each interface is > in the same > link, link information on each interface may be the > same. In this > scenario, multiple interfaces do not have any effect on > detecting > any link changes. > > What do you mean by technology here? MAC/PHY combination or > something else? > => MAC/PHY combination > It may be that two wireless devices have the same MAC > capabilities and same PHY encoding, but have different > sensitivities, policy, antennae (antennas), and physical locations. > > In this case, a condition affecting the IP layer connectivity > of one may not affect another. It may actually be why you'd > want to have both interfaces. > => You are right. In this case, a condition affecting the IP layer connectivity of one may not affect another. But the important thing is that each interface is in the same link. Although, two wireless devices have different sensitivities, policy, et al, access point(s) which two wireless devices are connected to can be in the same link. => I think that this case may not be common but we can guess this situations. > Do you have any papers or tech-reports which illustrate the > situation as you described? > => No..As we are designing multiple interface node, we have consider this case. > > There are a lot of statements about connection of another L2 > medium, but limited correlation of these processes to DNA. > I think that if there's work needed for CDMA systems, it may > be necessary to be specific as to the actual issues. > > Is it possible to work out a succinct problem statement for > these issues? > => What I want to say in this section is that in this case if each interface is in the same link, the effect of multiple interfaces for DNA schemes may be none. > Greg > From dna-owner@webcamserver.eng.monash.edu.au Wed Oct 20 23:36:33 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20175 for ; Wed, 20 Oct 2004 23:36:32 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGAMQ8W3LQ8ZEDND@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 21 Oct 2004 13:33:17 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AED3C80004; Thu, 21 Oct 2004 13:33:03 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 59BD53C00C; Thu, 21 Oct 2004 13:33:03 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9L3SdA24042 for dna-list; Thu, 21 Oct 2004 13:28:39 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9L3Sc624038 for ; Thu, 21 Oct 2004 13:28:38 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGAMKPVDNY8WYRLJ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Oct 2004 13:28:37 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A4311AB543; Thu, 21 Oct 2004 13:28:36 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 87ECB4FB0A; Thu, 21 Oct 2004 13:28:36 +1000 (EST) Date: Thu, 21 Oct 2004 13:28:36 +1000 From: Greg Daley Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies In-reply-to: <30388A145972BC428B56434C562AE177019CCE02@cms5> Sender: owner-dna@ecselists.eng.monash.edu.au To: YGHONG Cc: dna@eng.monash.edu.au, ??? , ??? Reply-to: greg.daley@eng.monash.edu.au Message-id: <41772CE4.1030103@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us References: <30388A145972BC428B56434C562AE177019CCE02@cms5> Content-Transfer-Encoding: 7BIT Hi Youn-Geun, YGHONG wrote: > Hi..Greg.. > > My answers are in lines.. > > >>-----Original Message----- >>From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] >>Sent: Tuesday, October 19, 2004 11:34 AM >>To: yghong@etri.re.kr >>Cc: dna@eng.monash.edu.au; ???; ??? >>Subject: Re: [DNA] Considerations for DNA Schemes with >>multiple Interface and Layer 2 Technologies >> >> >>Hi Youn-Geun, >> >>I have some questions. >> >>Yong-Geun Hong wrote: >> >>>Dear DNA Group.. >>> >>>We submitted the following draft to the IETF Secretariat. >>>It should appear in the internet-drafts in the internet-drafts >>>directory soon. >>> >>>"Considerations for DNA Schemes with Multiple Interfaces >> >>and Layer 2 >> >>>Technologies" >>>http://pec.etri.re.kr/~yghong/draft-hong-dna-if-l2-00.txt >>> >>>Currently, we are developing multiple interfaces node. >>>(one is 802.11g, the other is CDMA2000 1x) While we are developing, >>>current DNA schemes are enough for a single interface and WLAN. >>>When we consider multiple interfaces and other link-layer >> >>technology, >> >>>we think that current DNA schemes may be insufficient. In this >>>document, we consider and analyze various environments for applying >>>DNA schemes. >>> >>>Please let us know your comments/thoughts. >> >>in section 3.3 (page 4) there's a statement: >> >> >> If each link-layer technology of each interface is the same and >> each interface is in the same link, this scenario may >>not be very >> much different with case 3.1. Because each interface is >>in the same >> link, link information on each interface may be the >>same. In this >> scenario, multiple interfaces do not have any effect on >>detecting >> any link changes. >> >>What do you mean by technology here? MAC/PHY combination or >>something else? >> > > => MAC/PHY combination > > >>It may be that two wireless devices have the same MAC >>capabilities and same PHY encoding, but have different >>sensitivities, policy, antennae (antennas), and physical locations. >> >>In this case, a condition affecting the IP layer connectivity >>of one may not affect another. It may actually be why you'd >>want to have both interfaces. >> > > => You are right. In this case, a condition affecting the IP layer > connectivity > of one may not affect another. But the important thing is that each > interface > is in the same link. Although, two wireless devices have different > sensitivities, > policy, et al, access point(s) which two wireless devices are connected > to can > be in the same link. > => I think that this case may not be common but we can guess this > situations. > > >>Do you have any papers or tech-reports which illustrate the >>situation as you described? >> > > => No..As we are designing multiple interface node, we have consider this > case. > >>There are a lot of statements about connection of another L2 >>medium, but limited correlation of these processes to DNA. >>I think that if there's work needed for CDMA systems, it may >>be necessary to be specific as to the actual issues. >> >>Is it possible to work out a succinct problem statement for >>these issues? >> > > => What I want to say in this section is that in this case if each > interface is in the same link, > the effect of multiple interfaces for DNA schemes may be none. It would be good to have some corroboration of this. Anecdotally things may seem right, but perhaps there is an underlying issue here which we need to expose. Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Oct 22 12:57:12 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20314 for ; Fri, 22 Oct 2004 12:57:11 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGCT328LG68WZBOQ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 23 Oct 2004 02:57:01 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0945FAB543; Sat, 23 Oct 2004 02:56:47 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id AFAE54FB02; Sat, 23 Oct 2004 02:56:46 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9MGtZQ17664 for dna-list; Sat, 23 Oct 2004 02:55:35 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9MGtY617660 for ; Sat, 23 Oct 2004 02:55:34 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGCT17A8VG8WZBOQ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 23 Oct 2004 02:55:17 +1000 Received: by localhost (Postfix, from userid 510) id 2864280002; Sat, 23 Oct 2004 02:55:17 +1000 (EST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by larry.its.monash.edu.au (Postfix) with ESMTP id 26B553C002 for ; Sat, 23 Oct 2004 02:55:15 +1000 (EST) Received: by rproxy.gmail.com with SMTP id 73so314496rnl for ; Fri, 22 Oct 2004 09:55:14 -0700 (PDT) Received: by 10.38.22.51 with SMTP id 51mr3753784rnv; Fri, 22 Oct 2004 09:55:14 -0700 (PDT) Received: by 10.38.125.23 with HTTP; Fri, 22 Oct 2004 09:55:14 -0700 (PDT) Date: Sat, 23 Oct 2004 01:55:14 +0900 From: JinHyeock Choi Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies In-reply-to: <41772CE4.1030103@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: YGHONG , dna@eng.monash.edu.au, ??? , ??? Reply-to: JinHyeock Choi Message-id: <92e919fb0410220955183694fc@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ttFcajqIV9kCEKDe67HCmiuUuULJE7kEL+iyeuzexy0Ikp11FTb3O/oCLNb3NKQlutYYGthPR/ZM49T9zHNnAqrParglpypAyV7AVxmy0lmsZ+rMXlqLZfWHguwnVB3DGUER80ZRZ2ZvsZKyI3/B14oAC68YwH3DLji5gL3dTuY= X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: <30388A145972BC428B56434C562AE177019CCE02@cms5> <41772CE4.1030103@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Yong-Geun I think that the case 3.2, 'Single interface with Make before Break' will affect DNA solution design. I agree that we are not familiar with this case, so it would be of much help, if you elaborate the below with more detail. We think that we are not familiar with this case. But in CDMA[7], a mobile station can access two or more different base stations simultaneously. In this case, a host can make a new link-layer connection before an old link-layer connection is torn down. Especially I wonder whether it's possible for a host to distinguish the IP packets from the old link-layer connection FROM the ones from the new link-layer connection. However, it's not clear to me the relationship between 'DNA schemes' and 'multiple interfaces' from Case 3.3 & 3.4 description. I still can't see how multiple interfaces would affect DNA schemes substantially. Kindly elaborate this more. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Oct 22 13:52:46 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24512 for ; Fri, 22 Oct 2004 13:52:44 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGCUYH3MC28X6Z57@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 23 Oct 2004 03:50:34 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0676FAB555; Sat, 23 Oct 2004 03:50:21 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id A8FE14FB02; Sat, 23 Oct 2004 03:50:20 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9MHoBq18252 for dna-list; Sat, 23 Oct 2004 03:50:11 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9MHoA618248 for ; Sat, 23 Oct 2004 03:50:10 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGCUXZ21PC8X77T4@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Sat, 23 Oct 2004 03:49:58 +1000 Received: by localhost (Postfix, from userid 510) id E5612AB542; Sat, 23 Oct 2004 03:49:56 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id C184D4FB05; Sat, 23 Oct 2004 03:49:52 +1000 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id i9MHnoUe018033; Fri, 22 Oct 2004 13:49:50 -0400 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id DA2633C80F0; Fri, 22 Oct 2004 13:48:32 -0400 (EDT) Received: from Brijesh2K (dhcp251.Research.Panasonic.COM [150.169.1.251]) by redwood.research.panasonic.com (Postfix) with SMTP id CF8D93C80E4; Fri, 22 Oct 2004 13:48:32 -0400 (EDT) Date: Fri, 22 Oct 2004 13:53:24 -0400 From: Brijesh Kumar Subject: RE: [DNA] Considerations for DNA Schemes with multiple InterfaceandLayer 2 Technologies In-reply-to: <92e919fb0410220955183694fc@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , greg.daley@eng.monash.edu.au Cc: YGHONG , dna@eng.monash.edu.au, ??? , ??? Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Precedence: bulk X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:21 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT Yong-Geun; Like JinHyeock and Greg, I am too curious why CDMA soft handoff should impact the DNA scheme specially since CDMA provides make before break ability. Since with CDMA, it is possible to combine the data received from two or more different sites to ease the transition from one to the other, I am unable to see why this will have any DNA issues at all. Can you please elaborate a little bit more clearly. Cheers, --bk > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au > [mailto:owner-dna@ecselists.eng.monash.edu.au]On Behalf Of JinHyeock > Dear Yong-Geun > > I think that the case 3.2, 'Single interface with Make before Break' > will affect DNA solution design. I agree that we are not familiar with > this case, so it would be of much help, if you elaborate the below > with more detail. > > We think that we are not familiar with this case. But in CDMA[7], a > mobile station can access two or more different base stations > simultaneously. In this case, a host can make a new link-layer > connection before an old link-layer connection is torn down. > > Especially I wonder whether it's possible for a host to distinguish > the IP packets from the old link-layer connection FROM the ones > from the new link-layer connection. > > However, it's not clear to me the relationship between 'DNA schemes' > and 'multiple interfaces' from Case 3.3 & 3.4 description. I still > can't see how multiple interfaces would affect DNA schemes > substantially. Kindly elaborate this more. > > Thanks for your kind consideration. > > Best Regards > > JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Oct 22 17:07:33 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17295 for ; Fri, 22 Oct 2004 17:07:32 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGD1PV2FQ88X71HU@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 23 Oct 2004 07:04:18 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CE478AB557; Sat, 23 Oct 2004 07:04:13 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 66AD14FB05; Sat, 23 Oct 2004 07:04:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9ML3cp20623 for dna-list; Sat, 23 Oct 2004 07:03:38 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9ML3Y620619 for ; Sat, 23 Oct 2004 07:03:34 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGD1OXCRXA8WZ8G8@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 23 Oct 2004 07:03:28 +1000 Received: by localhost (Postfix, from userid 510) id 8C915AB554; Sat, 23 Oct 2004 07:03:28 +1000 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by moe.its.monash.edu.au (Postfix) with ESMTP id 71B6A4FB10; Sat, 23 Oct 2004 07:03:26 +1000 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i9ML3Ns3022098; Fri, 22 Oct 2004 14:03:24 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9ML3KJQ004770; Fri, 22 Oct 2004 23:03:21 +0200 (MEST) Date: Fri, 22 Oct 2004 14:04:03 -0700 From: Erik Nordmark Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies In-reply-to: <92e919fb0410220955183694fc@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, YGHONG , dna@eng.monash.edu.au, ??? , ??? Message-id: <417975C3.9000800@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <30388A145972BC428B56434C562AE177019CCE02@cms5> <41772CE4.1030103@eng.monash.edu.au> <92e919fb0410220955183694fc@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: > Dear Yong-Geun > > I think that the case 3.2, 'Single interface with Make before Break' > will affect DNA solution design. I agree that we are not familiar with > this case, so it would be of much help, if you elaborate the below > with more detail. > > We think that we are not familiar with this case. But in CDMA[7], a > mobile station can access two or more different base stations > simultaneously. In this case, a host can make a new link-layer > connection before an old link-layer connection is torn down. > > Especially I wonder whether it's possible for a host to distinguish > the IP packets from the old link-layer connection FROM the ones > from the new link-layer connection. I hope that L2 can actually tell the packets apart. If this is possible, then the implementation could present the packets from the different links are arriving on different interfaces to IP. If this isn't possible, then I fear that the question "am I attached to the same link as before" can no longer be answered with "yes" or "no"; there will be cases when the interface is attached to the same link but also attached to a new link. I don't understand the CDMA constraints, but for instance with 802.11, if somebody builds a radio which can talk to two APs at the same time, it wouldn't be hard to have the software present those to IP as "wlan0" and "wlan1". If this is done, then DNA would work just fine. Erik From dna-owner@webcamserver.eng.monash.edu.au Mon Oct 25 03:03:46 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24996 for ; Mon, 25 Oct 2004 03:03:45 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGGF4LMO1W8X09GW@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 25 Oct 2004 17:00:40 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A745CAB558; Mon, 25 Oct 2004 17:00:19 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 539DB4FB02; Mon, 25 Oct 2004 17:00:19 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9P6x8n28630 for dna-list; Mon, 25 Oct 2004 16:59:08 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9P6x8628626 for ; Mon, 25 Oct 2004 16:59:08 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGGF2ZNOCO8X7GJJ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Mon, 25 Oct 2004 16:59:02 +1000 Received: by localhost (Postfix, from userid 510) id E2139AB542; Mon, 25 Oct 2004 16:59:01 +1000 (EST) Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by curly.its.monash.edu.au (Postfix) with ESMTP id E3C1C4FB04; Mon, 25 Oct 2004 16:59:00 +1000 (EST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 4CE66220004; Mon, 25 Oct 2004 09:58:58 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id DB2758; Mon, 25 Oct 2004 09:58:56 +0300 (EEST) Date: Mon, 25 Oct 2004 08:59:00 +0200 From: Pekka Nikander Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies In-reply-to: <417975C3.9000800@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Cc: Erik Nordmark , YGHONG , ??? , Greg Daley , JinHyeock Choi , ??? Message-id: <591D4576-2653-11D9-AFFD-000D9331AFB0@nomadiclab.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <30388A145972BC428B56434C562AE177019CCE02@cms5> <41772CE4.1030103@eng.monash.edu.au> <92e919fb0410220955183694fc@mail.gmail.com> <417975C3.9000800@sun.com> Content-Transfer-Encoding: 7BIT >> I think that the case 3.2, 'Single interface with Make before Break' >> will affect DNA solution design. I agree that we are not familiar with >> this case, so it would be of much help, if you elaborate the below >> with more detail. >> >> ... But in CDMA[7], a >> mobile station can access two or more different base stations >> simultaneously. In this case, a host can make a new link-layer >> connection before an old link-layer connection is torn down. > > I hope that L2 can actually tell the packets apart. > If this is possible, then the implementation could present the packets > from the different links are arriving on different interfaces to IP. I agree with Erik and others that the apparently cleanest way is to model the situation with distinct (virtual) interfaces, each corresponding to a wireless connection. However, I am also wondering how often we need that in practise. As far as I've understood (which may be completely wrong), in the typical case the CDMA network models the whole base station network as a single link, with a single excess router. OTOH, I have no idea whether soft handovers between operators is defined or not. If they are, then we probably need some care there. Taking a slightly wider angle, we can imagine various anomalies like someone inadvertedly connecting two (wireline) LAN segments together. That would (temporarily) create a similar situation. Hence, I'm afraid that we need to make the DNA scheme(s) robust against these kinds of situations. However, my current opinion (subject to change) is that we should not worry too much about these kinds of situations, and it would be perfectly OK if it takes some more time to system to recover in such a situation. In other words, if some hosts unnecessarily run DNA and autoconfiguration, that wouldn't be too bad. Network operators have to live with the limits of technology anyway. If our DNA effort results in a piece of technology that has a number of well documented limitations, that is OK, as long as the WG agrees on the limitations. --Pekka From dna-owner@webcamserver.eng.monash.edu.au Mon Oct 25 11:56:33 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07658 for ; Mon, 25 Oct 2004 11:56:32 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGGXTKGZF88ZGT2X@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Oct 2004 01:56:09 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0639DAB545; Tue, 26 Oct 2004 01:55:51 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8EEAC4FB03; Tue, 26 Oct 2004 01:55:50 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9PFtKs01797 for dna-list; Tue, 26 Oct 2004 01:55:20 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9PFtJ601793 for ; Tue, 26 Oct 2004 01:55:19 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGGXSTVYHC8ZGT20@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Oct 2004 01:55:15 +1000 Received: by localhost (Postfix, from userid 510) id 99E5FAB555; Tue, 26 Oct 2004 01:55:15 +1000 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by moe.its.monash.edu.au (Postfix) with ESMTP id 5A4DA4FB08; Tue, 26 Oct 2004 01:55:13 +1000 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9PFtANH014568; Mon, 25 Oct 2004 09:55:11 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9PFt6JQ010947; Mon, 25 Oct 2004 17:55:07 +0200 (MEST) Date: Mon, 25 Oct 2004 08:55:50 -0700 From: Erik Nordmark Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies In-reply-to: <591D4576-2653-11D9-AFFD-000D9331AFB0@nomadiclab.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander Cc: Dna , YGHONG , ??? , Greg Daley , JinHyeock Choi , ??? Message-id: <417D2206.9060104@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <30388A145972BC428B56434C562AE177019CCE02@cms5> <41772CE4.1030103@eng.monash.edu.au> <92e919fb0410220955183694fc@mail.gmail.com> <417975C3.9000800@sun.com> <591D4576-2653-11D9-AFFD-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7BIT Pekka Nikander wrote: > Taking a slightly wider angle, we can imagine various anomalies > like someone inadvertedly connecting two (wireline) LAN segments > together. That would (temporarily) create a similar situation. > Hence, I'm afraid that we need to make the DNA scheme(s) robust > against these kinds of situations. However, my current opinion > (subject to change) is that we should not worry too much about > these kinds of situations, and it would be perfectly OK if it takes > some more time to system to recover in such a situation. In other > words, if some hosts unnecessarily run DNA and autoconfiguration, > that wouldn't be too bad. Good point. It would be good if we can say that DNA doesn't make such a situation any worse than it is without DNA, and that the same mechanisms which can be used to recover still work when DNA is used. An example of what would go wrong today is that the hosts would get the routers and the prefixes for the other link, where the prefixes would be used to both autoconfigure addresses and for on-link determination. Once the accidental connection is broken, with rfc 2461 it will take 30 minutes for the routers to time out from the default router list and 30 days for the prefixes to time out. Thus in the meantime the hosts will - try to use unreachable routers until NUD tells it the router isn't responding - assume hosts are on-link which are not and fail to communicate with those hosts - use autoconfigured addresses with the bogus prefixes, for which the return traffic will not reach them The administrator might have tools that can help restore this more quickly - just sending "spoofed" RAs with zero lifetimes for the bogus default routers and the bogus prefixes will quickly repair things except that the autoconfigured addresses will remain deprecated for 2 hours (due to the 2 hour rule in RFC 2462). So at a minimum I don't think we should make this any worse and any harder to restore than it is today. Erik From dna-owner@webcamserver.eng.monash.edu.au Mon Oct 25 23:11:26 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04377 for ; Mon, 25 Oct 2004 23:11:23 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGHLAR0K2C8ZETSE@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Oct 2004 13:07:57 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 96FE3AB55A; Tue, 26 Oct 2004 13:07:52 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 2C3C94FB14; Tue, 26 Oct 2004 13:07:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9Q35CS08953 for dna-list; Tue, 26 Oct 2004 13:05:12 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9Q35B608949 for ; Tue, 26 Oct 2004 13:05:11 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGHL7DB0FE8X0CNZ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Oct 2004 13:05:09 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 197A380006; Tue, 26 Oct 2004 13:05:09 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id EACB63C008; Tue, 26 Oct 2004 13:05:08 +1000 (EST) Date: Tue, 26 Oct 2004 13:05:08 +1000 From: Brett Pentland Subject: [DNA] Update to LinkID draft. Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Cc: Greg Daley , jinHyeock Choi Message-id: <417DBEE4.7060302@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en Content-Transfer-Encoding: 7BIT Hi Folks, A new version of our LinkID draft has been posted to address feedback we have received. Until it appears on the IETF web site, it can be downloaded from: http://www.ctie.monash.edu.au/ipv6/draft-pentland-mobileip-linkid-03.txt Changes can be seen easily at: http://www.ctie.monash.edu.au/dna/draft-pentland-mobileip-linkid-03-from-2.diff.html Basically the changes are to allow for storing the linkid in non-volatile storage for continuity across reboots and to deal with the situation where two links are joined. The latter is done by having routers listen for RAs with different LinkIDs but if Deterministic FastRA is being used, there will be periodic Router-to-Router messages being transmitted and it might make more sense to listen to them instead. Any comments appreciated. Brett (on behalf of Greg and JinHyeock) From dna-owner@webcamserver.eng.monash.edu.au Tue Oct 26 02:31:41 2004 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02580 for ; Tue, 26 Oct 2004 02:31:40 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGHSC4E0ME8X0E6K@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 26 Oct 2004 16:29:16 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 31ABCAB545; Tue, 26 Oct 2004 16:29:01 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id C43E54FB0F; Tue, 26 Oct 2004 16:29:00 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9Q6SY811462 for dna-list; Tue, 26 Oct 2004 16:28:34 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9Q6SX611458 for ; Tue, 26 Oct 2004 16:28:33 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGHSBFVNJE8ZGQFK@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 26 Oct 2004 16:28:29 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8DD21AB554; Tue, 26 Oct 2004 16:28:28 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 4FEB74FB07; Tue, 26 Oct 2004 16:28:28 +1000 (EST) Date: Tue, 26 Oct 2004 16:28:28 +1000 From: Greg Daley Subject: [DNA] Draft submitted: draft-daley-dna-det-fastra-01.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Cc: Pekka Nikander Reply-to: greg.daley@eng.monash.edu.au Message-id: <417DEE8C.8080604@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us Precedence: bulk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Hi, A new version of Deterministic FastRA has been submitted (01). This will shortly make its way to the repository. In the mean time, the draft is available at: http://www.ctie.monash.edu.au/ipv6/draft-daley-dna-det-fastra-01.txt Differences to the previous draft are available at: http://www.ctie.monash.edu.au/dna/draft-daley-dna-det-fastra-01-from-0.diff.html At this stage, most of the changes were resultant from the implementation of Deterministic FastRA for RADVD. Other issues are still unresolved, need further comment or text. An issue list with existing open issues (and resolved ones) is available at: http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DetFastRA A summary of the open issues is provided below: Issue: Status: Draft: Text: Title: 009 Adopted 00 No Incompatible Fast Routers 008 Adopted 00 No Router Authorization check procedure 007 Adopted 00 No SEND requirements 006 Adopted 00 Yes JA: Editorial Issues 005 Open 00 No Split off Router-to-Router 003 Adopted 00 Yes Ranking Calculations too complicated New issues and feedback are welcome. Greg Daley From dna-owner@webcamserver.eng.monash.edu.au Wed Oct 27 11:55:33 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17784 for ; Wed, 27 Oct 2004 11:55:32 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGJQE8U12K8ZH99Y@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Oct 2004 01:55:11 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3342AAB554; Thu, 28 Oct 2004 01:55:03 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id D163E4FB03; Thu, 28 Oct 2004 01:55:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9RFrit31911 for dna-list; Thu, 28 Oct 2004 01:53:44 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9RFrh631907 for ; Thu, 28 Oct 2004 01:53:43 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGJQC8SRRA8ZETWK@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 28 Oct 2004 01:53:26 +1000 Received: by localhost (Postfix, from userid 510) id 920B8AB554; Thu, 28 Oct 2004 01:53:26 +1000 (EST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by moe.its.monash.edu.au (Postfix) with ESMTP id 73DAB4FB05; Thu, 28 Oct 2004 01:53:23 +1000 (EST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Oct 2004 17:52:51 +0200 Date: Wed, 27 Oct 2004 17:52:50 +0200 From: NJEDJOU Eric RD-RESA-REN Subject: RE: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander , Dna Cc: Erik Nordmark , YGHONG , ??? , Greg Daley , JinHyeock Choi , ??? Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MIME-Autoconverted: from quoted-printable to 8bit by webcamserver.eng.monash.edu.au id i9RFrh631908 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Precedence: bulk Thread-Topic: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies Thread-Index: AcS6YNJJsCfhLUkPQyO2ojow2sGskgB2r5Kw Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) X-OriginalArrivalTime: 27 Oct 2004 15:52:51.0583 (UTC) FILETIME=[03CA40F0:01C4BC3D] Content-Transfer-Encoding: 8BIT Actually the DNA scheme would better not be the same depending on wether i am able to attach to more than one link or not. Effectively, if i am attached for instance to two links at the same time, i may not need to go into the DNA process whenever i receive a hint that one of those links (L2 or L3) is no more valid, if i am able to switch my flows onto the other link without noticeable service interruption (after checking that my IP configuration on that other link is valid). This is why i do not really like the sentence "DNA schemes are typically run per interface. When a host has multiple interfaces, the host separately checks for link changes on each interface." As said in the introduction of the dna goals document. I think DNA would better run on an overall basis i.e seeing all of the links (which my Ip layer is capable of for that matter). Eric Njedjou -----Message d'origine----- De : owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.eng.monash.edu.au] De la part de Pekka Nikander Envoyé : lundi 25 octobre 2004 08:59 À : Dna Cc : Erik Nordmark; YGHONG; ???; Greg Daley; JinHyeock Choi; ??? Objet : Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies >> I think that the case 3.2, 'Single interface with Make before Break' >> will affect DNA solution design. I agree that we are not familiar >> with this case, so it would be of much help, if you elaborate the >> below with more detail. >> >> ... But in CDMA[7], a >> mobile station can access two or more different base stations >> simultaneously. In this case, a host can make a new link-layer >> connection before an old link-layer connection is torn down. > > I hope that L2 can actually tell the packets apart. > If this is possible, then the implementation could present the packets > from the different links are arriving on different interfaces to IP. I agree with Erik and others that the apparently cleanest way is to model the situation with distinct (virtual) interfaces, each corresponding to a wireless connection. However, I am also wondering how often we need that in practise. As far as I've understood (which may be completely wrong), in the typical case the CDMA network models the whole base station network as a single link, with a single excess router. OTOH, I have no idea whether soft handovers between operators is defined or not. If they are, then we probably need some care there. Taking a slightly wider angle, we can imagine various anomalies like someone inadvertedly connecting two (wireline) LAN segments together. That would (temporarily) create a similar situation. Hence, I'm afraid that we need to make the DNA scheme(s) robust against these kinds of situations. However, my current opinion (subject to change) is that we should not worry too much about these kinds of situations, and it would be perfectly OK if it takes some more time to system to recover in such a situation. In other words, if some hosts unnecessarily run DNA and autoconfiguration, that wouldn't be too bad. Network operators have to live with the limits of technology anyway. If our DNA effort results in a piece of technology that has a number of well documented limitations, that is OK, as long as the WG agrees on the limitations. --Pekka From dna-owner@webcamserver.eng.monash.edu.au Wed Oct 27 12:04:05 2004 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18632 for ; Wed, 27 Oct 2004 12:04:04 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGJQOVL3IQ8X0YQB@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Oct 2004 02:03:59 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5C53B80006; Thu, 28 Oct 2004 02:03:37 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id F3D483C008; Thu, 28 Oct 2004 02:03:36 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9RG3V432061 for dna-list; Thu, 28 Oct 2004 02:03:31 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9RG3U632057 for ; Thu, 28 Oct 2004 02:03:30 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGJQOL8DM48ZEV3C@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 28 Oct 2004 02:03:24 +1000 Received: by localhost (Postfix, from userid 510) id C0210AB542; Thu, 28 Oct 2004 02:03:23 +1000 (EST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by curly.its.monash.edu.au (Postfix) with ESMTP id B65964FB0B; Thu, 28 Oct 2004 02:03:20 +1000 (EST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Oct 2004 18:02:29 +0200 Date: Wed, 27 Oct 2004 18:02:28 +0200 From: NJEDJOU Eric RD-RESA-REN Subject: RE: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander , Dna Cc: Erik Nordmark , YGHONG , ??? , Greg Daley , JinHyeock Choi , ??? Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MIME-Autoconverted: from quoted-printable to 8bit by webcamserver.eng.monash.edu.au id i9RG3U632058 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Precedence: bulk Thread-Topic: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies Thread-Index: AcS6YNJJsCfhLUkPQyO2ojow2sGskgB3G0WQ Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) X-OriginalArrivalTime: 27 Oct 2004 16:02:29.0094 (UTC) FILETIME=[5C037060:01C4BC3E] Content-Transfer-Encoding: 8BIT In the same respect, the sentence "Today, a link change necessitates an IP configuration change." in the dna goals document introduction let the reader believe that a node would not be having interfaces attached to other links. Because if it is so, then the a configuration that might have been built on the non used link could start being used without requiring new IP configuration. Is it possible to recall the definition of the word link in that dna goal document? Copy-paste from RFC 2461.... Eric regards -----Message d'origine----- De : owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.eng.monash.edu.au] De la part de Pekka Nikander Envoyé : lundi 25 octobre 2004 08:59 À : Dna Cc : Erik Nordmark; YGHONG; ???; Greg Daley; JinHyeock Choi; ??? Objet : Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies >> I think that the case 3.2, 'Single interface with Make before Break' >> will affect DNA solution design. I agree that we are not familiar >> with this case, so it would be of much help, if you elaborate the >> below with more detail. >> >> ... But in CDMA[7], a >> mobile station can access two or more different base stations >> simultaneously. In this case, a host can make a new link-layer >> connection before an old link-layer connection is torn down. > > I hope that L2 can actually tell the packets apart. > If this is possible, then the implementation could present the packets > from the different links are arriving on different interfaces to IP. I agree with Erik and others that the apparently cleanest way is to model the situation with distinct (virtual) interfaces, each corresponding to a wireless connection. However, I am also wondering how often we need that in practise. As far as I've understood (which may be completely wrong), in the typical case the CDMA network models the whole base station network as a single link, with a single excess router. OTOH, I have no idea whether soft handovers between operators is defined or not. If they are, then we probably need some care there. Taking a slightly wider angle, we can imagine various anomalies like someone inadvertedly connecting two (wireline) LAN segments together. That would (temporarily) create a similar situation. Hence, I'm afraid that we need to make the DNA scheme(s) robust against these kinds of situations. However, my current opinion (subject to change) is that we should not worry too much about these kinds of situations, and it would be perfectly OK if it takes some more time to system to recover in such a situation. In other words, if some hosts unnecessarily run DNA and autoconfiguration, that wouldn't be too bad. Network operators have to live with the limits of technology anyway. If our DNA effort results in a piece of technology that has a number of well documented limitations, that is OK, as long as the WG agrees on the limitations. --Pekka From dna-owner@webcamserver.eng.monash.edu.au Wed Oct 27 15:43:14 2004 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06858 for ; Wed, 27 Oct 2004 15:43:12 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGJYCMCRUQ8ZHAC3@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Oct 2004 05:43:01 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 55DE880004; Thu, 28 Oct 2004 05:42:48 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 337FC3C00A; Thu, 28 Oct 2004 05:42:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9RJfrx02093 for dna-list; Thu, 28 Oct 2004 05:41:53 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9RJfh602089 for ; Thu, 28 Oct 2004 05:41:43 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGJYB3RQQ48X0ZRG@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 28 Oct 2004 05:41:35 +1000 Received: by localhost (Postfix, from userid 510) id 5BBA7AB542; Thu, 28 Oct 2004 05:41:35 +1000 (EST) Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by curly.its.monash.edu.au (Postfix) with ESMTP id 4E6F54FB09; Thu, 28 Oct 2004 05:41:33 +1000 (EST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 40C1A220003; Wed, 27 Oct 2004 22:41:29 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 346CE8; Wed, 27 Oct 2004 22:41:30 +0300 (EEST) Date: Wed, 27 Oct 2004 22:41:28 +0300 From: Pekka Nikander Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: NJEDJOU Eric RD-RESA-REN Cc: JinHyeock Choi , Dna , Greg Daley Message-id: <321CF27D-2850-11D9-AFFD-000D9331AFB0@nomadiclab.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: Content-Transfer-Encoding: 7BIT Eric, The DNA goals document has been passed to the IESG. We already had the WG LC, resolved the comments, and as the comments were mostly editorial in nature, passed the document to the IESG. Do you feel that we should pull the document back? (I am not saying that I am willing to do that, I just want to understand how strongly you feel about your comments.) > Actually the DNA scheme would better not be the same depending on > wether i am able to attach to more than one link or not. Effectively, > if i am attached for instance to two links at the same time, i may not > need to go into the DNA process whenever i receive a hint that one of > those links (L2 or L3) is no more valid, if i am able to switch my > flows onto the other link without noticeable service interruption > (after checking that my IP configuration on that other link is valid). > > This is why i do not really like the sentence > "DNA schemes are typically run per interface. When a host has > multiple interfaces, the host separately checks for link changes on > each interface." > As said in the introduction of the dna goals document. I think DNA > would better run on an overall basis i.e seeing all of the links > (which my Ip layer is capable of for that matter). We discussed this already, see e.g. http://webcamserver.eng.monash.edu.au/~warchive/dna/2004-09/ msg00019.html and the messages before and after that. I don't quite understand how your comment is different from what Erik and I discussed? I originally more or less felt like you, but after some consideration came to the conclusion that the complications that would result are not worth the effort. However, for the related reasons we added the word "typically" to the above sentence, among other things. On Oct 27, 2004, at 19:02, NJEDJOU Eric RD-RESA-REN wrote: > In the same respect, > the sentence "Today, a link change necessitates an IP configuration > change." in the dna goals document introduction let the reader believe > that a node would not be having interfaces attached to other links. > Because if it is so, then the a configuration that might have been > built on the non used link could start being used without requiring > new IP configuration. I don't understand this comment. The document says pretty clearly that you _typically_ do DNA per interface. Hence, if you link changes, you _typically_ run DNA on the interface attached to that link, and not on others. What am I missing? > Is it possible to recall the definition of the word link in that dna > goal document? Copy-paste from RFC 2461.... I don't understand this comment either. We are referring to 2461. What is wrong with that? --Pekka From dna-owner@webcamserver.eng.monash.edu.au Wed Oct 27 22:29:10 2004 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09616 for ; Wed, 27 Oct 2004 22:29:08 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGKCB98SKU8X12P7@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Oct 2004 12:23:08 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4CAEA80002; Thu, 28 Oct 2004 12:22:34 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 085B73C00B; Thu, 28 Oct 2004 12:22:34 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9S2M4Y06472 for dna-list; Thu, 28 Oct 2004 12:22:04 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9S2M2606464 for ; Thu, 28 Oct 2004 12:22:02 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGKCAIPF0C8ZET2O@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 28 Oct 2004 12:22:00 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B3713AB545; Thu, 28 Oct 2004 12:21:58 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 4A2314FB0B; Thu, 28 Oct 2004 12:21:58 +1000 (EST) Date: Thu, 28 Oct 2004 12:21:58 +1000 From: Greg Daley Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: NJEDJOU Eric RD-RESA-REN Cc: Pekka Nikander , Dna , Erik Nordmark , YGHONG , ??? , JinHyeock Choi , ??? Reply-to: greg.daley@eng.monash.edu.au Message-id: <418057C6.4070909@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-Accept-Language: en, en-us Precedence: bulk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: Content-Transfer-Encoding: 8BIT Hi Eric, (this is as an author and WG member, not as a chair). NJEDJOU Eric RD-RESA-REN wrote: > Actually the DNA scheme would better not be the same depending on wether i > am able to attach to more than one link or not. Effectively, if i am > attached for instance to two links at the same time, i may not need to > go into the DNA process whenever i receive a hint that one of those > links (L2 or L3) is no more valid, if i am able to switch my flows onto > the other link without noticeable service interruption (after checking > that my IP configuration on that other link is valid). > > This is why i do not really like the sentence > "DNA schemes are typically run per interface. When a host has > multiple interfaces, the host separately checks for link changes on > each interface." > As said in the introduction of the dna goals document. I think DNA would > better run on an overall basis i.e seeing all of the links (which my > Ip layer is capable of for that matter). There is some text in the BCP document draft-narayanan-dna-bcp-01.txt which relates to situations with multiple interfaces in that it talks about inactive interfaces. It doesn't describe what should be discovered, but a means for handling interfaces which are not being used (for example, a second WLAN interface), and how to start DNA for them. The actual change discovery is largely the same, since it is based on link-local signalling. The requirement to initiate within a time bound may not be, due to the make-before-break nature of the operations. The coordination and policy decisions about interface preferences and which, though I'm not sure that this is in scope, because it varies dependent on upper layer protocols. If we need to add extra information to the BCP then I think it's worth discussing. As an aside, there's text about multiple connections through the same interface in the BCP too. Greg > Eric Njedjou > > > -----Message d'origine----- > De : owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.eng.monash.edu.au] De la part de Pekka Nikander > Envoyé : lundi 25 octobre 2004 08:59 > À : Dna > Cc : Erik Nordmark; YGHONG; ???; Greg Daley; JinHyeock Choi; ??? > Objet : Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies > > >>>I think that the case 3.2, 'Single interface with Make before Break' >>>will affect DNA solution design. I agree that we are not familiar >>>with this case, so it would be of much help, if you elaborate the >>>below with more detail. >>> >>> ... But in CDMA[7], a >>> mobile station can access two or more different base stations >>> simultaneously. In this case, a host can make a new link-layer >>> connection before an old link-layer connection is torn down. >> >>I hope that L2 can actually tell the packets apart. >>If this is possible, then the implementation could present the packets >>from the different links are arriving on different interfaces to IP. > > > I agree with Erik and others that the apparently cleanest way is to model the situation with distinct (virtual) interfaces, each corresponding to a wireless connection. > > However, I am also wondering how often we need that in practise. > As far as I've understood (which may be completely wrong), in the typical case the CDMA network models the whole base station network as a single link, with a single excess router. OTOH, I have no idea whether soft handovers between operators is defined or not. > If they are, then we probably need some care there. > > Taking a slightly wider angle, we can imagine various anomalies like someone inadvertedly connecting two (wireline) LAN segments together. That would (temporarily) create a similar situation. > Hence, I'm afraid that we need to make the DNA scheme(s) robust against these kinds of situations. However, my current opinion (subject to change) is that we should not worry too much about these kinds of situations, and it would be perfectly OK if it takes some more time to system to recover in such a situation. In other words, if some hosts unnecessarily run DNA and autoconfiguration, that wouldn't be too bad. > > Network operators have to live with the limits of technology anyway. If our DNA effort results in a piece of technology that has a number of well documented limitations, that is OK, as long as the WG agrees on the limitations. > > --Pekka > From dna-owner@webcamserver.eng.monash.edu.au Thu Oct 28 07:53:14 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04379 for ; Thu, 28 Oct 2004 07:53:12 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGKW1J7LUO8X87IS@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Oct 2004 21:47:29 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C38EA80005; Thu, 28 Oct 2004 21:47:23 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 6A2B03C006; Thu, 28 Oct 2004 21:47:23 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9SBkmN13106 for dna-list; Thu, 28 Oct 2004 21:46:48 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9SBkm613102 for ; Thu, 28 Oct 2004 21:46:48 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGKW0IBMKS8X7HG6@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 28 Oct 2004 21:46:34 +1000 Received: by localhost (Postfix, from userid 510) id 4BC53AB554; Thu, 28 Oct 2004 21:46:34 +1000 (EST) Received: from cms5.etri.re.kr (cms5.etri.re.kr [129.254.16.15]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9F9864FB06; Thu, 28 Oct 2004 21:46:31 +1000 (EST) Received: by cms5 with Internet Mail Service (5.5.2657.72) id ; Thu, 28 Oct 2004 20:52:28 +0900 Date: Thu, 28 Oct 2004 20:52:19 +0900 From: YGHONG Subject: RE: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , greg.daley@eng.monash.edu.au Cc: YGHONG , dna@eng.monash.edu.au, ??? , ??? Message-id: <30388A145972BC428B56434C562AE177019CD2C0@cms5> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT Dear JinHyeock.. Because I am not a specialist about CDMA, I can be wrong in some points. As my understanding (with discussion with other CDMA specialists), it is possible for a host to distinguish the IP packets from the old link-layer connection FROM the ones from the new link-layer connection. The reason is that a host in CDMA can have two link-layer connections during handover between base stations. One link-layer connection is for an old base station, the other link-layer connection is for a new base station. When handover happens and by using make-before-break, a host can have the ability to distinguish the IP packets. (Actually, current IPv4 based CDMA packet service in Korea, unfortunately only supports break-before-make(hard handover) because there are no needs for make-before-break(soft handover) ) So, if this situation is valuable for DNA schemes, we can ask CDMA operators to support make-before-break in IPv6 based CDMA packet service. But, if two(old and new) base stations are connected to different PDSN (Packet Data Serving Node, similar to router), during handover between base stations, an old PPP connection between the host and an old PDSN is disconnected and then a new PPP connection between the host and a new PDSN is connected. In this case, only break-before-make is used. Yong-Geun.. > -----Original Message----- > From: JinHyeock Choi [mailto:jinchoe@gmail.com] > Sent: Saturday, October 23, 2004 1:55 AM > To: greg.daley@eng.monash.edu.au > Cc: YGHONG; dna@eng.monash.edu.au; ???; ??? > Subject: Re: [DNA] Considerations for DNA Schemes with > multiple Interface and Layer 2 Technologies > > > Dear Yong-Geun > > I think that the case 3.2, 'Single interface with Make before Break' > will affect DNA solution design. I agree that we are not > familiar with this case, so it would be of much help, if you > elaborate the below with more detail. > > We think that we are not familiar with this case. But in > CDMA[7], a > mobile station can access two or more different base stations > simultaneously. In this case, a host can make a new link-layer > connection before an old link-layer connection is torn down. > > Especially I wonder whether it's possible for a host to > distinguish the IP packets from the old link-layer connection > FROM the ones from the new link-layer connection. > > However, it's not clear to me the relationship between 'DNA schemes' > and 'multiple interfaces' from Case 3.3 & 3.4 description. I > still can't see how multiple interfaces would affect DNA > schemes substantially. Kindly elaborate this more. > > Thanks for your kind consideration. > > Best Regards > > JinHyeock > From dna-owner@webcamserver.eng.monash.edu.au Thu Oct 28 09:33:49 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11744 for ; Thu, 28 Oct 2004 09:33:48 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGKZPYTTQO8ZHBSJ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 28 Oct 2004 23:33:38 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F2839AB544; Thu, 28 Oct 2004 23:33:22 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id D813E4FB07; Thu, 28 Oct 2004 23:33:21 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9SDX0e14703 for dna-list; Thu, 28 Oct 2004 23:33:00 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9SDWx614699 for ; Thu, 28 Oct 2004 23:32:59 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGKZP5STRG8X7SWN@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 28 Oct 2004 23:32:44 +1000 Received: by localhost (Postfix, from userid 510) id 410D7AB554; Thu, 28 Oct 2004 23:32:44 +1000 (EST) Received: from cms5.etri.re.kr (cms5.etri.re.kr [129.254.16.15]) by moe.its.monash.edu.au (Postfix) with ESMTP id 907794FB0A; Thu, 28 Oct 2004 23:32:41 +1000 (EST) Received: by cms5 with Internet Mail Service (5.5.2657.72) id ; Thu, 28 Oct 2004 22:38:39 +0900 Date: Thu, 28 Oct 2004 22:38:33 +0900 From: YGHONG Subject: RE: [DNA] Considerations for DNA Schemes with multiple Interface andLayer 2 Technologies Sender: owner-dna@ecselists.eng.monash.edu.au To: Brijesh Kumar , JinHyeock Choi , greg.daley@eng.monash.edu.au Cc: ??? , dna@eng.monash.edu.au, ??? , ??? Message-id: <30388A145972BC428B56434C562AE177019CD2C7@cms5> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT Hi.. Brilesh Kumar.. My understanding for current DNA scheme is that a host can determine the change of link only after a new link-layer connection is made and it receives link information when the change of link-layer connection happens. If a host can have the ability to make a new link-layer connection before an old link-layer connection is disconnected (make-before-break), I think that the host can determine whether link is changed before it receives RAs through a new link-layer connection from routers. . (To do this, Access Points (or Base Stations) must be tightly interacted with routers (PDSNs) like CDMA packet service.) Actually, in CDMA, L3 information in not necessary when moving between Base Stations which are connected to same PDSN. The host can directly use same IP configuration because it knows that link is same by L2 information I think that current DNA schemes are sufficient for currently used L2 technology such as Ethernet or WLAN. If we consider other (existing and future) wireless technologies, how about considering this fact? Yong-Geun.. > -----Original Message----- > From: Brijesh Kumar [mailto:kumarb@research.panasonic.com] > Sent: Saturday, October 23, 2004 2:53 AM > To: JinHyeock Choi; greg.daley@eng.monash.edu.au > Cc: YGHONG; dna@eng.monash.edu.au; ???; ??? > Subject: RE: [DNA] Considerations for DNA Schemes with > multiple InterfaceandLayer 2 Technologies > > > Yong-Geun; > > Like JinHyeock and Greg, I am too curious why CDMA soft > handoff should impact the DNA scheme specially since CDMA > provides make before break ability. > > Since with CDMA, it is possible to combine the data received > from two or more different sites to ease the transition from > one to the other, I am unable to see why this will have any > DNA issues at all. > > Can you please elaborate a little bit more clearly. > > Cheers, > > --bk > > > > > > > > > -----Original Message----- > > From: owner-dna@ecselists.eng.monash.edu.au > > [mailto:owner-dna@ecselists.eng.monash.edu.au]On Behalf Of > JinHyeock > > Dear Yong-Geun > > > > I think that the case 3.2, 'Single interface with Make before Break' > > will affect DNA solution design. I agree that we are not > familiar with > > this case, so it would be of much help, if you elaborate the below > > with more detail. > > > > We think that we are not familiar with this case. But > in CDMA[7], a > > mobile station can access two or more different base stations > > simultaneously. In this case, a host can make a new link-layer > > connection before an old link-layer connection is torn down. > > > > Especially I wonder whether it's possible for a host to distinguish > > the IP packets from the old link-layer connection FROM the > ones from > > the new link-layer connection. > > > > > > > > However, it's not clear to me the relationship between 'DNA schemes' > > and 'multiple interfaces' from Case 3.3 & 3.4 description. I still > > can't see how multiple interfaces would affect DNA schemes > > substantially. Kindly elaborate this more. > > > > Thanks for your kind consideration. > > > > Best Regards > > > > JinHyeock > From dna-owner@webcamserver.eng.monash.edu.au Thu Oct 28 11:48:05 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01635 for ; Thu, 28 Oct 2004 11:48:04 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGL4EGGKF28ZHDAX@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Oct 2004 01:47:22 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B60C780003; Fri, 29 Oct 2004 01:46:52 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 6B6C13C006; Fri, 29 Oct 2004 01:46:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9SFkP916900 for dna-list; Fri, 29 Oct 2004 01:46:25 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9SFkN616896 for ; Fri, 29 Oct 2004 01:46:23 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGL4DQXARC8X0RS0@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Oct 2004 01:46:18 +1000 Received: by localhost (Postfix, from userid 510) id A5737AB554; Fri, 29 Oct 2004 01:46:18 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id 5A7664FB09; Fri, 29 Oct 2004 01:46:16 +1000 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id i9SFkDQN031912; Thu, 28 Oct 2004 11:46:13 -0400 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 16D5F3C80E3; Thu, 28 Oct 2004 11:44:21 -0400 (EDT) Received: from Brijesh2K (dhcp251.Research.Panasonic.COM [150.169.1.251]) by redwood.research.panasonic.com (Postfix) with SMTP id 0A2563C80B4; Thu, 28 Oct 2004 11:44:21 -0400 (EDT) Date: Thu, 28 Oct 2004 11:49:51 -0400 From: Brijesh Kumar Subject: RE: [DNA] Considerations for DNA Schemes with multiple InterfaceandLayer 2 Technologies In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: NJEDJOU Eric RD-RESA-REN , Pekka Nikander , Dna Cc: Erik Nordmark , YGHONG , ??? , Greg Daley , JinHyeock Choi , ??? Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-MIME-Autoconverted: from quoted-printable to 8bit by webcamserver.eng.monash.edu.au id i9SFkN616897 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Precedence: bulk X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:13 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 8BIT > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au > [mailto:owner-dna@ecselists.eng.monash.edu.au]On Behalf Of NJEDJOU Eric > > In the same respect, > the sentence "Today, a link change necessitates an IP > configuration change." in the dna goals document introduction let > the reader believe that a node would not be having interfaces > attached to other links. Because if it is so, then the a > configuration that might have been built on the non used link > could start being used without requiring new IP configuration. It makes definite sense to me to clarify this aspect in any document that is discussing goals/ objective etc. I think there are three interfacing scenarios: a) single CDMA interface capable of connecting to two base stations (APs/BTS+BSS), each base station connected to a different network. b) two or more interfaces connected to a single network (same AR) c) Two or more interfaces on the device, but each interface connected to a separate network (902.11 + GPRS EDGE combo, or two 802.11 interfaces) Cheers, --bk > > > -----Message d'origine----- > De : owner-dna@ecselists.eng.monash.edu.au > [mailto:owner-dna@ecselists.eng.monash.edu.au] De la part de > Pekka Nikander > Envoyé : lundi 25 octobre 2004 08:59 > À : Dna > Cc : Erik Nordmark; YGHONG; ???; Greg Daley; JinHyeock Choi; ??? > Objet : Re: [DNA] Considerations for DNA Schemes with multiple > Interface and Layer 2 Technologies > > >> I think that the case 3.2, 'Single interface with Make before Break' > >> will affect DNA solution design. I agree that we are not familiar > >> with this case, so it would be of much help, if you elaborate the > >> below with more detail. > >> > >> ... But in CDMA[7], a > >> mobile station can access two or more different base stations > >> simultaneously. In this case, a host can make a new link-layer > >> connection before an old link-layer connection is torn down. > > > > I hope that L2 can actually tell the packets apart. > > If this is possible, then the implementation could present the packets > > from the different links are arriving on different interfaces to IP. > > I agree with Erik and others that the apparently cleanest way is > to model the situation with distinct (virtual) interfaces, each > corresponding to a wireless connection. > > However, I am also wondering how often we need that in practise. > As far as I've understood (which may be completely wrong), in the > typical case the CDMA network models the whole base station > network as a single link, with a single excess router. OTOH, I > have no idea whether soft handovers between operators is defined or not. > If they are, then we probably need some care there. > > Taking a slightly wider angle, we can imagine various anomalies > like someone inadvertedly connecting two (wireline) LAN segments > together. That would (temporarily) create a similar situation. > Hence, I'm afraid that we need to make the DNA scheme(s) robust > against these kinds of situations. However, my current opinion > (subject to change) is that we should not worry too much about > these kinds of situations, and it would be perfectly OK if it > takes some more time to system to recover in such a situation. > In other words, if some hosts unnecessarily run DNA and > autoconfiguration, that wouldn't be too bad. > > Network operators have to live with the limits of technology > anyway. If our DNA effort results in a piece of technology that > has a number of well documented limitations, that is OK, as long > as the WG agrees on the limitations. > > --Pekka > > From dna-owner@webcamserver.eng.monash.edu.au Thu Oct 28 12:36:18 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13447 for ; Thu, 28 Oct 2004 12:36:16 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGL5MI70XW8X7S2M@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Oct 2004 02:22:26 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8253CAB542; Fri, 29 Oct 2004 02:22:23 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 417894FB07; Fri, 29 Oct 2004 02:22:23 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9SGLiu17420 for dna-list; Fri, 29 Oct 2004 02:21:44 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9SGLi617416 for ; Fri, 29 Oct 2004 02:21:44 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGL5LNQRUK8X7S2M@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 29 Oct 2004 02:21:43 +1000 Received: by localhost (Postfix, from userid 510) id C4F3AAB544; Fri, 29 Oct 2004 02:21:42 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8C9C54FB08; Fri, 29 Oct 2004 02:21:40 +1000 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id i9SGLdPL000616; Thu, 28 Oct 2004 12:21:39 -0400 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id E8CB23C80E1; Thu, 28 Oct 2004 12:19:46 -0400 (EDT) Received: from Brijesh2K (dhcp251.Research.Panasonic.COM [150.169.1.251]) by redwood.research.panasonic.com (Postfix) with SMTP id DDB913C80B4; Thu, 28 Oct 2004 12:19:46 -0400 (EDT) Date: Thu, 28 Oct 2004 12:25:17 -0400 From: Brijesh Kumar Subject: RE: [DNA] Considerations for DNA Schemes with multipleInterfaceandLayer 2 Technologies In-reply-to: <30388A145972BC428B56434C562AE177019CD2C7@cms5> Sender: owner-dna@ecselists.eng.monash.edu.au To: YGHONG , JinHyeock Choi , greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au, ??? , ??? Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Precedence: bulk X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:21 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) Content-Transfer-Encoding: 7BIT Yong-Geun, thanks for responding to my earlier comment. > My understanding for current DNA scheme is that a host can determine the > change of link > only after a new link-layer connection is made and it receives link > information when the change > of link-layer connection happens. In theory, you can get both link up and down events. But, if you have only one interface, there is not much any one can do after you get a link down event. > If a host can have the ability to make a new link-layer connection before > an old link-layer connection > is disconnected (make-before-break), I think that the host can determine > whether link is changed > before it receives RAs through a new link-layer connection from > routers. . > (To do this, Access Points (or Base Stations) must be tightly interacted > with routers (PDSNs) > like CDMA packet service.) > Actually, in CDMA, L3 information in not necessary when moving > between Base > Stations which are > connected to same PDSN. The host can directly use same IP configuration > because it knows that > link is same by L2 information You are right here. In this case, the link change will be taken care of by the layer 2 hand-off mechanisms, and DNA mechanism wouldn't be needed. It can be seen as one layer 2 interface that has two independent link layer sessions (or two virtual links). The link is not until down both sessions are down. Clearly above is different than the mutiple physical interface scenarios where a node can be connected to a 802.11 network and at the same time connected to a GPRS or CDMA-1XRTT etc. > I think that current DNA schemes are sufficient for currently used L2 > technology such as Ethernet or WLAN. > If we consider other (existing and future) wireless technologies, > how about considering this fact? OK - I see your point now. Cheers, --bk > > -----Original Message----- > > From: Brijesh Kumar [mailto:kumarb@research.panasonic.com] > > Sent: Saturday, October 23, 2004 2:53 AM > > To: JinHyeock Choi; greg.daley@eng.monash.edu.au > > Cc: YGHONG; dna@eng.monash.edu.au; ???; ??? > > Subject: RE: [DNA] Considerations for DNA Schemes with > > multiple InterfaceandLayer 2 Technologies > > > > > > Yong-Geun; > > > > Like JinHyeock and Greg, I am too curious why CDMA soft > > handoff should impact the DNA scheme specially since CDMA > > provides make before break ability. > > > > Since with CDMA, it is possible to combine the data received > > from two or more different sites to ease the transition from > > one to the other, I am unable to see why this will have any > > DNA issues at all. > > > > Can you please elaborate a little bit more clearly. > > > > Cheers, > > > > --bk > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: owner-dna@ecselists.eng.monash.edu.au > > > [mailto:owner-dna@ecselists.eng.monash.edu.au]On Behalf Of > > JinHyeock > > > Dear Yong-Geun > > > > > > I think that the case 3.2, 'Single interface with Make before Break' > > > will affect DNA solution design. I agree that we are not > > familiar with > > > this case, so it would be of much help, if you elaborate the below > > > with more detail. > > > > > > We think that we are not familiar with this case. But > > in CDMA[7], a > > > mobile station can access two or more different base stations > > > simultaneously. In this case, a host can make a new link-layer > > > connection before an old link-layer connection is torn down. > > > > > > Especially I wonder whether it's possible for a host to distinguish > > > the IP packets from the old link-layer connection FROM the > > ones from > > > the new link-layer connection. > > > > > > > > > > > > > > However, it's not clear to me the relationship between 'DNA schemes' > > > and 'multiple interfaces' from Case 3.3 & 3.4 description. I still > > > can't see how multiple interfaces would affect DNA schemes > > > substantially. Kindly elaborate this more. > > > > > > Thanks for your kind consideration. > > > > > > Best Regards > > > > > > JinHyeock > > From dna-owner@webcamserver.eng.monash.edu.au Fri Oct 29 01:44:56 2004 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11362 for ; Fri, 29 Oct 2004 01:44:54 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGLXL4BSCA8ZHLZ9@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Oct 2004 15:43:15 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 23FE9AB544; Fri, 29 Oct 2004 15:43:00 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id A24824FB0B; Fri, 29 Oct 2004 15:42:59 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9T5gPF27330 for dna-list; Fri, 29 Oct 2004 15:42:25 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9T5gO627326 for ; Fri, 29 Oct 2004 15:42:24 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGLXK87W208X1AT2@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Oct 2004 15:42:17 +1000 Received: by localhost (Postfix, from userid 510) id 30415AB54A; Fri, 29 Oct 2004 15:42:15 +1000 (EST) Received: from kecgate03.infosys.com (unknown [220.227.179.21]) by curly.its.monash.edu.au (Postfix) with ESMTP id A32B14FB0B for ; Fri, 29 Oct 2004 15:42:12 +1000 (EST) Received: from indhubbhs01.ad.infosys.com ([192.168.200.81]) by kecgate03.infosys.com with InterScan Messaging Security Suite; Fri, 29 Oct 2004 11:07:27 +0530 Received: from kecmsg07.ad.infosys.com ([192.168.200.68]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 29 Oct 2004 11:11:03 +0530 Received: from kecmsg01.ad.infosys.com ([192.168.200.78]) by kecmsg07.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 29 Oct 2004 11:11:03 +0530 Date: Fri, 29 Oct 2004 11:11:03 +0530 From: Rajesh George Subject: [DNA] Plz clarify from draft-ietf-dna-link-information-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <31E1CAD34DAF2F48A768DE429D88E5990B1A32FB@kecmsg01.ad.infosys.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Precedence: bulk Thread-Topic: Plz clarify from draft-ietf-dna-link-information-00.txt Thread-Index: AcS9eeBo92wRHIw8TNOMDPvormHg2A== content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) X-OriginalArrivalTime: 29 Oct 2004 05:41:03.0647 (UTC) FILETIME=[E0FB3AF0:01C4BD79] Content-Transfer-Encoding: 7BIT Hi all I am not clear about about sec 2.1 of the draft I have the following case in mind. Case:- An MS already has an on going session with a WLAN and I suppose MS does not have GPRS coverage in that area. Now MS move out of WLAN coverage to GPRS area which does not have WLAN coverage. Now regarding the LL events My confusion:- PDP context activation is triggered by the upper layer. As the WLAN session is going on upper layers are using L2 of WLAN as the underlying mechanism for transporting packets. Now how MS can initiate a PDP context activation? Regards Rajesh George From dna-owner@webcamserver.eng.monash.edu.au Fri Oct 29 02:22:38 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27830 for ; Fri, 29 Oct 2004 02:22:37 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGLYY1H5K68X83VD@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Oct 2004 16:21:46 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C3581AB556; Fri, 29 Oct 2004 16:21:39 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 5FE474FB09; Fri, 29 Oct 2004 16:21:39 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9T6LSL27788 for dna-list; Fri, 29 Oct 2004 16:21:28 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9T6LS627784 for ; Fri, 29 Oct 2004 16:21:28 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGLYXQV4Z28X1BD6@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Oct 2004 16:21:26 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8FAD5AB543; Fri, 29 Oct 2004 16:21:25 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 7178B4FB04; Fri, 29 Oct 2004 16:21:25 +1000 (EST) Date: Fri, 29 Oct 2004 16:21:25 +1000 From: Greg Daley Subject: Re: [DNA] Plz clarify from draft-ietf-dna-link-information-00.txt In-reply-to: <31E1CAD34DAF2F48A768DE429D88E5990B1A32FB@kecmsg01.ad.infosys.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Rajesh George Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <4181E165.8090302@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us References: <31E1CAD34DAF2F48A768DE429D88E5990B1A32FB@kecmsg01.ad.infosys.com> Content-Transfer-Encoding: 7BIT Hi Rajesh, This seems like it's an interesting candidate to discuss with respect to the multiple interfaces we've been looking at in another thread. Rajesh George wrote: > Hi all > > I am not clear about about sec 2.1 of the draft > I have the following case in mind. > > Case:- > An MS already has an on going session with a WLAN and I suppose > MS does not have GPRS coverage in that area. Now MS move out of WLAN > coverage to GPRS area which does not have WLAN coverage. Now regarding > the LL events > > My confusion:- > PDP context activation is triggered by the upper layer. As the > WLAN session is going on upper layers are using L2 of WLAN as the > underlying mechanism for transporting packets. Now how MS can initiate a > PDP context activation? In IPv6, the WLAN is likely to have IP layer connectivity of its own without using GTP. So there will not need to be a PDP context on the WLAN interface, unless GTP is being used as a global mobility signalling protocol (an alternative would be to use Mobile IPv6). DNA is (typically :) run per interface, so movement out of WLAN coverage may provide DNA with connectivity indications out of the link-layer (Link-Down of the WLAN. PDP context activation occurs to establish a link-layer connection to the GGSN, which acts as a router on the GPRS link. Upon establishment of the context, an event notification (Link-Up) may be generated (including IP addressing). The establishment of PDP context occurs due to link-layer action, though, not necessarily through network layer action. When a host notices it has lost connectivity in WLAN it may bring up its GPRS interface, though, which could initiate it (these decisions seem to be out of scope for DNA though). There's normally no need to link the WLAN to the GPRS unless the address used for both is going to be the same (through some sort of interworking). Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Oct 29 04:06:04 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05527 for ; Fri, 29 Oct 2004 04:06:02 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGM2IQGR748ZHI2B@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Oct 2004 18:04:00 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3830FAB547; Fri, 29 Oct 2004 18:03:51 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id EBC764FB18; Fri, 29 Oct 2004 18:03:50 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9T81oH29001 for dna-list; Fri, 29 Oct 2004 18:01:50 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9T81m628997 for ; Fri, 29 Oct 2004 18:01:48 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGM2FVGX3I8X12PI@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Oct 2004 18:01:33 +1000 Received: by localhost (Postfix, from userid 510) id F138AAB544; Fri, 29 Oct 2004 18:01:32 +1000 (EST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by curly.its.monash.edu.au (Postfix) with ESMTP id E1AF74FB02; Fri, 29 Oct 2004 18:01:29 +1000 (EST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Oct 2004 09:59:11 +0200 Date: Fri, 29 Oct 2004 09:59:09 +0200 From: NJEDJOU Eric RD-RESA-REN Subject: RE: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander Cc: JinHyeock Choi , Dna , Greg Daley Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MIME-Autoconverted: from quoted-printable to 8bit by webcamserver.eng.monash.edu.au id i9T81m628998 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Precedence: bulk Thread-Topic: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies Thread-Index: AcS8XPWqFHoD3ykUS4i0jlzdUP1+1wBL6iqA Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) X-OriginalArrivalTime: 29 Oct 2004 07:59:11.0062 (UTC) FILETIME=[2CAA6760:01C4BD8D] Content-Transfer-Encoding: 8BIT Well Pekka, Greg, i had not followed precedent discussions on this and did not know the issue had already been raised and got a consensus. Sorry; Will check the thread archive... Eric -----Message d'origine----- De : Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] Envoyé : mercredi 27 octobre 2004 21:41 À : NJEDJOU Eric RD-RESA-REN Cc : JinHyeock Choi; Dna; Greg Daley Objet : Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies Eric, The DNA goals document has been passed to the IESG. We already had the WG LC, resolved the comments, and as the comments were mostly editorial in nature, passed the document to the IESG. Do you feel that we should pull the document back? (I am not saying that I am willing to do that, I just want to understand how strongly you feel about your comments.) > Actually the DNA scheme would better not be the same depending on > wether i am able to attach to more than one link or not. Effectively, > if i am attached for instance to two links at the same time, i may not > need to go into the DNA process whenever i receive a hint that one of > those links (L2 or L3) is no more valid, if i am able to switch my > flows onto the other link without noticeable service interruption > (after checking that my IP configuration on that other link is valid). > > This is why i do not really like the sentence "DNA schemes are > typically run per interface. When a host has > multiple interfaces, the host separately checks for link changes on > each interface." > As said in the introduction of the dna goals document. I think DNA > would better run on an overall basis i.e seeing all of the links > (which my Ip layer is capable of for that matter). We discussed this already, see e.g. http://webcamserver.eng.monash.edu.au/~warchive/dna/2004-09/ msg00019.html and the messages before and after that. I don't quite understand how your comment is different from what Erik and I discussed? I originally more or less felt like you, but after some consideration came to the conclusion that the complications that would result are not worth the effort. However, for the related reasons we added the word "typically" to the above sentence, among other things. On Oct 27, 2004, at 19:02, NJEDJOU Eric RD-RESA-REN wrote: > In the same respect, > the sentence "Today, a link change necessitates an IP configuration > change." in the dna goals document introduction let the reader believe > that a node would not be having interfaces attached to other links. > Because if it is so, then the a configuration that might have been > built on the non used link could start being used without requiring > new IP configuration. I don't understand this comment. The document says pretty clearly that you _typically_ do DNA per interface. Hence, if you link changes, you _typically_ run DNA on the interface attached to that link, and not on others. What am I missing? > Is it possible to recall the definition of the word link in that dna > goal document? Copy-paste from RFC 2461.... I don't understand this comment either. We are referring to 2461. What is wrong with that? --Pekka From dna-owner@webcamserver.eng.monash.edu.au Fri Oct 29 05:30:59 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11377 for ; Fri, 29 Oct 2004 05:30:58 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGM5IQLR2M8X1C2F@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Oct 2004 19:30:36 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AFBF8AB556; Fri, 29 Oct 2004 19:30:08 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 6FC384FB02; Fri, 29 Oct 2004 19:30:08 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9T9Tje30540 for dna-list; Fri, 29 Oct 2004 19:29:45 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9T9Ti630536 for ; Fri, 29 Oct 2004 19:29:45 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGM5HVZ6DO8X16JD@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Oct 2004 19:29:28 +1000 Received: by localhost (Postfix, from userid 510) id B93B5AB558; Fri, 29 Oct 2004 19:29:27 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by moe.its.monash.edu.au (Postfix) with ESMTP id B30984FB10; Fri, 29 Oct 2004 19:29:25 +1000 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6C004JGACYOE@mailout2.samsung.com>; Fri, 29 Oct 2004 18:29:22 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6C005V4ACIEH@mailout2.samsung.com>; Fri, 29 Oct 2004 18:29:06 +0900 (KST) Received: from jinchoe ([75.2.91.235]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I6C008A4ACIU3@mmp2.samsung.com>; Fri, 29 Oct 2004 18:29:06 +0900 (KST) Date: Fri, 29 Oct 2004 18:29:06 +0900 From: JinHyeock Choi Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark , JinHyeock Choi , JinHyeock Choi Cc: greg.daley@eng.monash.edu.au, YGHONG , dna@eng.monash.edu.au, ??? , ??? Message-id: <074b01c4bd99$bc8e39e0$eb5b024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <30388A145972BC428B56434C562AE177019CCE02@cms5> <41772CE4.1030103@eng.monash.edu.au> <92e919fb0410220955183694fc@mail.gmail.com> <417975C3.9000800@sun.com> Content-Transfer-Encoding: 7BIT Dear Erik > > Especially I wonder whether it's possible for a host to distinguish > > the IP packets from the old link-layer connection FROM the ones > > from the new link-layer connection. > > I hope that L2 can actually tell the packets apart. > If this is possible, then the implementation could present the packets > from the different links are arriving on different interfaces to IP. Right. To put the above more precisely, " the implementation could present the packets from the different link-layer connections (NOT different links) are arriving on different interfaces to IP." An interface only knows that the packets are arriving from different link-layer connections. It has no way to determine whether they are from different links or not. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Oct 29 06:01:08 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13897 for ; Fri, 29 Oct 2004 06:01:07 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGM6LGGIGG8ZHNHH@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Oct 2004 20:00:51 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BD1E6AB543; Fri, 29 Oct 2004 20:00:34 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 75B8C4FB02; Fri, 29 Oct 2004 20:00:34 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9TA0NO31078 for dna-list; Fri, 29 Oct 2004 20:00:23 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9TA0M631067 for ; Fri, 29 Oct 2004 20:00:22 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGM6KTKRKA8X16MD@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Oct 2004 20:00:04 +1000 Received: by localhost (Postfix, from userid 510) id 5487380003; Fri, 29 Oct 2004 20:00:04 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by larry.its.monash.edu.au (Postfix) with ESMTP id 9B8833C009; Fri, 29 Oct 2004 20:00:02 +1000 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0I6C00F4LBS0ZY@mailout1.samsung.com>; Fri, 29 Oct 2004 19:00:00 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I6C005MBBR2WC@mailout1.samsung.com>; Fri, 29 Oct 2004 18:59:26 +0900 (KST) Received: from jinchoe ([75.2.91.235]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I6C001PQBR2DY@mmp2.samsung.com>; Fri, 29 Oct 2004 18:59:26 +0900 (KST) Date: Fri, 29 Oct 2004 18:59:25 +0900 From: JinHyeock Choi Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander , Dna Cc: Erik Nordmark , YGHONG , ??? , Greg Daley , JinHyeock Choi , JinHyeock Choi Message-id: <079b01c4bd9d$f9296010$eb5b024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: <30388A145972BC428B56434C562AE177019CCE02@cms5> <41772CE4.1030103@eng.monash.edu.au> <92e919fb0410220955183694fc@mail.gmail.com> <417975C3.9000800@sun.com> <591D4576-2653-11D9-AFFD-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7BIT Dear Pekka > >> ... But in CDMA[7], a > >> mobile station can access two or more different base stations > >> simultaneously. In this case, a host can make a new link-layer > >> connection before an old link-layer connection is torn down. > > > > I hope that L2 can actually tell the packets apart. > > If this is possible, then the implementation could present the packets > > from the different links are arriving on different interfaces to IP. > > I agree with Erik and others that the apparently cleanest way is > to model the situation with distinct (virtual) interfaces, each > corresponding to a wireless connection. Agree. For a detailed operation, we may need a little more elaboration. > However, I am also wondering how often we need that in practise. > As far as I've understood (which may be completely wrong), in the > typical case the CDMA network models the whole base station network > as a single link, with a single excess router. OTOH, I have no > idea whether soft handovers between operators is defined or not. > If they are, then we probably need some care there. > > Taking a slightly wider angle, we can imagine various anomalies > like someone inadvertedly connecting two (wireline) LAN segments > together. That would (temporarily) create a similar situation. > Hence, I'm afraid that we need to make the DNA scheme(s) robust > against these kinds of situations. However, my current opinion > (subject to change) is that we should not worry too much about > these kinds of situations, and it would be perfectly OK if it takes > some more time to system to recover in such a situation. In other > words, if some hosts unnecessarily run DNA and autoconfiguration, > that wouldn't be too bad. > > Network operators have to live with the limits of technology > anyway. If our DNA effort results in a piece of technology that > has a number of well documented limitations, that is OK, as long > as the WG agrees on the limitations. Agree. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Oct 29 06:35:17 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15251 for ; Fri, 29 Oct 2004 06:35:15 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGM7N9P0IS8ZEVHG@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 29 Oct 2004 20:31:10 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F09EDAB554; Fri, 29 Oct 2004 20:31:03 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9F5C54FB03; Fri, 29 Oct 2004 20:31:03 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9TAUko31428 for dna-list; Fri, 29 Oct 2004 20:30:46 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9TAUj631424 for ; Fri, 29 Oct 2004 20:30:45 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGM7MNF81O8WWR43@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 29 Oct 2004 20:30:34 +1000 Received: by localhost (Postfix, from userid 510) id 3BAEB80002; Fri, 29 Oct 2004 20:30:34 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by larry.its.monash.edu.au (Postfix) with ESMTP id 8D4B73C003; Fri, 29 Oct 2004 20:30:32 +1000 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6C00707D6UT7@mailout3.samsung.com>; Fri, 29 Oct 2004 19:30:30 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6C00K41D6TK8@mailout3.samsung.com>; Fri, 29 Oct 2004 19:30:30 +0900 (KST) Received: from jinchoe ([75.2.91.235]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I6C00MH2D6TYR@mmp1.samsung.com>; Fri, 29 Oct 2004 19:30:29 +0900 (KST) Date: Fri, 29 Oct 2004 19:30:29 +0900 From: JinHyeock Choi Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies Sender: owner-dna@ecselists.eng.monash.edu.au To: NJEDJOU Eric RD-RESA-REN , Pekka Nikander , Dna Cc: Erik Nordmark , YGHONG , ??? , Greg Daley , JinHyeock Choi , ??? , JinHyeock Choi Message-id: <07da01c4bda2$4fd57f80$eb5b024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) References: Content-Transfer-Encoding: 7BIT Dear Eric Njedjou I think we have confusion about what DNA schemes accomplish. DNA schemes aim to detect the identity of currently attached link to verify IP configuration. It's closely related, but not identical, to handoff process. > Actually the DNA scheme would better not be the same depending on wether i am able to > attach to more than one link or not. Effectively, if i am attached for instance to two links at > the same time, i may not need to go into the DNA process whenever i receive a hint that > one of those links (L2 or L3) is no more valid, if i am able to switch my flows onto the > other link without noticeable service interruption (after checking that my IP configuration on > that other link is valid). Even in the above case, DNA scheme is needed. Without DNA process, a host will switch flow onto the other link whenever it receive a hint, resulting in undue signaling. Also DNA schemes enable a host to check whether its IP configuration on a link is valid or not. > This is why i do not really like the sentence > "DNA schemes are typically run per interface. When a host has > multiple interfaces, the host separately checks for link changes on > each interface." > As said in the introduction of the dna goals document. I think DNA would better run on > an overall basis i.e seeing all of the links (which my Ip layer is capable of for that matter). I think we have confusion about what DNA schemes accomplish. > In the same respect, > the sentence "Today, a link change necessitates an IP configuration change." > in the dna goals document introduction let the reader believe that a node would > not be having interfaces attached to other links. Because if it is so, then the > a configuration that might have been built on the non used link could start being > used without requiring new IP configuration. Some IP configuration, such as IP addres, is assigned to an interface. When an interface attaches to a new link, its existing IP address is no longer valid. Hence the interface needs a new IP address, irrespective of whether the host it belongs has other interfaces or not. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Oct 29 11:59:44 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10997 for ; Fri, 29 Oct 2004 11:59:43 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGMIZ2HRZC8X7O0S@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 30 Oct 2004 01:55:15 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3BDD4AB557; Sat, 30 Oct 2004 01:55:09 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id E83654FB03; Sat, 30 Oct 2004 01:55:08 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9TFsV602428 for dna-list; Sat, 30 Oct 2004 01:54:31 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9TFsV602424 for ; Sat, 30 Oct 2004 01:54:31 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGMIY6MHSO8X88YM@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Sat, 30 Oct 2004 01:54:26 +1000 Received: by localhost (Postfix, from userid 510) id 8E3E1AB542; Sat, 30 Oct 2004 01:54:26 +1000 (EST) Received: from RRWNOTE.org (213-229-63-72.static.adsl-line.inode.at [213.229.63.72]) by curly.its.monash.edu.au (Postfix) with SMTP id 2F5CF4FB03 for ; Sat, 30 Oct 2004 01:54:22 +1000 (EST) Date: Fri, 29 Oct 2004 17:50:02 +0100 From: "Greg.daley" Subject: [DNA] Re: Hi Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_46eOBhXmN+uTGH+63RflQQ)" Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) X-Spam-Level: *** --Boundary_(ID_46eOBhXmN+uTGH+63RflQQ) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT :))
--Boundary_(ID_46eOBhXmN+uTGH+63RflQQ) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT +--------------------------------------------------------------------- | NOTICE: The following listed attachment(s) have been removed from | this email for security reasons. Please refer to the | following website for further information: | http://www.its.monash.edu.au/messaging/faq/viruses.html +--------------------------------------------------------------------- | | FILE(S) REMOVED: | | "price.com" | +--------------------------------------------------------------------- --Boundary_(ID_46eOBhXmN+uTGH+63RflQQ)-- From dna-owner@webcamserver.eng.monash.edu.au Fri Oct 29 12:25:16 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12730 for ; Fri, 29 Oct 2004 12:25:15 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGMK0C781U8X89F3@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 30 Oct 2004 02:24:34 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BD22F80002; Sat, 30 Oct 2004 02:24:24 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 6AB153C00A; Sat, 30 Oct 2004 02:24:24 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9TGO0T02763 for dna-list; Sat, 30 Oct 2004 02:24:00 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9TGNx602759 for ; Sat, 30 Oct 2004 02:23:59 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGMJYIPHPG8ZHNNG@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 30 Oct 2004 02:23:44 +1000 Received: by localhost (Postfix, from userid 510) id 30DF380002; Sat, 30 Oct 2004 02:23:44 +1000 (EST) Received: from jaju.cvnet.co.kr (unknown [219.252.92.142]) by larry.its.monash.edu.au (Postfix) with SMTP id 488753C00A for ; Sat, 30 Oct 2004 02:23:42 +1000 (EST) Received: from 221.147.158.196 (221.147.158.196) by jaju.cvnet.co.kr with ZMAIL SMTP; Sat, 30 Oct 2004 01:23:18 +0900 Date: Sat, 30 Oct 2004 01:23:14 +0900 From: JinHyeock Choi Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies Sender: owner-dna@ecselists.eng.monash.edu.au To: YGHONG , JinHyeock Choi , greg.daley@eng.monash.edu.au Cc: YGHONG , dna@eng.monash.edu.au, ??? , ??? , jinchoe@samsung.com Message-id: <0ffb01c4bdd3$9a55a630$c49e93dd@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc2 (2004-08-15) X-Spam-Level: ** References: <30388A145972BC428B56434C562AE177019CD2C0@cms5> Content-Transfer-Encoding: 7BIT Dear Yong-Geun Thanks for your reply. > Because I am not a specialist about CDMA, I can be wrong in some points. > As my understanding (with discussion with other CDMA specialists), > it is possible for a host to distinguish the IP packets from the old > link-layer connection FROM the ones > from the new link-layer connection. Glad & relieved to hear that. > The reason is that a host in CDMA can > have two link-layer connections > during handover between base stations. One link-layer connection is for an > old base station, the other link-layer > connection is for a new base station. When handover happens and by using > make-before-break, a host can have > the ability to distinguish the IP packets. I am confused. Why does a host need 'make-before-break' technology to distinguish the IP packets? In case there is no 'make-before-break', only one link-layer connection is allowed per interface. Hence, all the packets come from the same link-layer connection. No need to distinguish packets at all. > (Actually, current IPv4 based > CDMA packet service in Korea, unfortunately > only supports break-before-make(hard handover) because there are no needs > for make-before-break(soft handover) ) > So, if this situation is valuable for DNA schemes, we can ask CDMA > operators to support make-before-break in > IPv6 based CDMA packet service. Allow me to present it more logically. First, If CDMA supports 'make-before-break', it's possible for an interface to establish multiple link-layer connections at the same time. Second, If so, it's difficult for an interface to detect the identity of the currently attached link, because there may be more than one currently attached links. Third, In this case, it would help DNA scheme if an interface can distinguish the packets from one link-layer connection from another. Purely DNA point of view, it would be better if CDMA doesn't support 'make-before-break' at all. It would make DNA much simpler. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Oct 29 12:50:08 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14770 for ; Fri, 29 Oct 2004 12:50:07 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGMKVZ4O4S8ZHPB9@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 30 Oct 2004 02:50:05 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9715F80002; Sat, 30 Oct 2004 02:49:55 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 489423C00B; Sat, 30 Oct 2004 02:49:55 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9TGnhg03078 for dna-list; Sat, 30 Oct 2004 02:49:43 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9TGng603074 for ; Sat, 30 Oct 2004 02:49:42 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGMKVC7K588X1EIF@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 30 Oct 2004 02:49:26 +1000 Received: by localhost (Postfix, from userid 510) id DE631AB54A; Sat, 30 Oct 2004 02:49:24 +1000 (EST) Received: from jaju.cvnet.co.kr (unknown [219.252.92.142]) by curly.its.monash.edu.au (Postfix) with SMTP id 6FB1B4FB02 for ; Sat, 30 Oct 2004 02:49:21 +1000 (EST) Received: from 221.147.158.196 (221.147.158.196) by jaju.cvnet.co.kr with ZMAIL SMTP; Sat, 30 Oct 2004 01:49:16 +0900 Date: Sat, 30 Oct 2004 01:49:12 +0900 From: JinHyeock Choi Subject: Re: [DNA] Considerations for DNA Schemes with multipleInterfaceandLayer 2 Technologies Sender: owner-dna@ecselists.eng.monash.edu.au To: Brijesh Kumar , NJEDJOU Eric RD-RESA-REN , Pekka Nikander , Dna Cc: Erik Nordmark , YGHONG , ??? , Greg Daley , JinHyeock Choi , ??? , jinchoe@samsung.com Message-id: <104201c4bdd7$3a8e9e60$c49e93dd@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) X-Spam-Level: ** References: Content-Transfer-Encoding: 7BIT > > In the same respect, > > the sentence "Today, a link change necessitates an IP > > configuration change." in the dna goals document introduction let > > the reader believe that a node would not be having interfaces > > attached to other links. Because if it is so, then the a > > configuration that might have been built on the non used link > > could start being used without requiring new IP configuration. > > It makes definite sense to me to clarify this aspect in any document > that is discussing goals/ objective etc. Disagree. I see little connection with this aspect with goals/objectives. How can an IP address assigned to one interface can be used in other interface? What if they are attached to different links? In case I am wrong, kindly enlighten me. > I think there are three interfacing scenarios: > > a) single CDMA interface capable of connecting to two base > stations (APs/BTS+BSS), each base station connected to a > different network. > > b) two or more interfaces connected to a single network (same AR) > > c) Two or more interfaces on the device, but each interface connected > to a separate network (902.11 + GPRS EDGE combo, or two 802.11 > interfaces) DNA is run per interface. Each interface detects the identity of currently attached link. Hence few need to take b) and c) into special consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Sun Oct 31 17:49:31 2004 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10911 for ; Sun, 31 Oct 2004 17:49:30 -0500 (EST) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGPS337F328ZI6HF@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 01 Nov 2004 09:48:22 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9BBF180004; Mon, 01 Nov 2004 09:48:04 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 143E53C004; Mon, 01 Nov 2004 09:48:04 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i9VMkgG09045 for dna-list; Mon, 01 Nov 2004 09:46:42 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i9VMkd609041 for ; Mon, 01 Nov 2004 09:46:40 +1100 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGPS0V00LO8ZI59H@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 01 Nov 2004 09:46:20 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E434880007; Mon, 01 Nov 2004 09:46:16 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 6C5803C006; Mon, 01 Nov 2004 09:46:16 +1100 (EST) Date: Mon, 01 Nov 2004 09:46:16 +1100 From: Greg Daley Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies In-reply-to: <0ffb01c4bdd3$9a55a630$c49e93dd@jinchoe> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: YGHONG , JinHyeock Choi , dna@eng.monash.edu.au, ??? , ??? , jinchoe@samsung.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <41856B38.9050308@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us Precedence: bulk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <30388A145972BC428B56434C562AE177019CD2C0@cms5> <0ffb01c4bdd3$9a55a630$c49e93dd@jinchoe> Content-Transfer-Encoding: 7BIT Hi JinHyeock, JinHyeock Choi wrote: [cut] > Purely DNA point of view, it would be better if CDMA doesn't support > 'make-before-break' at all. It would make DNA much simpler. I know this was a throw-away line, but it's hard to throw away. I think that MBB will have to be supported, in DNA. This is especially the case where Unreachability is to be determined from certain tests. We mainly need to be clear about which tests are applicable and what inference is taken from received messages. I think this is still in coverage for the BCP and Goals though. Greg From dna-owner@webcamserver.eng.monash.edu.au Sun Oct 31 23:51:37 2004 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04711 for ; Sun, 31 Oct 2004 23:51:36 -0500 (EST) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGQ4QGRIYC8X1VXK@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 01 Nov 2004 15:50:43 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4F329AB554; Mon, 01 Nov 2004 15:50:31 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0D6914FB0A; Mon, 01 Nov 2004 15:50:31 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id iA14nxI13021 for dna-list; Mon, 01 Nov 2004 15:49:59 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id iA14nw613017 for ; Mon, 01 Nov 2004 15:49:58 +1100 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LGQ4PJ745Q8X26ZV@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 01 Nov 2004 15:49:46 +1100 Received: by localhost (Postfix, from userid 510) id 6689FAB544; Mon, 01 Nov 2004 15:49:46 +1100 (EST) Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by curly.its.monash.edu.au (Postfix) with ESMTP id 4AE894FB05; Mon, 01 Nov 2004 15:49:42 +1100 (EST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id BA99B220009; Mon, 01 Nov 2004 06:49:37 +0200 (EET) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id B3DAA8; Mon, 01 Nov 2004 06:49:38 +0200 (EET) Date: Mon, 01 Nov 2004 06:49:37 +0200 From: Pekka Nikander Subject: Re: [DNA] Considerations for DNA Schemes with multiple Interface and Layer 2 Technologies In-reply-to: <41856B38.9050308@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Cc: JinHyeock Choi , YGHONG , ??? , JinHyeock Choi , Greg Daley , JinHyeock Choi , ??? Message-id: <6F373F6F-2BC1-11D9-B982-000D9331AFB0@nomadiclab.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Precedence: bulk X-Spam-Checker-Version: SpamAssassin 3.0.0-rc3 (2004-09-03) References: <30388A145972BC428B56434C562AE177019CD2C0@cms5> <0ffb01c4bdd3$9a55a630$c49e93dd@jinchoe> <41856B38.9050308@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT >> Purely DNA point of view, it would be better if CDMA doesn't support >> 'make-before-break' at all. It would make DNA much simpler. > > I know this was a throw-away line, but it's hard to throw away. > > I think that MBB will have to be supported, in DNA. This is especially > the case where Unreachability is to be determined from certain tests. > > We mainly need to be clear about which tests are applicable and > what inference is taken from received messages. I think this > is still in coverage for the BCP and Goals though. I have to admit that I am totally confused now. Maybe I just don't know the facts. So, let me ask some stupid questions: 1. Are people planning to use make-before-break with CDMA with PPP or not? Or both? (If PPP is used, I see no problem wrt. DNA as PPP is then the link layer to IPv6, and the situation has to be handled below the IPv6 layer.) 2. Assuming no PPP is used, are there any actual plans of supporting make-before-break between networks that actually have different IPv6 configuration at different base stations? (If not, again, I don't see what we have to worry about.) 3. Assuming no PPP is used and make-before-break is supported between base stations that potentially have different network configuration, is there any reason why the link layer cannot model the situation as two different interfaces? That is, even in the case that the CDMA link layer does not use PPP but is directly visible to IPv6, if we can model the radio layer connections to different base stations as different interfaces, as seen by IPv6, I don't see any problem. The worst that can there happen is that the two interfaces, corresponding to the two radio layer connections, are connected to the same IPv6 network. But that is a case that we have to handle otherwise, too. There may be some problems related to link layer addresses, etc, but someone should really point us to the right documents, or better, write a problem statement draft of the situation, trying to clarify the current plans of running IPv6 over make-before-break CDMA (and other such radio links). I don't see much use to argue about this until we properly understand the details, and at least I can't possibly claim understanding them. I don't even know what documents I should read; sorry about my ignorance. --Pekka