From dna-owner@webcamserver.eng.monash.edu.au Sun May 1 05:01:41 2005 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 FAA05647 for ; Sun, 1 May 2005 05:01:39 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNR64MOO1A96Y6Y2@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sun, 01 May 2005 19:01:01 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E5C89AB543; Sun, 01 May 2005 19:00:35 +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 A42CD4FB03; Sun, 01 May 2005 19:00:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j418x5I17097 for dna-list; Sun, 01 May 2005 18:59:05 +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 j418x4617093 for ; Sun, 01 May 2005 18:59:04 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNR62NW5I09AN5X8@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sun, 01 May 2005 18:59:01 +1000 Received: by localhost (Postfix, from userid 510) id EA101AB542; Sun, 01 May 2005 18:59:00 +1000 (EST) Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by curly.its.monash.edu.au (Postfix) with ESMTP id 788B04FB02; Sun, 01 May 2005 18:58:56 +1000 (EST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j418wqfm015285; Sun, 01 May 2005 10:58:53 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 01 May 2005 10:58:51 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.13]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 01 May 2005 10:58:51 +0200 Received: from [127.0.0.1] (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2C5AF18AAA; Sun, 01 May 2005 11:58:50 +0300 (EEST) Date: Sun, 01 May 2005 11:58:47 +0300 From: "Tero Kauppinen (JO/LMF)" Subject: Re: [DNA] RE: Review of link-information from Pekka Savola In-reply-to: <002101c54d11$aa89d670$291d9069@sisa.samsung.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Alper Yegin Cc: "'Pekka Savola'" , "'Greg Daley'" , dna@eng.monash.edu.au Message-id: <42749A47.8030409@ericsson.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 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <002101c54d11$aa89d670$291d9069@sisa.samsung.com> X-OriginalArrivalTime: 01 May 2005 08:58:51.0304 (UTC) FILETIME=[FEA9FA80:01C54E2B] Content-Transfer-Encoding: 7BIT Alper Yegin wrote: > Pekka, > > I perceive this mostly as a stack configuration issue. If your IP has > nothing to do with a given interface, it should not be getting any > notifications from there (include the link up). [For example, you would > not plumb IP driver on a non-IP L2 driver]. I agree. > > IPv4 vs. IPv6 distinction is harder. Link up would tell "IP is enabled", > but not necessarily which version of the IP is supported on that link. > The DNA process that consumes the link up notification would have to > figure that out. Why should DNA be started on an interface that doesn't support IPv6 in the first place? Naturally this issue comes valid if a node roams from an IPv6 network to an IPv4 network (or vice versa). IMHO that's beyond the scope of DNA. Anyway, what will happen is that the DNA process will try to confirm whether it's still on the same IPv6 link or not but the process will fail (i.e. timeout). What the node can of course do is to run DHCP to get an IPv4 address (in parallel or after the timeout). /Tero > > Alper > > > > >>>> Node's establishment of a link-layer connection with an >>> >>>attachment >>> >>>> point that signifies the availability of IP service (i.e., > > being > >>>>able >>>> to send and receive IP packets) between the two is considered > > a > >>>>link >>>> up event. >>>> >>>> ==> a physical link is a link which can carry any media. Maybe >>>>you should >>>> reword this slightly -- for example, a host does not know about >>>>availability >>>> of IP (or anything else). Maybe "availability of IP service" is >>>>specific to >>>> some link types which can only carry IP service, not any L3 > > protocol? > >>>Not sure if I understood this. Could you please elaborate a bit > > more? > >>You're making the assumption that once a lower-layer link is up, the >>link can be used to transport IP packets. >> >>What if the link supported only IPX or CLNS packets? What if the link >>supported only IPv4 but not IPv6 packets? As an example of these, >>consider protocol-based Ethernet VLANs. >> >>That said, I'm not sure how much this spec can do about this kind of >>situation. Maybe it could be a bit clearer that it's making a leap of >>faith when associating "link up => IP protocol available" unless the >>link can be known a priori to support IP protocol (e.g., I'd guess if >>you do PPP and also IPCP, you can be pretty sure of that..). > > From dna-owner@webcamserver.eng.monash.edu.au Sun May 1 08:24:34 2005 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 IAA17513 for ; Sun, 1 May 2005 08:24:33 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNRD7X28JE99GC3T@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sun, 01 May 2005 22:24:22 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5C28BAB545; Sun, 01 May 2005 22:24:04 +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 096544FB05; Sun, 01 May 2005 22:24:04 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j41CMr918617 for dna-list; Sun, 01 May 2005 22:22: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 j41CMp618613 for ; Sun, 01 May 2005 22:22:51 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNRD680JRA96YQJ5@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sun, 01 May 2005 22:22:42 +1000 Received: by localhost (Postfix, from userid 510) id 71F6980002; Sun, 01 May 2005 22:22:42 +1000 (EST) Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by larry.its.monash.edu.au (Postfix) with ESMTP id 24A533C004; Sun, 01 May 2005 22:22:37 +1000 (EST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j41CMVO6002295; Sun, 01 May 2005 14:22:31 +0200 Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 01 May 2005 14:22:30 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.13]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 01 May 2005 14:22:30 +0200 Received: from [127.0.0.1] (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8318D18AAA; Sun, 01 May 2005 15:22:29 +0300 (EEST) Date: Sun, 01 May 2005 15:22:25 +0300 From: "Tero Kauppinen (JO/LMF)" Subject: Re: [DNA] RE: Review of link-information from Pekka Savola In-reply-to: <07B14A720C46C344AC96AAA64F5D6A31DA4070@FITMS201MB.tcad.telia.se> Sender: owner-dna@ecselists.eng.monash.edu.au To: jouni.korhonen@teliasonera.com Cc: alper.yegin@samsung.com, Greg.Daley@eng.monash.edu.au, dna@eng.monash.edu.au, pekkas@netcore.fi Message-id: <4274CA01.7070806@ericsson.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 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <07B14A720C46C344AC96AAA64F5D6A31DA4070@FITMS201MB.tcad.telia.se> X-OriginalArrivalTime: 01 May 2005 12:22:30.0465 (UTC) FILETIME=[71D9FB10:01C54E48] Content-Transfer-Encoding: 7BIT jouni.korhonen@teliasonera.com wrote: > Hi, > > Some comments on the 3GPP part of this draft. I think the > text should also mention that the PDP context creation can > be network originated. Also at least since Release-99 it has > been possible to create secondary PDP contexts and more than > one primary PDP context. IMO those should be addresses. > > In the case of secondary PDP context creation the MT has been > configured with a functional IP address (including the IPv6 case). > The IP address of the primary PDP context is assigned to > secondary contexts. > > For additional primary PDP contexts the MT is assigned a new > additional IP address. Thus it is possible to receive link-up > notification while already being able to send/receive IP packets > through existing PDP contexts. Also vice versa for link-down > notifications. > Would it make sense to make each PDP context to look like an interface of its own? /Tero From dna-owner@webcamserver.eng.monash.edu.au Sun May 1 17:41:11 2005 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 RAA18359 for ; Sun, 1 May 2005 17:41:10 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNRWO18ZBE94HPUQ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 02 May 2005 07:41:02 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3038DAB545; Mon, 02 May 2005 07:40: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 E8DFD4FB06; Mon, 02 May 2005 07:40:41 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j41Ldiw22878 for dna-list; Mon, 02 May 2005 07:39: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 j41Ldf622874 for ; Mon, 02 May 2005 07:39:41 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNRWMFW9CQ9AN5HI@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 02 May 2005 07:39:25 +1000 Received: by localhost (Postfix, from userid 510) id 54C6FAB543; Mon, 02 May 2005 07:39:25 +1000 (EST) Received: from ceiling.dave.sonera.fi (ceiling.dave.sonera.fi [131.177.130.26]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2C9814FB06; Mon, 02 May 2005 07:39:22 +1000 (EST) Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id j41LdKdF014760; Mon, 02 May 2005 00:39:20 +0300 (EEST) Received: from FITMS201MB.tcad.telia.se (fitms201cb.tcad.telia.se [131.177.121.204]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id j41LdH24014752; Mon, 02 May 2005 00:39:18 +0300 (EEST) Date: Mon, 02 May 2005 00:39:17 +0300 From: jouni.korhonen@teliasonera.com Subject: RE: [DNA] RE: Review of link-information from Pekka Savola Sender: owner-dna@ecselists.eng.monash.edu.au To: tero.kauppinen@ericsson.com Cc: alper.yegin@samsung.com, Greg.Daley@eng.monash.edu.au, dna@eng.monash.edu.au, pekkas@netcore.fi Message-id: <07B14A720C46C344AC96AAA64F5D6A31DA4078@FITMS201MB.tcad.telia.se> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6617.27 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-Topic: [DNA] RE: Review of link-information from Pekka Savola Thread-Index: AcVOSHnjjbCjblvKS5C9x48yr7Dh5AAS9vcg content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Tero, Making each PDP context look like an interface of its own would probably be ok -- at least for primary contexts. I don't know how that would fit for the secondary contexts, where these secondary contexts share the same IP address of their primary (i.e. the address is known and functional). Cheers, Jouni > -----Original Message----- > From: Tero Kauppinen (JO/LMF) [mailto:tero.kauppinen@ericsson.com] > Sent: 1. toukokuuta 2005 15:22 > To: Korhonen, Jouni /TeliaSonera Finland Oyj > Cc: alper.yegin@samsung.com; Greg.Daley@eng.monash.edu.au; > dna@eng.monash.edu.au; pekkas@netcore.fi > Subject: Re: [DNA] RE: Review of link-information from Pekka Savola > > jouni.korhonen@teliasonera.com wrote: > > Hi, > > > > Some comments on the 3GPP part of this draft. I think the > text should > > also mention that the PDP context creation can be network > originated. > > Also at least since Release-99 it has been possible to create > > secondary PDP contexts and more than one primary PDP context. IMO > > those should be addresses. > > > > In the case of secondary PDP context creation the MT has been > > configured with a functional IP address (including the IPv6 case). > > The IP address of the primary PDP context is assigned to secondary > > contexts. > > > > For additional primary PDP contexts the MT is assigned a new > > additional IP address. Thus it is possible to receive link-up > > notification while already being able to send/receive IP packets > > through existing PDP contexts. Also vice versa for link-down > > notifications. > > > > Would it make sense to make each PDP context to look like an > interface of its own? > > /Tero > From dna-owner@webcamserver.eng.monash.edu.au Mon May 2 00:11:57 2005 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 AAA09186 for ; Mon, 2 May 2005 00:11:56 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNSABT4PB299GEPT@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 02 May 2005 14:11:49 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B0C6880006; Mon, 02 May 2005 14:11:42 +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 66A873C00E; Mon, 02 May 2005 14:11:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j424BB125753 for dna-list; Mon, 02 May 2005 14:11:11 +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 j424BA625749 for ; Mon, 02 May 2005 14:11:10 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNSAAV9XL696YZ98@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 02 May 2005 14:10:57 +1000 Received: by localhost (Postfix, from userid 510) id 14F26AB54A; Mon, 02 May 2005 14:10:57 +1000 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 550E14FB0E; Mon, 02 May 2005 14:10:54 +1000 (EST) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j424AeQ25413; Mon, 02 May 2005 07:10:40 +0300 (EET DST) Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j4247tSs013134; Mon, 02 May 2005 07:07:55 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00lfvZuk; Mon, 02 May 2005 07:07:55 +0100 (EEST) Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j4247sM27837; Mon, 02 May 2005 07:07:54 +0300 (EET DST) Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 02 May 2005 07:07:52 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 02 May 2005 07:07:02 +0300 Date: Mon, 02 May 2005 07:07:02 +0300 From: john.loughney@nokia.com Subject: RE: [DNA] RE: Review of link-information from Pekka Savola Sender: owner-dna@ecselists.eng.monash.edu.au To: jouni.korhonen@teliasonera.com, tero.kauppinen@ericsson.com Cc: alper.yegin@samsung.com, Greg.Daley@eng.monash.edu.au, dna@eng.monash.edu.au, pekkas@netcore.fi Message-id: <1AA39B75171A7144A73216AED1D7478D168663@esebe100.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-Topic: [DNA] RE: Review of link-information from Pekka Savola Thread-Index: AcVOSHnjjbCjblvKS5C9x48yr7Dh5AAS9vcgAA32a/A= Content-class: urn:content-classes:message X-Scanned: Mon, 2 May 2005 07:07:55 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 02 May 2005 04:07:03.0188 (UTC) FILETIME=[656D3D40:01C54ECC] Content-Transfer-Encoding: 7BIT Jouni & Tero, > Making each PDP context look like an interface of its own > would probably > be ok -- at least for primary contexts. I don't know how that > would fit > for the secondary contexts, where these secondary contexts share the > same IP address of their primary (i.e. the address is known and > functional). Some discussion of the relationship of primary & secondary PDP contexts would be good. Basically, they fate-share; so if something is detected on a Primary PDP context, it would also be applicable for any of its Secondary PDP contexts. That applies for Link UP and Link Down. John From dna-owner@webcamserver.eng.monash.edu.au Mon May 2 04:24:29 2005 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 EAA13935 for ; Mon, 2 May 2005 04:24:27 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNSJ4P15YU94HQQR@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 02 May 2005 18:24:12 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CBA3EAB578; Mon, 02 May 2005 18:24:03 +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 8636B4FB0A; Mon, 02 May 2005 18:24:03 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j428NZc27672 for dna-list; Mon, 02 May 2005 18:23:35 +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 j428NX627668 for ; Mon, 02 May 2005 18:23:33 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNSJ41774M9AN701@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 02 May 2005 18:23:32 +1000 Received: by localhost (Postfix, from userid 510) id 019298000F; Mon, 02 May 2005 18:23:31 +1000 (EST) Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by larry.its.monash.edu.au (Postfix) with ESMTP id BB9543C00E; Mon, 02 May 2005 18:23:25 +1000 (EST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j428MqRe014084; Mon, 02 May 2005 10:23:19 +0200 Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 02 May 2005 10:23:13 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 02 May 2005 10:23:12 +0200 Date: Mon, 02 May 2005 10:23:11 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] RE: Review of link-information from Pekka Savola Sender: owner-dna@ecselists.eng.monash.edu.au To: john.loughney@nokia.com, jouni.korhonen@teliasonera.com Cc: alper.yegin@samsung.com, Greg.Daley@eng.monash.edu.au, dna@eng.monash.edu.au, pekkas@netcore.fi Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] RE: Review of link-information from Pekka Savola Thread-Index: AcVOSHnjjbCjblvKS5C9x48yr7Dh5AAS9vcgAA32a/AAB5mUYA== Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 02 May 2005 08:23:12.0895 (UTC) FILETIME=[2E7C68F0:01C54EF0] Content-Transfer-Encoding: 7BIT > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 2. toukokuuta 2005 7:07 > To: jouni.korhonen@teliasonera.com; Tero Kauppinen (JO/LMF) > Cc: alper.yegin@samsung.com; Greg.Daley@eng.monash.edu.au; > dna@eng.monash.edu.au; pekkas@netcore.fi > Subject: RE: [DNA] RE: Review of link-information from Pekka Savola > > Jouni & Tero, > > > Making each PDP context look like an interface of its own > > would probably > > be ok -- at least for primary contexts. I don't know how that > > would fit > > for the secondary contexts, where these secondary contexts share the > > same IP address of their primary (i.e. the address is known and > > functional). > > Some discussion of the relationship of primary & secondary PDP contexts > would be good. Basically, they fate-share; so if something is detected > on a Primary PDP context, it would also be applicable for any of its > Secondary PDP contexts. That applies for Link UP and Link Down. > Jouni & John, Sorry, this doesn't exactly fall under the topic but I just wanted to write it down since we were talking about PDP contexts. Actually while discussing this with Jari Arkko we started to think that running DNA on an interface configuring an address from a PDP context is unnecessary (e.g. a phone. On a laptop with a GPRS card the node still runs pppd.). There is no need to question the address you get from the context. If the address differs from the previous one then it just is different and the node uses it. The situation is different if you are running PPP with your phone (or with a GPRS card) which is using a PDP context to configure the link. We have previously seen (thanks to my foolish mails) that the laptop indeed gets the address from a router advertisement. The laptop doesn't know about the link technology below PPP and can't make any assumptions regarding address changes. In that case DNA is required. > John Tero From dna-owner@webcamserver.eng.monash.edu.au Mon May 2 19:57:59 2005 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 TAA02385 for ; Mon, 2 May 2005 19:57:58 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNTFNYP6WU94HT15@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 03 May 2005 09:56:36 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7A0DBAB544; Tue, 03 May 2005 09: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 225534FB07; Tue, 03 May 2005 09:55:51 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j42NqsX02608 for dna-list; Tue, 03 May 2005 09:52:54 +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 j42Nqr602604 for ; Tue, 03 May 2005 09:52:53 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNTFJZ0GXY9AN77M@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 03 May 2005 09:52:39 +1000 Received: by localhost (Postfix, from userid 510) id B5EA980007; Tue, 03 May 2005 09:52:37 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by larry.its.monash.edu.au (Postfix) with ESMTP id 079333C009; Tue, 03 May 2005 09:52:36 +1000 (EST) 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 <0IFV003DQZNL2C@mailout1.samsung.com>; Tue, 03 May 2005 08:52:33 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IFV00448ZNJDL@mmp2.samsung.com>; Tue, 03 May 2005 08:52:33 +0900 (KST) Date: Mon, 02 May 2005 16:52:00 -0700 From: Alper Yegin Subject: RE: [DNA] RE: Review of link-information from Pekka Savola In-reply-to: <42749A47.8030409@ericsson.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: "'Tero Kauppinen (JO/LMF)'" Cc: "'Pekka Savola'" , "'Greg Daley'" , dna@eng.monash.edu.au Message-id: <024601c54f71$f069c710$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT > > IPv4 vs. IPv6 distinction is harder. Link up would tell "IP is enabled", > > but not necessarily which version of the IP is supported on that link. > > The DNA process that consumes the link up notification would have to > > figure that out. > > Why should DNA be started on an interface that doesn't support IPv6 in > the first place? I meant to say, the host does not know whether there is an IPv6-enabled router on that link or not.... So, it's not a local host configuration, but a network configuration which can only be dynamically discovered (but not necessarily via the link up notification). > Naturally this issue comes valid if a node roams from > an IPv6 network to an IPv4 network (or vice versa). IMHO that's beyond > the scope of DNA. Anyway, what will happen is that the DNA process will > try to confirm whether it's still on the same IPv6 link or not but the > process will fail (i.e. timeout). What the node can of course do is to > run DHCP to get an IPv4 address (in parallel or after the timeout). Sure. Alper > > /Tero > > > > Alper > > > > > > > > > >>>> Node's establishment of a link-layer connection with an > >>> > >>>attachment > >>> > >>>> point that signifies the availability of IP service (i.e., > > > > being > > > >>>>able > >>>> to send and receive IP packets) between the two is considered > > > > a > > > >>>>link > >>>> up event. > >>>> > >>>> ==> a physical link is a link which can carry any media. Maybe > >>>>you should > >>>> reword this slightly -- for example, a host does not know about > >>>>availability > >>>> of IP (or anything else). Maybe "availability of IP service" is > >>>>specific to > >>>> some link types which can only carry IP service, not any L3 > > > > protocol? > > > >>>Not sure if I understood this. Could you please elaborate a bit > > > > more? > > > >>You're making the assumption that once a lower-layer link is up, the > >>link can be used to transport IP packets. > >> > >>What if the link supported only IPX or CLNS packets? What if the link > >>supported only IPv4 but not IPv6 packets? As an example of these, > >>consider protocol-based Ethernet VLANs. > >> > >>That said, I'm not sure how much this spec can do about this kind of > >>situation. Maybe it could be a bit clearer that it's making a leap of > >>faith when associating "link up => IP protocol available" unless the > >>link can be known a priori to support IP protocol (e.g., I'd guess if > >>you do PPP and also IPCP, you can be pretty sure of that..). > > > > > From dna-owner@webcamserver.eng.monash.edu.au Mon May 2 19:58:01 2005 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 TAA02405 for ; Mon, 2 May 2005 19:58:00 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNTFOLXL0O96Z43L@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 03 May 2005 09:56:45 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BCC8CAB54C; Tue, 03 May 2005 09:56: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 644BB4FB08; Tue, 03 May 2005 09:56:22 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j42NuJP02670 for dna-list; Tue, 03 May 2005 09:56:19 +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 j42NuJ602666 for ; Tue, 03 May 2005 09:56:19 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNTFOBC17M96YZCV@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 03 May 2005 09:56:09 +1000 Received: by localhost (Postfix, from userid 510) id 7DAFEAB550; Tue, 03 May 2005 09:56:08 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by curly.its.monash.edu.au (Postfix) with ESMTP id 626C24FB0A; Tue, 03 May 2005 09:56:06 +1000 (EST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IFV006X7ZTGG7@mailout3.samsung.com>; Tue, 03 May 2005 08:56:04 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IFV0042OZTDDM@mmp2.samsung.com>; Tue, 03 May 2005 08:56:04 +0900 (KST) Date: Mon, 02 May 2005 16:55:31 -0700 From: Alper Yegin Subject: RE: [DNA] RE: Review of link-information from Pekka Savola In-reply-to: <1AA39B75171A7144A73216AED1D7478D168663@esebe100.NOE.Nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: john.loughney@nokia.com, jouni.korhonen@teliasonera.com, tero.kauppinen@ericsson.com Cc: Greg.Daley@eng.monash.edu.au, dna@eng.monash.edu.au, pekkas@netcore.fi Message-id: <024701c54f72$6e05d830$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT If the secondary PDP contexts share the same "IP configuration" as the primary one, couldn't we simply just look at the latter one to generate L2 event notifications? Isn't this what matters in the context of DNA? Alper > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Sunday, May 01, 2005 9:07 PM > To: jouni.korhonen@teliasonera.com; tero.kauppinen@ericsson.com > Cc: alper.yegin@samsung.com; Greg.Daley@eng.monash.edu.au; > dna@eng.monash.edu.au; pekkas@netcore.fi > Subject: RE: [DNA] RE: Review of link-information from Pekka Savola > > Jouni & Tero, > > > Making each PDP context look like an interface of its own > > would probably > > be ok -- at least for primary contexts. I don't know how that > > would fit > > for the secondary contexts, where these secondary contexts share the > > same IP address of their primary (i.e. the address is known and > > functional). > > Some discussion of the relationship of primary & secondary PDP contexts > would be good. Basically, they fate-share; so if something is detected > on a Primary PDP context, it would also be applicable for any of its > Secondary PDP contexts. That applies for Link UP and Link Down. > > John From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 02:21:36 2005 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 CAA01972 for ; Tue, 3 May 2005 02:21:35 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNTT4FKBF899GLUW@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 03 May 2005 16:21:05 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 86F0BAB542; Tue, 03 May 2005 16:20:58 +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 378034FB05; Tue, 03 May 2005 16:20:58 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j437m7f00898 for dna-list; Tue, 03 May 2005 17:48:07 +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 j437m6r00894 for ; Tue, 03 May 2005 17:48:06 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNTT38YZ6M99GM95@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 03 May 2005 16:20:01 +1000 Received: by localhost (Postfix, from userid 510) id 658A9AB54A; Tue, 03 May 2005 16:20:01 +1000 (EST) Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by curly.its.monash.edu.au (Postfix) with ESMTP id 93F774FB09; Tue, 03 May 2005 16:19:55 +1000 (EST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j436JoOg009834; Tue, 03 May 2005 08:19:53 +0200 Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 03 May 2005 08:19:33 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 03 May 2005 08:19:33 +0200 Date: Tue, 03 May 2005 08:19:32 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] RE: Review of link-information from Pekka Savola Sender: owner-dna@ecselists.eng.monash.edu.au To: john.loughney@nokia.com, alper.yegin@samsung.com, jouni.korhonen@teliasonera.com Cc: Greg.Daley@eng.monash.edu.au, dna@eng.monash.edu.au, pekkas@netcore.fi Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] RE: Review of link-information from Pekka Savola Thread-Index: AcVPcoIxzhvc2ssFSjqQiS1IulDrJQAK6s9wAACFtcAAASC6MA== Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 03 May 2005 06:19:33.0089 (UTC) FILETIME=[12599D10:01C54FA8] Content-Transfer-Encoding: 7BIT Hi John, > A Linux machine cannot see the PDP context that has been setup by > the phone. If the phone has multiple PDP for applications running > on the phone, those are not available to a laptop, for example. True. Actually I meant that if the node is using a GPRS card, which means that the node runs PPP to the card. If the card has multiple PDP contexts, are those mapped as several PPP connections or are they still within the same PPP connection? Because if they are within the same connection, how does the card know which context to use for an outgoing packet? > > Phones running the Symbian OS have way of handling these multiple > PDP contexts; there are a number of other embedded operator systems > that handle these in a vendor specified manner. > > So, I think we have two cases here: > > 1) Laptop case which uses PPP from the laptop, no open issues here, > I think. > 2) Phone application case: some issues here, I think. > > What I assume we want to do is "detect network attachment" on the links. For > 2G & 3G GPRS, the link is essentially a PDP context. There are two types of > PDP contexts, a Primary PDP Context and a Secondary PDP Context. Secondary > PDP contexts get their IP address from the Primary PDP context. Here I refer to a previous mail of mine where I mentioned the discussion with Jari. The motivation of DNA can also be seen as a way to find an answer to the question: "I was previously using this address, can I still use it on this network too?" On a phone where PDP contexts are not hidden from the application there should not be any reason to ask that question because the node gets an address in the PDP context and then just applies that. If it differs from the previous one, well, then it does. Hmm ... maybe we have to run MobileIPvX on a phone too :) Or am I once again completely lost? Tero From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 03:38:42 2005 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 DAA08688 for ; Tue, 3 May 2005 03:38:39 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNTVSPXMF096ZC1G@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 03 May 2005 17:38:01 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 71AC1AB546; Tue, 03 May 2005 17:37:49 +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 208794FB04; Tue, 03 May 2005 17:37:49 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j437bHi01432 for dna-list; Tue, 03 May 2005 17:37:17 +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 j437bGr01428 for ; Tue, 03 May 2005 17:37:16 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNTRDJOW109AN6WU@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 03 May 2005 15:31:03 +1000 Received: by localhost (Postfix, from userid 510) id 9658CAB544; Tue, 03 May 2005 15:31:03 +1000 (EST) Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by curly.its.monash.edu.au (Postfix) with ESMTP id 508C74FB03; Tue, 03 May 2005 15:30:57 +1000 (EST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j435Uph5005160; Tue, 03 May 2005 07:30:51 +0200 (MEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 03 May 2005 07:30:51 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 03 May 2005 07:30:51 +0200 Date: Tue, 03 May 2005 07:30:50 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] RE: Review of link-information from Pekka Savola Sender: owner-dna@ecselists.eng.monash.edu.au To: Alper Yegin Cc: Pekka Savola , Greg Daley , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] RE: Review of link-information from Pekka Savola Thread-Index: AcVPcgbsU18nBFMrQ0m7AkDYBgV8XwALYBqg Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 03 May 2005 05:30:51.0214 (UTC) FILETIME=[44C6DEE0:01C54FA1] Content-Transfer-Encoding: 7BIT > I meant to say, the host does not know whether there is an IPv6-enabled > router on that link or not.... So, it's not a local host configuration, > but a network configuration which can only be dynamically discovered > (but not necessarily via the link up notification). That's true. I think IPv6 DNA and IPv4 DNA (or whatever it's called -- zeroconf?) should be separate processes both making their own decisions and when a link up notification is received it should be sent to both DNA processes. If IPv6 DNA runs on an interface that is not connected to a network with an IPv6-enabled router, the process will naturally fail in which case hopefully the node will get an IPv4 address. The node can naturally also be connected to a network with both address spaces. /Tero From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 03:39:26 2005 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 DAA08759 for ; Tue, 3 May 2005 03:39:25 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNTVSJRQLA9AN70U@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 03 May 2005 17:37:45 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1A396AB545; Tue, 03 May 2005 17:37: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 BD7C74FB03; Tue, 03 May 2005 17:37:40 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j437bFW01426 for dna-list; Tue, 03 May 2005 17:37:15 +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 j437bEr01420 for ; Tue, 03 May 2005 17:37:14 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNTRITUY8I99GMP5@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 03 May 2005 15:35:19 +1000 Received: by localhost (Postfix, from userid 510) id 223F5AB546; Tue, 03 May 2005 15:35:19 +1000 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 5463D4FB08; Tue, 03 May 2005 15:35:16 +1000 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j435Z2l13537; Tue, 03 May 2005 08:35:02 +0300 (EET DST) Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j435Wa4c015435; Tue, 03 May 2005 08:32:36 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00HveGHx; Tue, 03 May 2005 08:32:36 +0100 (EEST) Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j435WYM01069; Tue, 03 May 2005 08:32:34 +0300 (EET DST) Received: from esebh006.NOE.Nokia.com ([172.21.138.88]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 03 May 2005 08:32:27 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 03 May 2005 08:32:27 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 03 May 2005 08:32:09 +0300 Date: Tue, 03 May 2005 08:32:09 +0300 From: john.loughney@nokia.com Subject: RE: [DNA] RE: Review of link-information from Pekka Savola Sender: owner-dna@ecselists.eng.monash.edu.au To: tero.kauppinen@ericsson.com, alper.yegin@samsung.com, jouni.korhonen@teliasonera.com Cc: Greg.Daley@eng.monash.edu.au, dna@eng.monash.edu.au, pekkas@netcore.fi Message-id: <1AA39B75171A7144A73216AED1D7478D2ED3A7@esebe100.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-Topic: [DNA] RE: Review of link-information from Pekka Savola Thread-Index: AcVPcoIxzhvc2ssFSjqQiS1IulDrJQAK6s9wAACFtcA= Content-class: urn:content-classes:message X-Scanned: Tue, 3 May 2005 08:32:36 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 03 May 2005 05:32:09.0826 (UTC) FILETIME=[73A21C20:01C54FA1] Content-Transfer-Encoding: 7BIT Tero, > How do these PDP contexts look alike from system point of view? On a > phone the application can actually see different PDP contexts and can > choose to use one for signaling and another for some other > purposes but > how do they behave, for example, on a Linux machine? Does each PDP > context map to one PPP connection thus resulting in multiple PPP > connections? A Linux machine cannot see the PDP context that has been setup by the phone. If the phone has multiple PDP for applications running on the phone, those are not available to a laptop, for example. Phones running the Symbian OS have way of handling these multiple PDP contexts; there are a number of other embedded operator systems that handle these in a vendor specified manner. So, I think we have two cases here: 1) Laptop case which uses PPP from the laptop, no open issues here, I think. 2) Phone application case: some issues here, I think. What I assume we want to do is "detect network attachment" on the links. For 2G & 3G GPRS, the link is essentially a PDP context. There are two types of PDP contexts, a Primary PDP Context and a Secondary PDP Context. Secondary PDP contexts get their IP address from the Primary PDP context. I have a general question for the WG, are we focusing on only the initial DNA procedure or are we considering on-going DNA procedures? By way of an example, what I mean is that if you start a 2G GPRS session, you create a primary PDP context, get an IPv6 address, potentially run DNA (maybe not in that order). However, there are many reasons why that PDP context might be interupted. A normal voice call usually will pause the PDP context as most phones don't support concurrent voice and data connections in 2G. After the call ends, you might want to run DNA again, to ensure that you have a network connection. Likewise, if you go through a tunnel, you might lose the network connection, so you probably want to run DNA when you come out of the tunnel. Anyhow, if the above scenarios are of relevance to the WG, I can double check on the correct PDP context terminalogy and references; then supply text. John From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 03:39:27 2005 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 DAA08781 for ; Tue, 3 May 2005 03:39:26 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNTVSVZYKA99GN29@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 03 May 2005 17:37:59 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 82695AB543; Tue, 03 May 2005 17:37:57 +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 426234FB0A; Tue, 03 May 2005 17:37:57 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j437bEt01421 for dna-list; Tue, 03 May 2005 17:37:14 +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 j437bBr01416 for ; Tue, 03 May 2005 17:37:12 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNTQZBHP4Q9AN7W3@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 03 May 2005 15:19:36 +1000 Received: by localhost (Postfix, from userid 510) id CD0D3AB54D; Tue, 03 May 2005 15:19:33 +1000 (EST) Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9CBC54FB05; Tue, 03 May 2005 15:19:25 +1000 (EST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j435JJO6003730; Tue, 03 May 2005 07:19:19 +0200 Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 03 May 2005 07:19:19 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 03 May 2005 07:19:19 +0200 Date: Tue, 03 May 2005 07:19:18 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] RE: Review of link-information from Pekka Savola Sender: owner-dna@ecselists.eng.monash.edu.au To: Alper Yegin , john.loughney@nokia.com, jouni.korhonen@teliasonera.com Cc: Greg.Daley@eng.monash.edu.au, dna@eng.monash.edu.au, pekkas@netcore.fi Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] RE: Review of link-information from Pekka Savola Thread-Index: AcVPcoIxzhvc2ssFSjqQiS1IulDrJQAK6s9w Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 03 May 2005 05:19:19.0518 (UTC) FILETIME=[A87E6FE0:01C54F9F] Content-Transfer-Encoding: 7BIT How do these PDP contexts look alike from system point of view? On a phone the application can actually see different PDP contexts and can choose to use one for signaling and another for some other purposes but how do they behave, for example, on a Linux machine? Does each PDP context map to one PPP connection thus resulting in multiple PPP connections? /Tero > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@samsung.com] > Sent: 3. toukokuuta 2005 2:56 > To: john.loughney@nokia.com; jouni.korhonen@teliasonera.com; Tero Kauppinen > (JO/LMF) > Cc: Greg.Daley@eng.monash.edu.au; dna@eng.monash.edu.au; pekkas@netcore.fi > Subject: RE: [DNA] RE: Review of link-information from Pekka Savola > > If the secondary PDP contexts share the same "IP configuration" as the > primary one, couldn't we simply just look at the latter one to generate > L2 event notifications? Isn't this what matters in the context of DNA? > > Alper > > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Sunday, May 01, 2005 9:07 PM > > To: jouni.korhonen@teliasonera.com; tero.kauppinen@ericsson.com > > Cc: alper.yegin@samsung.com; Greg.Daley@eng.monash.edu.au; > > dna@eng.monash.edu.au; pekkas@netcore.fi > > Subject: RE: [DNA] RE: Review of link-information from Pekka Savola > > > > Jouni & Tero, > > > > > Making each PDP context look like an interface of its own > > > would probably > > > be ok -- at least for primary contexts. I don't know how that > > > would fit > > > for the secondary contexts, where these secondary contexts share the > > > same IP address of their primary (i.e. the address is known and > > > functional). > > > > Some discussion of the relationship of primary & secondary PDP > contexts > > would be good. Basically, they fate-share; so if something is > detected > > on a Primary PDP context, it would also be applicable for any of its > > Secondary PDP contexts. That applies for Link UP and Link Down. > > > > John > From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 04:01:31 2005 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 EAA10653 for ; Tue, 3 May 2005 04:01:30 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNTWMK5YU899GN3Y@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 03 May 2005 18:01:09 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D7477AB545; Tue, 03 May 2005 18:01: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 986B94FB06; Tue, 03 May 2005 18:01:05 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4380uY01700 for dna-list; Tue, 03 May 2005 18:00:56 +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 j4380tr01696 for ; Tue, 03 May 2005 18:00:55 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNTWM0VQ8899GN3Y@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 03 May 2005 18:00:40 +1000 Received: by localhost (Postfix, from userid 510) id 3203980002; Tue, 03 May 2005 18:00:40 +1000 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 36D193C00A; Tue, 03 May 2005 18:00:36 +1000 (EST) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j4380LQ29103; Tue, 03 May 2005 11:00:21 +0300 (EET DST) Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j437t9mf019021; Tue, 03 May 2005 10:55:09 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00Yrr0W7; Tue, 03 May 2005 10:55:00 +0100 (EEST) Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j437snM20952; Tue, 03 May 2005 10:54:49 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 03 May 2005 10:54:31 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 03 May 2005 10:54:30 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 03 May 2005 10:54:17 +0300 Date: Tue, 03 May 2005 10:54:17 +0300 From: john.loughney@nokia.com Subject: RE: [DNA] RE: Review of link-information from Pekka Savola Sender: owner-dna@ecselists.eng.monash.edu.au To: tero.kauppinen@ericsson.com, alper.yegin@samsung.com, jouni.korhonen@teliasonera.com Cc: Greg.Daley@eng.monash.edu.au, dna@eng.monash.edu.au, pekkas@netcore.fi Message-id: <1AA39B75171A7144A73216AED1D7478D2ED3DC@esebe100.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-Topic: [DNA] RE: Review of link-information from Pekka Savola Thread-Index: AcVPcoIxzhvc2ssFSjqQiS1IulDrJQAK6s9wAACFtcAAASC6MAABMAMA Content-class: urn:content-classes:message X-Scanned: Tue, 3 May 2005 10:55:09 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 03 May 2005 07:54:17.0239 (UTC) FILETIME=[4E5E1270:01C54FB5] Content-Transfer-Encoding: 7BIT Hi Tero, > > A Linux machine cannot see the PDP context that has been setup by > > the phone. If the phone has multiple PDP for applications running > > on the phone, those are not available to a laptop, for example. > > True. Actually I meant that if the node is using a GPRS card, which > means that the node runs PPP to the card. If the card has multiple PDP > contexts, are those mapped as several PPP connections or are they still > within the same PPP connection? Because if they are within the same > connection, how does the card know which context to use for an outgoing > packet? That sounds like a driver issue. I haven't played with GPRS cards that support multiple PDP contexts. > > Phones running the Symbian OS have way of handling these multiple > > PDP contexts; there are a number of other embedded operator systems > > that handle these in a vendor specified manner. > > > > So, I think we have two cases here: > > > > 1) Laptop case which uses PPP from the laptop, no open issues here, > > I think. > > 2) Phone application case: some issues here, I think. > > > > What I assume we want to do is "detect network attachment" on the links. For > > 2G & 3G GPRS, the link is essentially a PDP context. There are two types of > > PDP contexts, a Primary PDP Context and a Secondary PDP Context.Secondary > > PDP contexts get their IP address from the Primary PDP context. > > Here I refer to a previous mail of mine where I mentioned the discussion > with Jari. The motivation of DNA can also be seen as a way to find an > answer to the question: "I was previously using this address, can I > still use it on this network too?" On a phone where PDP contexts are not > hidden from the application there should not be any reason to ask that > question because the node gets an address in the PDP context and then > just applies that. If it differs from the previous one, well, then it > does. Hmm ... maybe we have to run MobileIPvX on a phone too :) PDP Contexts can have the following state: 1) Active - resources & IP address allocated, traffic flow possible 2) Suspended - resources & IP address allocated, traffic suspended 3) inactive - no resources & no IP address allocate However, even with an active PDP context, it is possible that the link isn't active; for example if the GGSN goes down, then UE might still be in the PDP Context active state but there are no resources available. To repeat your question: > The motivation of DNA can also be seen as a way to find an > answer to the question: "I was previously using this address, can I > still use it on this network too?" You would need to re-run DNA everytime the PDP context state is changed, in my opinion. John From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 04:06:02 2005 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 EAA11223 for ; Tue, 3 May 2005 04:06:01 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNTWRLFFOK96ZA5Z@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 03 May 2005 18:05:42 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5CCAEAB54A; Tue, 03 May 2005 18:05: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 1DA9C4FB05; Tue, 03 May 2005 18:05:09 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j43856O01797 for dna-list; Tue, 03 May 2005 18:05:06 +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 j43855r01788 for ; Tue, 03 May 2005 18:05:05 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNTWRBHRVY94I2G7@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 03 May 2005 18:04:56 +1000 Received: by localhost (Postfix, from userid 510) id 588B480002; Tue, 03 May 2005 18:04:56 +1000 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id A9C1E3C003; Tue, 03 May 2005 18:04:53 +1000 (EST) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j4384gM28912; Tue, 03 May 2005 11:04:42 +0300 (EET DST) Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j437xC8D004051; Tue, 03 May 2005 10:59:12 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00jIr7On; Tue, 03 May 2005 10:59:11 +0100 (EEST) Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j437x4M26015; Tue, 03 May 2005 10:59:05 +0300 (EET DST) Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 03 May 2005 10:58:35 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 03 May 2005 10:58:27 +0300 Date: Tue, 03 May 2005 10:58:27 +0300 From: john.loughney@nokia.com Subject: RE: [DNA] RE: Review of link-information from Pekka Savola Sender: owner-dna@ecselists.eng.monash.edu.au To: tero.kauppinen@ericsson.com, alper.yegin@samsung.com, jouni.korhonen@teliasonera.com Cc: Greg.Daley@eng.monash.edu.au, dna@eng.monash.edu.au, pekkas@netcore.fi Message-id: <1AA39B75171A7144A73216AED1D7478D2ED3E9@esebe100.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-Topic: [DNA] RE: Review of link-information from Pekka Savola Thread-Index: AcVPcoIxzhvc2ssFSjqQiS1IulDrJQAK6s9wAAXZvnA= Content-class: urn:content-classes:message X-Scanned: Tue, 3 May 2005 10:59:12 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 03 May 2005 07:58:27.0887 (UTC) FILETIME=[E3C3EBF0:01C54FB5] Content-Transfer-Encoding: 7BIT > How do these PDP contexts look alike from system point of view? On a > phone the application can actually see different PDP contexts and can > choose to use one for signaling and another for some other purposes but > how do they behave, for example, on a Linux machine? Does each PDP > context map to one PPP connection thus resulting in multiple PPP > connections? I don't know of any GPRS cards that are currently supporting multiple PDP contexts. If there were, I'd assume that each PPP connection would be a primary PDP context, so that their would be no correlation between any of them; each would have seperate IP addresses. John From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 04:23:55 2005 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 EAA12962 for ; Tue, 3 May 2005 04:23:53 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNTXDU6XOK99GJ12@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 03 May 2005 18:23:15 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7B51980003; Tue, 03 May 2005 18:23:05 +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 32D6A3C003; Tue, 03 May 2005 18:23:05 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j438Mpt02036 for dna-list; Tue, 03 May 2005 18:22:51 +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 j438Mor02032 for ; Tue, 03 May 2005 18:22:50 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNTXDB1QMI94HYKN@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 03 May 2005 18:22:40 +1000 Received: by localhost (Postfix, from userid 510) id E32D9AB542; Tue, 03 May 2005 18:22:39 +1000 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 0C8134FB04; Tue, 03 May 2005 18:22:36 +1000 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j438MSQ03457; Tue, 03 May 2005 11:22:28 +0300 (EET DST) Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j438G4Vi024498; Tue, 03 May 2005 11:16:04 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00O7mpPR; Tue, 03 May 2005 11:16:02 +0100 (EEST) Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j4385HM03252; Tue, 03 May 2005 11:05:18 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 03 May 2005 11:05:12 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 03 May 2005 11:05:11 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 03 May 2005 11:05:11 +0300 Date: Tue, 03 May 2005 11:05:12 +0300 From: john.loughney@nokia.com Subject: RE: [DNA] RE: Review of link-information from Pekka Savola Sender: owner-dna@ecselists.eng.monash.edu.au To: alper.yegin@samsung.com, jouni.korhonen@teliasonera.com, tero.kauppinen@ericsson.com Cc: Greg.Daley@eng.monash.edu.au, dna@eng.monash.edu.au, pekkas@netcore.fi Message-id: <1AA39B75171A7144A73216AED1D7478D2ED3F0@esebe100.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-Topic: [DNA] RE: Review of link-information from Pekka Savola Thread-Index: AcVPcphEJcVc+7iwSS6YayoQ07XejQAQ2hJQ Content-class: urn:content-classes:message X-Scanned: Tue, 3 May 2005 11:16:04 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 03 May 2005 08:05:11.0545 (UTC) FILETIME=[D45D3E90:01C54FB6] Content-Transfer-Encoding: 7BIT Alper, > If the secondary PDP contexts share the same "IP configuration" as the > primary one, couldn't we simply just look at the latter one to generate > L2 event notifications? Isn't this what matters in the context of DNA? I think that would be sufficient. Since secondary PDP contexts fate share with the Primary PDP context that they belong to, sharing L2 event notifications is fine. One slight twist is that Secondary PDP contexts can still exist after a Primary PDP context is removed; all the IP config data still remains valid. John > > Alper > > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Sunday, May 01, 2005 9:07 PM > > To: jouni.korhonen@teliasonera.com; tero.kauppinen@ericsson.com > > Cc: alper.yegin@samsung.com; Greg.Daley@eng.monash.edu.au; > > dna@eng.monash.edu.au; pekkas@netcore.fi > > Subject: RE: [DNA] RE: Review of link-information from Pekka Savola > > > > Jouni & Tero, > > > > > Making each PDP context look like an interface of its own > > > would probably > > > be ok -- at least for primary contexts. I don't know how that > > > would fit > > > for the secondary contexts, where these secondary > contexts share the > > > same IP address of their primary (i.e. the address is known and > > > functional). > > > > Some discussion of the relationship of primary & secondary PDP > contexts > > would be good. Basically, they fate-share; so if something is > detected > > on a Primary PDP context, it would also be applicable for any of its > > Secondary PDP contexts. That applies for Link UP and Link Down. > > > > John > > > From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 04:25:22 2005 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 EAA13048 for ; Tue, 3 May 2005 04:25:20 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNTXFZV3FG96ZCMY@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 03 May 2005 18:25:01 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D656EAB546; Tue, 03 May 2005 18:24:49 +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 8DAEF4FB02; Tue, 03 May 2005 18:24:48 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j438OiJ02088 for dna-list; Tue, 03 May 2005 18:24: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 j438Ohr02083 for ; Tue, 03 May 2005 18:24:43 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNTXFKPUMI9AN722@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 03 May 2005 18:24:30 +1000 Received: by localhost (Postfix, from userid 510) id 9BD29AB54B; Tue, 03 May 2005 18:24:29 +1000 (EST) Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by curly.its.monash.edu.au (Postfix) with ESMTP id 823CD4FB02; Tue, 03 May 2005 18:24:24 +1000 (EST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j438N9jO002751; Tue, 03 May 2005 10:24:22 +0200 (MEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 03 May 2005 10:24:13 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 03 May 2005 10:24:13 +0200 Date: Tue, 03 May 2005 10:24:12 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] RE: Review of link-information from Pekka Savola Sender: owner-dna@ecselists.eng.monash.edu.au To: john.loughney@nokia.com, alper.yegin@samsung.com, jouni.korhonen@teliasonera.com Cc: Greg.Daley@eng.monash.edu.au, dna@eng.monash.edu.au, pekkas@netcore.fi Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] RE: Review of link-information from Pekka Savola Thread-Index: AcVPcoIxzhvc2ssFSjqQiS1IulDrJQAK6s9wAACFtcAAASC6MAABMAMAAANHS9A= Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 03 May 2005 08:24:13.0421 (UTC) FILETIME=[7CF9B1D0:01C54FB9] Content-Transfer-Encoding: 7BIT > However, even with an active PDP context, it is possible that the link isn't > active; for example if the GGSN goes down, then UE might still be in the > PDP Context active state but there are no resources available. > > To repeat your question: > > > The motivation of DNA can also be seen as a way to find an > > answer to the question: "I was previously using this address, can I > > still use it on this network too?" > > You would need to re-run DNA everytime the PDP context state is changed, in > my opinion. What would the node gain by running DNA every time the PDP context state changes? Would DNA be used to detect if the link is useable in this case? I'm just trying to understand the motivation. Tero From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 04:30:31 2005 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 EAA13422 for ; Tue, 3 May 2005 04:30:30 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNTXMAGPHK9AMUM5@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 03 May 2005 18:30:01 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6020380006; Tue, 03 May 2005 18:29:54 +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 1C09A3C005; Tue, 03 May 2005 18:29:54 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j438TnC02247 for dna-list; Tue, 03 May 2005 18:29:49 +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 j438Tnr02243 for ; Tue, 03 May 2005 18:29:49 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNTXM40JJ09AMUM5@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 03 May 2005 18:29:45 +1000 Received: by localhost (Postfix, from userid 510) id D068BAB543; Tue, 03 May 2005 18:29:45 +1000 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by curly.its.monash.edu.au (Postfix) with ESMTP id 3716B4FB02 for ; Tue, 03 May 2005 18:29:44 +1000 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8A1DB89844; Tue, 03 May 2005 11:29:40 +0300 (EEST) Date: Tue, 03 May 2005 11:29:45 +0300 From: Jari Arkko Subject: Re: [DNA] RE: Review of link-information from Pekka Savola In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" Cc: dna@eng.monash.edu.au Message-id: <42773679.2070804@kolumbus.fi> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: Content-Transfer-Encoding: 7BIT Tero, >I think IPv6 DNA and IPv4 DNA (or whatever it's called -- zeroconf?) >should be separate processes both making their own decisions and when a >link up notification is received it should be sent to both DNA >processes. If IPv6 DNA runs on an interface that is not connected to a >network with an IPv6-enabled router, the process will naturally fail in >which case hopefully the node will get an IPv4 address. The node can >naturally also be connected to a network with both address spaces. > > I tend to agree with this. There are two possible ways to look at this, either you have a synchronized procedure or you simply do both. Considering that IPv4 DNA appears to be using different sets of messages, it makes more sense, imho, to keep the processes completely separate as there does not seem to be any optimization gains in sight. And yes, IPv6 DNA can fail and then you don't have IPv6 connectivity on that link. (I hope all the DNA documents explicitly talk about this case and how to deal with it. Knowing that you have no connectivity can be as important as knowing you have moved.) --Jari From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 04:45:41 2005 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 EAA14794 for ; Tue, 3 May 2005 04:45:40 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNTY6JZ8FQ99GJHU@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 03 May 2005 18:45:30 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A1C9680006; Tue, 03 May 2005 18:45:27 +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 518E53C007; Tue, 03 May 2005 18:45:27 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j438j5R02421 for dna-list; Tue, 03 May 2005 18:45:05 +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 j438j4r02415 for ; Tue, 03 May 2005 18:45:04 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNTY5R1LAQ99GN8A@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 03 May 2005 18:44:49 +1000 Received: by localhost (Postfix, from userid 510) id F0BA4AB543; Tue, 03 May 2005 18:44:48 +1000 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by curly.its.monash.edu.au (Postfix) with ESMTP id E81AD4FB02 for ; Tue, 03 May 2005 18:44:46 +1000 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 81A9D89844; Tue, 03 May 2005 11:44:45 +0300 (EEST) Date: Tue, 03 May 2005 11:44:50 +0300 From: Jari Arkko Subject: Re: [DNA] RE: Review of link-information from Pekka Savola In-reply-to: <1AA39B75171A7144A73216AED1D7478D2ED3DC@esebe100.NOE.Nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: john.loughney@nokia.com Cc: tero.kauppinen@ericsson.com, dna@eng.monash.edu.au Message-id: <42773A02.7070700@kolumbus.fi> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <1AA39B75171A7144A73216AED1D7478D2ED3DC@esebe100.NOE.Nokia.com> Content-Transfer-Encoding: 7BIT Hi John, >PDP Contexts can have the following state: >1) Active - resources & IP address allocated, traffic flow possible >2) Suspended - resources & IP address allocated, traffic suspended >3) inactive - no resources & no IP address allocate > >However, even with an active PDP context, it is possible that the link isn't >active; for example if the GGSN goes down, then UE might still be in the >PDP Context active state but there are no resources available. > > But isn't IPv6 NUD the right protocol to use when ensuring that you still have connectivity to the GGSN? At least that's what we wrote in RFC 3316... >>The motivation of DNA can also be seen as a way to find an >>answer to the question: "I was previously using this address, can I >>still use it on this network too?" >> >> > >You would need to re-run DNA everytime the PDP context state is changed, in >my opinion. > > The way that I see this is that the point of DNA is to detect changes in (a) prefixes that affect the host's addresses, and (b) routers that the host uses as default routers. Now, when you are on a point-to-point link such as PDP context or PPP, there isn't much use for part b, so we are primarily interested in part a. My understanding of the PDP context procedure is that in the establishment procedure (that runs on lower layers) you get a prefix that is unique to you. Furthermore, as specified in RFC 3316 there are some rules that prevent the same interface ID from being assigned on the same link; that's why DupAddrDetectTransmits can be set to zero. My understanding is also that the 3GPP specifications require the network to never change the prefixes on a live PDP context (or if they are changed, the context needs to be shut down first). As a result, I have trouble seeing why we'd need to run DNA on a phone that is connected to a GSM/UMTS network via a PDP context. NUD yes. L2 signaling to set up yes. But no DNA. Or am I missing something? (On a laptop connected over PPP this is a different matter. The laptop has no knowledge of what the L2 really is at the other end.) --Jari From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 05:53:52 2005 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 FAA25516 for ; Tue, 3 May 2005 05:53:50 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNU0K3NSRO9AN73Z@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 03 May 2005 19:53:42 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F02A0AB545; Tue, 03 May 2005 19:53:38 +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 AB0DF4FB04; Tue, 03 May 2005 19:53:38 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j439rCL02977 for dna-list; Tue, 03 May 2005 19:53: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 j439rBr02973 for ; Tue, 03 May 2005 19:53:11 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNU0JFBLC694HUGW@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 03 May 2005 19:53:06 +1000 Received: by localhost (Postfix, from userid 510) id 6812AAB542; Tue, 03 May 2005 19:53:06 +1000 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id ED09B4FB06 for ; Tue, 03 May 2005 19:53:02 +1000 (EST) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j439qvl04320; Tue, 03 May 2005 12:52:57 +0300 (EET DST) Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j439pmwN012364; Tue, 03 May 2005 12:51:48 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00RmOW5j; Tue, 03 May 2005 12:51:46 +0100 (EEST) Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j439pgM04707; Tue, 03 May 2005 12:51:42 +0300 (EET DST) Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 03 May 2005 12:51:33 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 03 May 2005 12:51:32 +0300 Date: Tue, 03 May 2005 12:51:33 +0300 From: john.loughney@nokia.com Subject: RE: [DNA] RE: Review of link-information from Pekka Savola Sender: owner-dna@ecselists.eng.monash.edu.au To: jari.arkko@kolumbus.fi Cc: tero.kauppinen@ericsson.com, dna@eng.monash.edu.au Message-id: <1AA39B75171A7144A73216AED1D7478D2ED434@esebe100.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-Topic: [DNA] RE: Review of link-information from Pekka Savola Thread-Index: AcVPvJnzJY+iuSbvSvWZLyI84ZHifgACOIIQ Content-class: urn:content-classes:message X-Scanned: Tue, 3 May 2005 12:51:48 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 03 May 2005 09:51:32.0513 (UTC) FILETIME=[AFB7B110:01C54FC5] Content-Transfer-Encoding: 7BIT Hi Jari, > >However, even with an active PDP context, it is possible > that the link isn't > >active; for example if the GGSN goes down, then UE might > still be in the > >PDP Context active state but there are no resources available. > > > > > But isn't IPv6 NUD the right protocol to use when ensuring > that you still have connectivity to the GGSN? At least that's > what we wrote in RFC 3316... You are correct. > >You would need to re-run DNA everytime the PDP context state > is changed, in > >my opinion. > > > > > The way that I see this is that the point of DNA is to detect > changes in (a) prefixes that affect the host's addresses, and > (b) routers that the host uses as default routers. > > Now, when you are on a point-to-point link such as PDP context > or PPP, there isn't much use for part b, so we are primarily interested > in part a. > > My understanding of the PDP context procedure is that in > the establishment procedure (that runs on lower layers) you > get a prefix that is unique to you. Furthermore, as specified > in RFC 3316 there are some rules that prevent the same > interface ID from being assigned on the same link; that's > why DupAddrDetectTransmits can be set to zero. > > My understanding is also that the 3GPP specifications > require the network to never change the prefixes on > a live PDP context (or if they are changed, the context > needs to be shut down first). > > As a result, I have trouble seeing why we'd need to run > DNA on a phone that is connected to a GSM/UMTS network > via a PDP context. NUD yes. L2 signaling to set up yes. > But no DNA. Or am I missing something? Actually, I think your analysis is correct. NUD is sufficient here. > (On a laptop connected over PPP this is a different matter. > The laptop has no knowledge of what the L2 really is at the > other end.) Correct, just PPP knowledge. John From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 09:34:10 2005 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 JAA16986 for ; Tue, 3 May 2005 09:34:08 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNU891AR9A9AN79F@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 03 May 2005 23:33:51 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 94D3BAB543; Tue, 03 May 2005 23:33: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 5696A4FB07; Tue, 03 May 2005 23:33:47 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j43DX8C04623 for dna-list; Tue, 03 May 2005 23:33:08 +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 j43DX6r04619 for ; Tue, 03 May 2005 23:33:06 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNU882EZWQ96ZEET@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 03 May 2005 23:33:01 +1000 Received: by localhost (Postfix, from userid 510) id E102180003; Tue, 03 May 2005 23:33:00 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (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 30E193C009; Tue, 03 May 2005 23:32:59 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1DSxWA-00024S-Dy; Tue, 03 May 2005 09:32:54 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j43DT9618858; Tue, 03 May 2005 06:32:51 -0700 Date: Tue, 03 May 2005 06:29:09 -0700 (PDT) From: Bernard Aboba Subject: RE: [DNA] RE: Review of link-information from Pekka Savola In-reply-to: X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" Cc: john.loughney@nokia.com, alper.yegin@samsung.com, jouni.korhonen@teliasonera.com, Greg.Daley@eng.monash.edu.au, dna@eng.monash.edu.au, pekkas@netcore.fi Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: Content-Transfer-Encoding: 7BIT > Here I refer to a previous mail of mine where I mentioned the discussion > with Jari. The motivation of DNA can also be seen as a way to find an > answer to the question: "I was previously using this address, can I > still use it on this network too?" On a phone where PDP contexts are not > hidden from the application there should not be any reason to ask that > question because the node gets an address in the PDP context and then > just applies that. If it differs from the previous one, well, then it > does. Hmm ... maybe we have to run MobileIPvX on a phone too :) > > Or am I once again completely lost? I think you are correct. In the DNAv4 document it explicitly states that DNAv4 is only for use with media that support ARP, for that reason. From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 13:21:46 2005 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 NAA12057 for ; Tue, 3 May 2005 13:21:45 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNUG779HNS9AN7EX@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 04 May 2005 03:21:26 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C730F80004; Wed, 04 May 2005 03:21:22 +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 8555D3C00B; Wed, 04 May 2005 03:21:22 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j43HKpw06658 for dna-list; Wed, 04 May 2005 03:20:51 +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 j43HKnr06654 for ; Wed, 04 May 2005 03:20:49 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNUG6D43BO94HYG5@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 04 May 2005 03:20:42 +1000 Received: by localhost (Postfix, from userid 510) id 69D5EAB542; Wed, 04 May 2005 03:20:42 +1000 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by curly.its.monash.edu.au (Postfix) with ESMTP id 5AB0F4FB08; Wed, 04 May 2005 03:20:40 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.226.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j43HKcjO017502; Tue, 03 May 2005 11:20:39 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j43HKYdH127633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 03 May 2005 10:20:34 -0700 (PDT) Date: Tue, 03 May 2005 10:20:38 -0700 From: Erik Nordmark Subject: Re: [DNA] RE: Review of link-information from Pekka Savola In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" Cc: Alper Yegin , Pekka Savola , Greg Daley , dna@eng.monash.edu.au Message-id: <4277B2E6.8090008@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 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: Content-Transfer-Encoding: 7BIT Tero Kauppinen (JO/LMF) wrote: > I think IPv6 DNA and IPv4 DNA (or whatever it's called -- zeroconf?) draft-ietf-dhc-dna-ipv4-11.txt > should be separate processes both making their own decisions and when a > link up notification is received it should be sent to both DNA > processes. If IPv6 DNA runs on an interface that is not connected to a > network with an IPv6-enabled router, the process will naturally fail in > which case hopefully the node will get an IPv4 address. The node can > naturally also be connected to a network with both address spaces. I haven't thought much about the dual-stack host doing DNA. Given that DNAv4 relies on DHCP and DNA for IPv6 handles stateless address autoconfig, it seems easiest to pass the 'link up' notifications to each of them independently. That would work, albeit a bit ineffecient when the IPv4 links are congruent with the IPv6 links (i.e., if you stay on the same link as before for IPvX you also do that for IPvY. Likewise if you move for one, you move for the other.) Jari suggested that we should be able to detect when a host moves from a dual link to one which only supports one version of IP, and disable the IP protocol which isn't available. This seems a bit scarier to me. While we want DNA to operate efficiently and quickly, so that it can find a new working address and trigger Mobile IP style signaling when it has moved, the act of turning off IPvX is a lot more disruptive; unconfiguring all the IPvX addresses and blowing away all the connections that used them can't easily be undone. And it might be that the host moved to a link with no IPvX support for just a few seconds, and then moves back to a link where IPvX is available. Perhaps there are anaogous cases for a single IP version when there is no mobility signaling protocol used on top; in that case it might make sense to keep the old connections around, just in case the host will move back to the old link a few seconds later. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 14:05:07 2005 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 OAA16412 for ; Tue, 3 May 2005 14:05:06 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNUHP9EAAM9AN882@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 04 May 2005 04:04:59 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C0D8780004; Wed, 04 May 2005 04:04:57 +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 ED0693C003; Wed, 04 May 2005 04:04:56 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j43I4eh07207 for dna-list; Wed, 04 May 2005 04:04:40 +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 j43I4cr07203 for ; Wed, 04 May 2005 04:04:38 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNUHOPUZ4299GNJT@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 04 May 2005 04:04:31 +1000 Received: by localhost (Postfix, from userid 510) id AB875AB542; Wed, 04 May 2005 04:04:31 +1000 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9958F4FB05 for ; Wed, 04 May 2005 04:04:29 +1000 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id BF48F89879; Tue, 03 May 2005 21:04:26 +0300 (EEST) Date: Tue, 03 May 2005 21:04:32 +0300 From: Jari Arkko Subject: Re: [DNA] RE: Review of link-information from Pekka Savola In-reply-to: <4277B2E6.8090008@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: dna@eng.monash.edu.au Message-id: <4277BD30.7080702@kolumbus.fi> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <4277B2E6.8090008@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, > I haven't thought much about the dual-stack host doing DNA. > > Given that DNAv4 relies on DHCP and DNA for IPv6 handles stateless > address autoconfig, it seems easiest to pass the 'link up' > notifications to each of them independently. That would work, albeit a > bit ineffecient when the IPv4 links are congruent with the IPv6 links > (i.e., if you stay on the same link as before for IPvX you also do > that for IPvY. Likewise if you move for one, you move for the other.) Hmm... perhaps there are optimization gains available after all. I was thinking mainly of the initial case of a new link, this seems to need a parallel process on both IP versions, since different mechanisms are used. But on subsequent hints that say "we may have moved", the fact that IPv4 DNA says we have NOT moved might be taken as an indication that we don't need to do the IPv6 DNA process. On the other hand, if it turns out you have moved, then you may have lost some time as you could have already sent the RS. > Jari suggested that we should be able to detect when a host moves from > a dual link to one which only supports one version of IP, and disable > the IP protocol which isn't available. > This seems a bit scarier to me. While we want DNA to operate > efficiently and quickly, so that it can find a new working address and > trigger Mobile IP style signaling when it has moved, the act of > turning off IPvX is a lot more disruptive; unconfiguring all the IPvX > addresses and blowing away all the connections that used them can't > easily be undone. I admit it sounds scarier. But I didn't actually intend to turn off IPv6 altogether if you hit a link that doesn't appear to be doing v6. Just v6 on that link! The situation is similar to detecting a "link down" on an interface. If you have other interfaces, you keep on using them. (Or you turn on your other interfaces because of this; this is one of the reasons why you'd want to know you have no IPvx service.) If you do not have any other interfaces, you hold on to your session state and addresses for a while, in case things change for the better. Finally, home addresses and sessions on top of them should survive in any case. (Observation: all this seems more complicated than I thought at first sight. Probably time to write this up somewhere, if not yet done.) --Jari From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 16:48:20 2005 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 QAA11154 for ; Tue, 3 May 2005 16:48:19 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNUNEAQ1FK9AN8HN@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 04 May 2005 06:48:00 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AB0AE80002; Wed, 04 May 2005 06:47:54 +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 5CBA53C00B; Wed, 04 May 2005 06:47:54 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j43KknP08539 for dna-list; Wed, 04 May 2005 06:46:49 +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 j43Kkbr08535 for ; Wed, 04 May 2005 06:46:38 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNUNCMEP6294HPY9@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 04 May 2005 06:46:34 +1000 Received: by localhost (Postfix, from userid 510) id 75B01AB542; Wed, 04 May 2005 06:46:34 +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 AD9424FB04 for ; Wed, 04 May 2005 06:46:32 +1000 (EST) Received: from redwood.research.panasonic.com (birch.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j43KkV5v000386 for ; Tue, 03 May 2005 16:46:31 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 7F7C91E8188 for ; Tue, 03 May 2005 16:38:54 -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 68A6A1E8170for ; Tue, 03 May 2005 16:38:54 -0400 (EDT) Date: Tue, 03 May 2005 16:46:21 -0400 From: Sathya Narayanan Subject: [DNA] DNA Design team solution draft Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <4277E31D.7080308@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 User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:5.08151 C:17 M:1 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.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Dear WG - The design team submitted a solution draft today. It should appear in the internet-draft directory soon. Meanwhile, the draft can be found at http://www.ctie.monash.edu.au/dna-dt/draft-dnadt-dna-protocol-00.txt Please read the document and provide comments. thanks & regards, Sathya for The Design Team. From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 17:16:06 2005 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 RAA13019 for ; Tue, 3 May 2005 17:16:05 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNUOE25NV89AN7PR@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 04 May 2005 07:16:01 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 60222AB545; Wed, 04 May 2005 07:15:58 +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 1E2E04FB06; Wed, 04 May 2005 07:15:58 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j43LFiM08888 for dna-list; Wed, 04 May 2005 07:15: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 j43LFfr08884 for ; Wed, 04 May 2005 07:15:41 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNUODDVLEA9AN7PR@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 04 May 2005 07:15:26 +1000 Received: by localhost (Postfix, from userid 510) id ED3A2AB543; Wed, 04 May 2005 07:15:25 +1000 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by curly.its.monash.edu.au (Postfix) with ESMTP id 3F5F44FB05 for ; Wed, 04 May 2005 07:15:24 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.226.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j43LFNQ1014159; Tue, 03 May 2005 14:15:23 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j43LFLmV261324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 03 May 2005 14:15:22 -0700 (PDT) Date: Tue, 03 May 2005 14:15:26 -0700 From: Erik Nordmark Subject: Re: [DNA] RE: Review of link-information from Pekka Savola In-reply-to: <4277BD30.7080702@kolumbus.fi> Sender: owner-dna@ecselists.eng.monash.edu.au To: Jari Arkko Cc: dna@eng.monash.edu.au Message-id: <4277E9EE.4010400@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 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <4277B2E6.8090008@sun.com> <4277BD30.7080702@kolumbus.fi> Content-Transfer-Encoding: 7BIT Jari Arkko wrote: > Hmm... perhaps there are optimization gains available after all. > I was thinking mainly of the initial case of a new link, this seems > to need a parallel process on both IP versions, since different > mechanisms are used. But on subsequent hints that say "we may > have moved", the fact that IPv4 DNA says we have NOT moved > might be taken as an indication that we don't need to do the IPv6 > DNA process. Of course the IPv6 DNA process will be faster than the IPv4 one, so you got this one backwards :-) > On the other hand, if it turns out you have moved, then you may have > lost some time as you could have already sent the RS. Good point. > I admit it sounds scarier. But I didn't actually intend to turn off > IPv6 altogether if you hit a link that doesn't appear to be doing v6. > Just v6 on that link! The situation is similar to detecting a "link > down" on > an interface. If you have other interfaces, you keep on using them. > (Or you turn on your other interfaces because of this; this is one > of the reasons why you'd want to know you have no IPvx service.) > If you do not have any other interfaces, you hold on to your session > state and addresses for a while, in case things change for the > better. But the tradeoffs are tricky, because it depends on interactions between the inability to predict whether the host is going to move again, and the behavior of the application/user. For example, assume no mobility protocol on top and a single IP version being used. When the host detects that an interface has moved to a new link then, if this is more or less permanent, it makes sense to immediately tell the applications that there connections are gone, so that the applications (or user) can attempt to reestablish communication, which will automatically prefer the IP addresses for the new link. But, if there is some probability of soon moving back to the old link, it might make sense to not tell the applications that their connections are dead, since, should the move back happen before the transport protocol, application, or user gives up, things would just start working again after the move back. However, if the transport protocol, application, or user have timeliness constraints, even if there is a chance of moving back to the old link, it makes sense to tell such applications that things are dead and they should reestablish communication. > Finally, home addresses and sessions on top of them should > survive in any case. Agreed. When we have something like MIP which can repair things on top, then we don't have to get into understanding the desired behavior from the applications' and user' perspective. > (Observation: all this seems more complicated than I thought at > first sight. Probably time to write this up somewhere, if not yet > done.) I'm not aware of anybody that has started to write this down. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 20:56:30 2005 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 UAA28083 for ; Tue, 3 May 2005 20:56:27 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNUW2EWX8096ZHH1@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 04 May 2005 10:55:56 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EC42680008; Wed, 04 May 2005 10:55:38 +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 815C63C00D; Wed, 04 May 2005 10:55:38 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j440r7F10677 for dna-list; Wed, 04 May 2005 10:53:07 +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 j440r7r10673 for ; Wed, 04 May 2005 10:53:07 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNUVXZ8P0C96ZJTL@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 04 May 2005 10:52:52 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 49AF880003; Wed, 04 May 2005 10:52:51 +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 208863C00B; Wed, 04 May 2005 10:52:51 +1000 (EST) Date: Wed, 04 May 2005 10:52:45 +1000 From: Greg Daley Subject: [DNA] draft-ietf-dna-hosts-00.txt typo in section 5.1 Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42781CDD.5060507@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 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Hi Sathya, Just a quick erratum In section 5.1, I think that the first sentence should read: Upon reception of a hint that link change may have... instead of: Upon reception of a hint that link change detection may have... I don't know what I was thinking there. Greg. From dna-owner@webcamserver.eng.monash.edu.au Tue May 3 21:05:55 2005 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 VAA28725 for ; Tue, 3 May 2005 21:05:54 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNUWECNPIC96ZKOG@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 04 May 2005 11:05:46 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 566F5AB545; Wed, 04 May 2005 11:05:16 +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 F19544FB08; Wed, 04 May 2005 11:05:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j44159g10824 for dna-list; Wed, 04 May 2005 11:05:09 +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 j44157r10820 for ; Wed, 04 May 2005 11:05:07 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNUWE0EVJI94I84R@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 04 May 2005 11:05:04 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0E20B80002; Wed, 04 May 2005 11:05:00 +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 DEC443C009; Wed, 04 May 2005 11:04:59 +1000 (EST) Date: Wed, 04 May 2005 11:04:54 +1000 From: Greg Daley Subject: Re: [DNA] RE: Review of link-information from Pekka Savola In-reply-to: <1AA39B75171A7144A73216AED1D7478D2ED3DC@esebe100.NOE.Nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: john.loughney@nokia.com Cc: tero.kauppinen@ericsson.com, alper.yegin@samsung.com, jouni.korhonen@teliasonera.com, dna@eng.monash.edu.au, pekkas@netcore.fi Reply-to: greg.daley@eng.monash.edu.au Message-id: <42781FB6.6050208@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 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <1AA39B75171A7144A73216AED1D7478D2ED3DC@esebe100.NOE.Nokia.com> Content-Transfer-Encoding: 7BIT Hi John, john.loughney@nokia.com wrote: [chop] > > > PDP Contexts can have the following state: > 1) Active - resources & IP address allocated, traffic flow possible > 2) Suspended - resources & IP address allocated, traffic suspended > 3) inactive - no resources & no IP address allocate > > However, even with an active PDP context, it is possible that the link isn't > active; for example if the GGSN goes down, then UE might still be in the > PDP Context active state but there are no resources available. Right. Not all of these are associated with hints from GPRS though. Some of these will be determined through 'other' hints like timeouts or packet reception/non-reception at other layers. > To repeat your question: > > >>The motivation of DNA can also be seen as a way to find an >>answer to the question: "I was previously using this address, can I >>still use it on this network too?" > > > You would need to re-run DNA everytime the PDP context state is changed, in > my opinion. If you receive a credible hint from your own L2 stack that PDP context state has changed, then I think that DNA (of whichever form v4/v6) is necessary. Please have a look at section 5 (particularly 5.(0) and 5.1) in the hosts BCP (draft-ietf-dna-hosts-00). This has recently changed in response to review that there was no explicit actions prescribed in the previous version. Do these sub-sections provide sufficient information to hosts as to what to do in this case? Greg From dna-owner@webcamserver.eng.monash.edu.au Wed May 4 01:15:46 2005 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 BAA16902 for ; Wed, 4 May 2005 01:15:44 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNV53KFTWO96Z9GA@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 04 May 2005 15:15:01 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1CB4EAB544; Wed, 04 May 2005 15:14:40 +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 BE27B4FB0F; Wed, 04 May 2005 15:14:39 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j445DXS12752 for dna-list; Wed, 04 May 2005 15:13:33 +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 j445DWr12748 for ; Wed, 04 May 2005 15:13:32 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNV51W3AM894I5T6@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 04 May 2005 15:13:21 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0BAACAB545; Wed, 04 May 2005 15:13:19 +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 D7A8C4FB05; Wed, 04 May 2005 15:13:18 +1000 (EST) Date: Wed, 04 May 2005 15:13:18 +1000 From: Greg Daley Subject: DNA for IPv4 or IPv6 ( was Re: [DNA] RE: Review of link-information from Pekka Savola) In-reply-to: <4277B2E6.8090008@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: "Tero Kauppinen (JO/LMF)" , Alper Yegin , Pekka Savola , dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <427859EE.4060207@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 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <4277B2E6.8090008@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Erik Nordmark wrote: > Tero Kauppinen (JO/LMF) wrote: [chop] > > I haven't thought much about the dual-stack host doing DNA. I think we've tried to avoid it sometimes... > Given that DNAv4 relies on DHCP and DNA for IPv6 handles stateless > address autoconfig, it seems easiest to pass the 'link up' notifications > to each of them independently. That would work, albeit a bit ineffecient > when the IPv4 links are congruent with the IPv6 links (i.e., if you stay > on the same link as before for IPvX you also do that for IPvY. Likewise > if you move for one, you move for the other.) That's fine until someone spoofs ARP,DHCPv4 and the IPv4 subsystem tells SEND that a link change has occurred. There are some subtleties with regard to trust models which mean that indications from other layers (Transport, Link-layer or another network layer) should be treated as hints in most cases. It may be possible for a sufficiently trusted subsytems on one box to indicate that there's no IPvY service, but that's still just a strong hint. I think I've heard ideas for DHCP to provide IPv4 and IPv6 addresses, but unless you have reason to believe that this is an available service, the same costs in delay and messages are incurred as trying to contact a MIPv4 Foreign agent in DNAv4 (don't rely on it in general). > Jari suggested that we should be able to detect when a host moves from a > dual link to one which only supports one version of IP, and disable the > IP protocol which isn't available. Well, that is if IPv4 was switched on in the first place... :) > This seems a bit scarier to me. While we want DNA to operate efficiently > and quickly, so that it can find a new working address and trigger > Mobile IP style signaling when it has moved, the act of turning off IPvX > is a lot more disruptive; unconfiguring all the IPvX addresses and > blowing away all the connections that used them can't easily be undone. I guess that there may need to be a parking for native support. There's been talk about mobility signalling or auto tunneling when native IPvX or IPvY is not available. If you can't get packets, perhaps 'switching off' is bit bucketing data (or buffering until it's useless and then dropping it), rather than IP subsystem restart. After all: 127.0.0.1 should still work. The way that existing hosts do IPv4 and manage addresses though, it may be a valid fallback mechanism to deconfigure the address and send messages to processes which listen to them. This assumes that only garden variety IPv4 is in use, with no support for mobility or long term disconnection. This would possibly be better done with the complicity of upper-layers though (perhaps through flow control). > And it might be that the host moved to a link with no IPvX support for > just a few seconds, and then moves back to a link where IPvX is available. This is possible for contact via LEO satellites, for example. Parking the connection state makes best sense, rather than losing state. > Perhaps there are anaogous cases for a single IP version when there is > no mobility signaling protocol used on top; in that case it might make > sense to keep the old connections around, just in case the host will > move back to the old link a few seconds later. Agreed. There's likely to be a pain threshold for applications though. If the arrival on a non-supporting link is indicated, it may be possible to set up a tunneled or transition link to a native service. Perhaps it's worthwhile looking at some of these ideas with the remains of the zeroconf team, who are sure to have looked at this (moving to networks with no service). Particularly, if IPvY-only networks are available, does that mean you should pick up a link-local IPvX address? What does that mean for IPvX applications? When do we resort to transition mechanisms (probably a simple question)? If we use transition mechanisms, do we keep our link-local state in IPvX? Greg From dna-owner@webcamserver.eng.monash.edu.au Wed May 4 02:27:14 2005 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 CAA20129 for ; Wed, 4 May 2005 02:27:13 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNV7M425069AMURL@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 04 May 2005 16:26:59 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2E53BAB54B; Wed, 04 May 2005 16:26:53 +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 CEEE34FB0D; Wed, 04 May 2005 16:26:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j446QSt13325 for dna-list; Wed, 04 May 2005 16:26: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 j446QRr13321 for ; Wed, 04 May 2005 16:26:27 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNV7LGLV4E96ZMDM@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 04 May 2005 16:26:21 +1000 Received: by localhost (Postfix, from userid 510) id BF41080002; Wed, 04 May 2005 16:26:21 +1000 (EST) Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by larry.its.monash.edu.au (Postfix) with ESMTP id A7C963C006 for ; Wed, 04 May 2005 16:26:16 +1000 (EST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j446QEO6024582; Wed, 04 May 2005 08:26:14 +0200 Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 04 May 2005 08:26:14 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 04 May 2005 08:26:14 +0200 Date: Wed, 04 May 2005 08:26:13 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: DNA for IPv4 or IPv6 ( was Re: [DNA] RE: Review of link-information from Pekka Savola) Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark , Jari Arkko Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: DNA for IPv4 or IPv6 ( was Re: [DNA] RE: Review of link-information from Pekka Savola) Thread-Index: AcVQJVVWOYWaLKbMRVCnaXZYZ94r0wAS2ZPQ Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 04 May 2005 06:26:14.0307 (UTC) FILETIME=[2BE85F30:01C55072] Content-Transfer-Encoding: 7BIT > > (Observation: all this seems more complicated than I thought at > > first sight. Probably time to write this up somewhere, if not yet > > done.) > > I'm not aware of anybody that has started to write this down. You might find this interesting: http://www.ietf.org/internet-drafts/draft-larsson-v6ops-mip-scenarios-01 .txt We once implemented a prototype basing on it. It even "seemed" to work :) /Tero From dna-owner@webcamserver.eng.monash.edu.au Wed May 4 08:22:36 2005 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 IAA27981 for ; Wed, 4 May 2005 08:22:35 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNVK0NU7PY99GOE3@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 04 May 2005 22:21:56 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7890EAB543; Wed, 04 May 2005 22:21:25 +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 2CF5B4FB06; Wed, 04 May 2005 22:21:25 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j44CKpR15976 for dna-list; Wed, 04 May 2005 22:20:51 +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 j44CKnr15972 for ; Wed, 04 May 2005 22:20:50 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNVJYOLH8S99GOE3@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 04 May 2005 22:20:37 +1000 Received: by localhost (Postfix, from userid 510) id 3CE4480002; Wed, 04 May 2005 22:20:37 +1000 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id CCB983C00B for ; Wed, 04 May 2005 22:20:34 +1000 (EST) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j44CKQl15005; Wed, 04 May 2005 15:20:26 +0300 (EET DST) Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j44CC8Qg032580; Wed, 04 May 2005 15:12:08 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00Ca0gnM; Wed, 04 May 2005 15:10:41 +0100 (EEST) Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j44CAfu12984; Wed, 04 May 2005 15:10:41 +0300 (EET DST) Received: from esebh006.NOE.Nokia.com ([172.21.138.88]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 04 May 2005 15:09:22 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 04 May 2005 15:09:22 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 04 May 2005 15:09:21 +0300 Date: Wed, 04 May 2005 15:09:21 +0300 From: john.loughney@nokia.com Subject: RE: [DNA] RE: Review of link-information from Pekka Savola Sender: owner-dna@ecselists.eng.monash.edu.au To: jari.arkko@kolumbus.fi, erik.nordmark@sun.com Cc: dna@eng.monash.edu.au Message-id: <1AA39B75171A7144A73216AED1D7478D2ED6C0@esebe100.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-Topic: [DNA] RE: Review of link-information from Pekka Savola Thread-Index: AcVQCwITsi8tQlaMS32/05NdVR9U2QAluBKw Content-class: urn:content-classes:message X-Scanned: Wed, 4 May 2005 15:12:08 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 04 May 2005 12:09:21.0487 (UTC) FILETIME=[1AD2BDF0:01C550A2] Content-Transfer-Encoding: 7BIT Jari, > I admit it sounds scarier. But I didn't actually intend to turn off > IPv6 altogether if you hit a link that doesn't appear to be doing v6. > Just v6 on that link! The situation is similar to detecting a > "link down" on > an interface. If you have other interfaces, you keep on using them. > (Or you turn on your other interfaces because of this; this is one > of the reasons why you'd want to know you have no IPvx service.) > If you do not have any other interfaces, you hold on to your session > state and addresses for a while, in case things change for the > better. Finally, home addresses and sessions on top of them should > survive in any case. I think that sounds reasonable. The IPv6 Link would be marked as down; another interface could be started a virtual interface for a transition mechanism could then be substituted. John From dna-owner@webcamserver.eng.monash.edu.au Wed May 4 10:32:44 2005 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 KAA14958 for ; Wed, 4 May 2005 10:32:43 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNVOJW0S7S9AN9B5@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 05 May 2005 00:31:32 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 064F380003; Thu, 05 May 2005 00:31:28 +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 B5DB13C006; Thu, 05 May 2005 00:31:27 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j44EUxA17090 for dna-list; Thu, 05 May 2005 00:30:59 +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 j44EUvr17084 for ; Thu, 05 May 2005 00:30:57 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNVOJ8HVA894ICYO@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 05 May 2005 00:30:56 +1000 Received: by localhost (Postfix, from userid 510) id 7588B80002; Thu, 05 May 2005 00:30:56 +1000 (EST) Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by larry.its.monash.edu.au (Postfix) with ESMTP id 78E1C3C006 for ; Thu, 05 May 2005 00:30:51 +1000 (EST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j44EUWg2008502; Wed, 04 May 2005 16:30:46 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 04 May 2005 16:30:46 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 04 May 2005 16:30:45 +0200 Date: Wed, 04 May 2005 16:30:45 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] RE: Review of link-information from Pekka Savola Sender: owner-dna@ecselists.eng.monash.edu.au To: john.loughney@nokia.com, jari.arkko@kolumbus.fi, erik.nordmark@sun.com Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] RE: Review of link-information from Pekka Savola Thread-Index: AcVQCwITsi8tQlaMS32/05NdVR9U2QAluBKwAAS0XpA= Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 04 May 2005 14:30:45.0955 (UTC) FILETIME=[DBF5D130:01C550B5] Content-Transfer-Encoding: 7BIT > > I admit it sounds scarier. But I didn't actually intend to turn off > > IPv6 altogether if you hit a link that doesn't appear to be doing v6. > > Just v6 on that link! The situation is similar to detecting a > > "link down" on > > an interface. If you have other interfaces, you keep on using them. > > (Or you turn on your other interfaces because of this; this is one > > of the reasons why you'd want to know you have no IPvx service.) > > If you do not have any other interfaces, you hold on to your session > > state and addresses for a while, in case things change for the > > better. Finally, home addresses and sessions on top of them should > > survive in any case. > > I think that sounds reasonable. The IPv6 Link would be marked as down; > another interface could be started a virtual interface for a transition > mechanism could then be substituted. True. It should probably remain down until another link-up notification is received or when the node mysteriously receives an RA without first receiving a notification, i.e. the case when IPv6 router functionality is suddenly enabled. > > John Tero From dna-owner@webcamserver.eng.monash.edu.au Thu May 5 16:41:31 2005 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 QAA12691 for ; Thu, 5 May 2005 16:41:29 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNXFQ9M1W494IFQC@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 06 May 2005 06:41:01 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 20B9AAB543; Fri, 06 May 2005 06:40:53 +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 9F52F4FB0B; Fri, 06 May 2005 06:40:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j45Kcwi32677 for dna-list; Fri, 06 May 2005 06:38:58 +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 j45Kckr32672 for ; Fri, 06 May 2005 06:38:48 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNXFNG96FA9AN82C@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 06 May 2005 06:38:37 +1000 Received: by localhost (Postfix, from userid 510) id 0AD0980002; Fri, 06 May 2005 06:38:36 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id 1A0963C005 for ; Fri, 06 May 2005 06:38:34 +1000 (EST) Received: from redwood.research.panasonic.com (birch.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j45KcXDs032629 for ; Thu, 05 May 2005 16:38:33 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id BEF5F1E8179 for ; Thu, 05 May 2005 16:30:53 -0400 (EDT) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62]) by redwood.research.panasonic.com (Postfix) with ESMTP id B601D1E816Afor ; Thu, 05 May 2005 16:30:53 -0400 (EDT) Received: from [128.238.242.254] bypintlmail.MITL.Research.Panasonic.COM (mshttpd); Thu, 05 May 200516:38:33 -0400 Date: Thu, 05 May 2005 16:38:33 -0400 From: Sathya Narayanan Subject: [DNA] DNA Design team solution draft - **** Correction ****** Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <8eef98a6de.8a6de8eef9@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:22.30183 C:17 M:0 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.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Dear WG - Since the IETF secretariat objected to the name of the draft being 'draft-dnadt..' we resubmitted it as 'draft-pentland...'. The current draft can be found at http://www.ietf.org/internet-drafts/draft-pentland-dna-protocol-00.txt To avoid any confusions, please refer to the above link. thanks, Sathya for The DNA Design Team. ----- Original Message ----- From: Sathya Narayanan Date: Tuesday, May 3, 2005 4:46 pm Subject: [DNA] DNA Design team solution draft > Dear WG - > > The design team submitted a solution draft today. It should appear > in > the internet-draft directory soon. Meanwhile, the draft can be > found at > http://www.ctie.monash.edu.au/dna-dt/draft-dnadt-dna-protocol-00.txt > > Please read the document and provide comments. > > thanks & regards, > Sathya > > for > The Design Team. > > From dna-owner@webcamserver.eng.monash.edu.au Thu May 5 18:29:13 2005 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 SAA27464 for ; Thu, 5 May 2005 18:29:12 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNXJI9FVKU9705S9@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 06 May 2005 08:29:06 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B6FD2AB545; Fri, 06 May 2005 08:28:57 +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 7A8AF4FB0D; Fri, 06 May 2005 08:28:57 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j45MSSj01198 for dna-list; Fri, 06 May 2005 08:28: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 j45MSQr01194 for ; Fri, 06 May 2005 08:28:26 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNXJH9W3PU9705S9@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 06 May 2005 08:28:10 +1000 Received: by localhost (Postfix, from userid 510) id 14E86AB543; Fri, 06 May 2005 08:28:10 +1000 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by curly.its.monash.edu.au (Postfix) with ESMTP id 028A54FB08; Fri, 06 May 2005 08:28:07 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.228.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j45MS6Q1011021; Thu, 05 May 2005 15:28:06 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j45MS4dg135988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 05 May 2005 15:28:05 -0700 (PDT) Date: Thu, 05 May 2005 15:28:10 -0700 From: Erik Nordmark Subject: Re: DNA for IPv4 or IPv6 ( was Re: [DNA] RE: Review of link-information from Pekka Savola) In-reply-to: <427859EE.4060207@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: "Tero Kauppinen (JO/LMF)" , Alper Yegin , Pekka Savola , dna@eng.monash.edu.au Message-id: <427A9DFA.3080703@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 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <4277B2E6.8090008@sun.com> <427859EE.4060207@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > That's fine until someone spoofs ARP,DHCPv4 and the IPv4 subsystem tells > SEND that a link change has occurred. > > There are some subtleties with regard to trust models which mean that > indications from other layers (Transport, Link-layer or another network > layer) should be treated as hints in most cases. > > It may be possible for a sufficiently trusted subsytems on one box to > indicate that there's no IPvY service, but that's still just a strong > hint. Yes, but it isn't obvious to me that heeding such a strong hint would have any detrimental effect. It would just mean that the DNA would discard the old routers, prefixes, etc and then more or less immediately configure the same ones. Thus it doesn't sound like an interesting attack for the attacker; it wouldn't cause much harm. > There's been talk about mobility signalling or auto tunneling when > native IPvX or IPvY is not available. That might be an option when you have some mipvX service. But we need DNA to work whether or not such support is available; just a plain old dual-stack host should get reasonable behavior from DNA. > If you can't get packets, perhaps 'switching off' is bit bucketing > data (or buffering until it's useless and then dropping it), rather than > IP subsystem restart. After all: 127.0.0.1 should still work. Making 127.0.0.1 and ::1 is easy even when the host moves very frequently :-) >> And it might be that the host moved to a link with no IPvX support for >> just a few seconds, and then moves back to a link where IPvX is >> available. > > > This is possible for contact via LEO satellites, for example. I assume it is just as possible walking around with 802.11 APs, and the boundary between different IP links (some APs on one subnet and other APs on another subnet). > Perhaps it's worthwhile looking at some of these ideas with the > remains of the zeroconf team, who are sure to have looked at this > (moving to networks with no service). I doubt the zeroconf experience has anything to offer (than additional complexity and unsolvable problems). Bernard's observation that most use of IPv4 link-local is due to some failure is an important one. And things like 802.11 ad-hoc mode seems to also show up due to failures (the desire being to associate with the AP, but the AP doesn't respond quickly enough and the software is configured to automatically fallback to ad-hoc.) My take is that most of the devices that we understand today (laptops, PDAs, mobile phones) actually want Internet connectivity. So assuming that some local-only communication using IPvX link-local address will add something (other than failure modes and complexity) seems odd to me. Erik From dna-owner@webcamserver.eng.monash.edu.au Thu May 5 19:46:07 2005 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 TAA08533 for ; Thu, 5 May 2005 19:46:06 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNXM6RL4BQ94IOKV@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 06 May 2005 09:45:39 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3744380004; Fri, 06 May 2005 09:45:12 +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 E057D3C008; Fri, 06 May 2005 09:45:11 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j45Nie501899 for dna-list; Fri, 06 May 2005 09:44:40 +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 j45Nicr01895 for ; Fri, 06 May 2005 09:44:38 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LNXM5QQOH69ANARW@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 06 May 2005 09:44:23 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A41EFAB543; Fri, 06 May 2005 09:44:22 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id 811504FB02; Fri, 06 May 2005 09:44:22 +1000 (EST) Received: from [211.28.23.28] by mail-store-2.its.monash.edu.au (mshttpd); Fri, 06 May 2005 09:44:22 +1000 Date: Fri, 06 May 2005 09:44:22 +1000 From: Greg Daley Subject: Re: DNA for IPv4 or IPv6 ( was Re: [DNA] RE: Review of link-information from Pekka Savola) Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: greg.daley@eng.monash.edu.au, "Tero Kauppinen (JO/LMF)" , Alper Yegin , Pekka Savola , dna@eng.monash.edu.au Message-id: <1ba8b1b3fe.1b3fe1ba8b@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 Patch 2 (built Jul 14 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Erik, ----- Original Message ----- [cut] > > Yes, but it isn't obvious to me that heeding such a strong hint > would have any detrimental effect. It would just mean that the > DNA would discard the old routers, prefixes, etc and then more > or less immediately configure the same ones. > > Thus it doesn't sound like an interesting attack for the attacker; > it wouldn't cause much harm. Perhaps. Still, the potential for harm is the same if any unverified hint is used to invalidate state before reception of an RA. Strong (or fast) attackers can get in first with an RA which wouldn't otherwise have been listened to. Any DNA procedures just need to be wise or robust to this though. > > > There's been talk about mobility signalling or auto tunneling when > > native IPvX or IPvY is not available. > > That might be an option when you have some mipvX service. > But we need DNA to work whether or not such support is available; > just a plain old dual-stack host should get reasonable behavior > from DNA. Agreed. They may have resources on another interface (or upper layer) which just needs to know the availability of IPvX access. > > If you can't get packets, perhaps 'switching off' is bit bucketing > > data (or buffering until it's useless and then dropping it), > rather than > > IP subsystem restart. After all: 127.0.0.1 should still work. > > Making 127.0.0.1 and ::1 is easy even when the host moves very > frequently :-) Sounds like you've got a short draft to write before April next year. > >> And it might be that the host moved to a link with no IPvX > support for > >> just a few seconds, and then moves back to a link where IPvX is > >> available. > > > > > > This is possible for contact via LEO satellites, for example. > > I assume it is just as possible walking around with 802.11 APs, > and the boundary between different IP links (some APs on one > subnet and other APs on another subnet). It's going to be pretty common. > > Perhaps it's worthwhile looking at some of these ideas with the > > remains of the zeroconf team, who are sure to have looked at this > > (moving to networks with no service). > > I doubt the zeroconf experience has anything to offer (than > additional complexity and unsolvable problems). > Bernard's observation that most use of IPv4 link-local is due to > some failure is an important one. And things like 802.11 ad-hoc > mode seems to also show up due to failures (the desire being to > associate with the AP, but the AP doesn't respond quickly > enough and the software is configured to automatically fallback > to ad-hoc.) Well let's not make those mistakes if they're costly in our environment..... Knowing what not to do is worthwhile. Talking to Bernard about any caveats from IPv4 LL (which aren't already mentioned in the DNAv4 document) would be useful. > My take is that most of the devices that we understand today > (laptops, PDAs, mobile phones) actually want Internet connectivity. > So assuming that some local-only communication using IPvX link-local > address will add something (other than failure modes and complexity) > seems odd to me. The default in Linux is to configure IPv6 Link-Local addresses on an interface if IPv6 is on. I believe it then then follows ND and attempts Router Discovery, falling back into a state of quiet after MAX_RTR_SOLICITATIONS (not looking at 2461, at the moment for names, sorry). Resetting the state for this interface may be within the realms of DNAv6, by default in this WG, we think of an interface being actively used, or having active configuration to check. When IPv6 service is unavailable on a valid interface though, procedures may be slightly different. For example (and not meant as a premature optimization) it doesn't make sense to send 3 or 4 router solicitations on an interface if IPv4 'knows' it's on the same IPv4 subnet=> same link. That's all I had in mind. The remaining state for latent IPv6 or IPv4 link local may need resetting or modification. Greg From dna-owner@webcamserver.eng.monash.edu.au Fri May 6 12:46:53 2005 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 MAA08771 for ; Fri, 6 May 2005 12:46:52 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNYLT0BNMA9703H1@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 07 May 2005 02:46:18 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3094F80003; Sat, 07 May 2005 02:45:41 +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 D51D03C004; Sat, 07 May 2005 02:45:40 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j46GixW10370 for dna-list; Sat, 07 May 2005 02:44:59 +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 j46Givr10366 for ; Sat, 07 May 2005 02:44:57 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LNYLRQOJBE94IRL2@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 07 May 2005 02:44:40 +1000 Received: by localhost (Postfix, from userid 510) id EA7A580003; Sat, 07 May 2005 02:44:39 +1000 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by larry.its.monash.edu.au (Postfix) with ESMTP id D77793C003; Sat, 07 May 2005 02:44:37 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.68.36]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j46GiZQ1020270; Fri, 06 May 2005 09:44:36 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j46GiYeC454719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 06 May 2005 09:44:35 -0700 (PDT) Date: Fri, 06 May 2005 09:44:39 -0700 From: Erik Nordmark Subject: Re: DNA for IPv4 or IPv6 ( was Re: [DNA] RE: Review of link-information from Pekka Savola) In-reply-to: <1ba8b1b3fe.1b3fe1ba8b@monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: "Tero Kauppinen (JO/LMF)" , Alper Yegin , Pekka Savola , dna@eng.monash.edu.au Message-id: <427B9EF7.9080809@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 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <1ba8b1b3fe.1b3fe1ba8b@monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: >>My take is that most of the devices that we understand today >>(laptops, PDAs, mobile phones) actually want Internet connectivity. >>So assuming that some local-only communication using IPvX link-local >>address will add something (other than failure modes and complexity) >>seems odd to me. > > > The default in Linux is to configure IPv6 Link-Local addresses on an > interface > if IPv6 is on. Yes, but link-local works quite differently than link-local IPv4 in most stacks. A host can have a link-local IPv6 address and one or more global IPv6 addresses, whereas for many IPv4 stacks it is an either link-local or non-link local, which makes switching back and forth so much more painful in IPv4. Also, there's been the 'v6 on by default' discussion in v6ops, so I think by now most stacks can operate with an IPv6 link-local address (and no globals, due to no IPv6 router), without any adverse effect on applications (which will just use IPv4). > For example (and not meant as a premature optimization) it doesn't make > sense > to send 3 or 4 router solicitations on an interface if IPv4 'knows' > it's on > the same IPv4 subnet=> same link. Unless you are concerned about ARP/DHCP spoofs that make the host think it didn't move when it in fact did, and IPv6 is using SeND. Attacks that try to convince you that you didn't move (when you did) are a lot worse than those that try to convince you that you moved when you didn't. Erik From dna-owner@webcamserver.eng.monash.edu.au Sun May 8 22:45:52 2005 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 WAA20359 for ; Sun, 8 May 2005 22:45:51 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LO1ZB164LS94ITFL@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 09 May 2005 12:44:38 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 04ABCAB544; Mon, 09 May 2005 12:44:26 +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 B64C54FB04; Mon, 09 May 2005 12:44:25 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j492fbQ01806 for dna-list; Mon, 09 May 2005 12:41:37 +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 j492fZr01802 for ; Mon, 09 May 2005 12:41:35 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LO1Z742U5K970THQ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 09 May 2005 12:41:16 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6795980004; Mon, 09 May 2005 12:41:16 +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 385D93C009; Mon, 09 May 2005 12:41:16 +1000 (EST) Date: Mon, 09 May 2005 12:41:15 +1000 From: Brett Pentland Subject: [DNA] DT status Sender: owner-dna@ecselists.eng.monash.edu.au To: DNA WG Message-id: <427ECDCB.9000006@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) Content-Transfer-Encoding: 7BIT Dear DNA WG, The design team has just recently posted a draft that represents a solution that most of the DT feels is workable when a few outstanding issues are resolved. Not everyone is comfortable with the proposal, and there will be two more proposals presented shortly - one that is a fairly small modification to the posted proposal, and one that is substantially different. We look forward to discussing the pros and cons of the proposals on the WG list. Brett. (For the design team) From dna-owner@webcamserver.eng.monash.edu.au Tue May 10 01:27:00 2005 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 BAA20706 for ; Tue, 10 May 2005 01:26:59 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LO3J84NX1899H65K@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 10 May 2005 15:25:37 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D744880005; Tue, 10 May 2005 15:25: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 897EA3C003; Tue, 10 May 2005 15:25:32 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4A5OOo19076 for dna-list; Tue, 10 May 2005 15:24:24 +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 j4A5ONr19072 for ; Tue, 10 May 2005 15:24:23 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LO3J6DRO8K94JMLS@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 10 May 2005 15:24:08 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 44428AB543 for ; Tue, 10 May 2005 15:24:08 +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 F06834FB02 for ; Tue, 10 May 2005 15:24:07 +1000 (EST) Date: Tue, 10 May 2005 15:24:02 +1000 From: Greg Daley Subject: [DNA] Design Team solution 1: Question about DNA Option Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42804572.5090508@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 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT from draft-pentland-dna-protocol-00.txt: Section 4.3: The learned prefixes in the DNA option are not 8 octet aligned, and include prefix lengths. Assuming that advertised prefixes are global addresses, can't the prefixes be: 1) 8 octet aligned and 2) 8 octets (64 bits) long With no prefix length field. From RFC 3513 (S2.5.1): For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. This would lead to 6 octets overhead (which is the minimum additional cost when you consider the size of prefix lengths). One of those octets could indicate the known number of prefixes, and the option length could indicate how many prefixes are advertised (effectively indicating if the RA is complete or not when the PIOs are counted). This would remove the need to get two bits from the RA header in the case of Also, if there is a requested landmark prefix, could it not appear in the DNA option, even if the option is does not provide complete RA? The minimum NACK for an unknown landmark would then be 8 octets (no prefixes in the list), on top of the existing RA. The DNA option could then be used in both solicitor and receiver. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed May 11 12:23:55 2005 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 MAA20804 for ; Wed, 11 May 2005 12:23:54 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LO5KIG2MJ89ANG6R@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 12 May 2005 02:23:43 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7FB96AB54A; Thu, 12 May 2005 02:23: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 2C79E4FB04; Thu, 12 May 2005 02:23:41 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4BGMCo08947 for dna-list; Thu, 12 May 2005 02:22: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 j4BGMBr08943 for ; Thu, 12 May 2005 02:22:11 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LO5KGHGU4K97046T@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 12 May 2005 02:22:07 +1000 Received: by localhost (Postfix, from userid 510) id C001DAB543; Thu, 12 May 2005 02:22:06 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 296B14FB03 for ; Thu, 12 May 2005 02:22:05 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1DVtyE-0008pE-6E for dna@eng.monash.edu.au; Wed, 11 May 2005 12:22:02 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4BGM0R04971 for ; Wed, 11 May 2005 09:22:01 -0700 Date: Wed, 11 May 2005 09:22:00 -0700 (PDT) From: Bernard Aboba Subject: [DNA] Last call: Detection of Network Attachment (DNA) in IPv4 (fwd) In-reply-to: <427B9EF7.9080809@sun.com> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <1ba8b1b3fe.1b3fe1ba8b@monash.edu.au> <427B9EF7.9080809@sun.com> Content-Transfer-Encoding: 7BIT The IESG has received a request from the Dynamic Host Configuration WG to consider the following document: - 'Detection of Network Attachment (DNA) in IPv4 ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg at ietf.org or ietf at ietf.org mailing lists by 2005-05-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-11.txt From dna-owner@webcamserver.eng.monash.edu.au Wed May 11 23:28:31 2005 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 XAA25196 for ; Wed, 11 May 2005 23:28:30 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LO67OC2FJY94JV54@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 12 May 2005 13:27:39 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 76A6080005; Thu, 12 May 2005 13:27: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 223263C008; Thu, 12 May 2005 13:27:23 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4C3PG816304 for dna-list; Thu, 12 May 2005 13:25:16 +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 j4C3PGr16300 for ; Thu, 12 May 2005 13:25:16 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LO67LDEKT299HLH4@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 12 May 2005 13:25:00 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3B379AB542; Thu, 12 May 2005 13:25:00 +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 curly.its.monash.edu.au (Postfix) with ESMTP id 1A2C74FB06; Thu, 12 May 2005 13:25:00 +1000 (EST) Date: Thu, 12 May 2005 13:24:59 +1000 From: Brett Pentland Subject: Re: [DNA] Design Team solution 1: Question about DNA Option In-reply-to: <42804572.5090508@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <4282CC8B.1020601@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) References: <42804572.5090508@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > from draft-pentland-dna-protocol-00.txt: > > Section 4.3: > > The learned prefixes in the DNA option are not > 8 octet aligned, and include prefix lengths. Yes this is something that needs more thought. > Assuming that advertised prefixes are global > addresses, can't the prefixes be: > 1) 8 octet aligned and Probably necessary. > 2) 8 octets (64 bits) long > > With no prefix length field. > > From RFC 3513 (S2.5.1): > > For all unicast addresses, except those that start with binary value > 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. Does this imply that all advertised prefixes MUST be 64 bits long? If so it would simplify the DNAO considerably. > This would lead to 6 octets overhead (which is the minimum additional > cost when you consider the size of prefix lengths). > One of those octets could indicate the known number of prefixes, > and the option length could indicate how many prefixes are advertised > (effectively indicating if the RA is complete or not when the PIOs > are counted). The known number of prefixes is something which we had in there and removed. The thinking was that if the number didn't match the number of prefixes in PIOs and the DNAO, then it wasn't really much use, and thus its function was no greater than a "complete" bit. That bit could go in the DNAO, but then the DNAO would need to be included, even when there were no learned prefixes (ie. when routers all advertise the same set of prefixes on a given link). This would then mean that 64 bits were being included to carry one bit of information. > This would remove the need to get two bits from the RA header in the > case of > > Also, if there is a requested landmark prefix, could it not appear > in the DNA option, even if the option is does not provide complete RA? > The minimum NACK for an unknown landmark would then be 8 octets > (no prefixes in the list), on top of the existing RA. > > The DNA option could then be used in both solicitor and receiver. Yes, I think this could be done. It would be overloading two separate functions on the DNAO. Does it provide some advantage to do this? As the draft stands, we have two modes of operation and the Landmark Option is used for one, and the DNA Option for the other. The preferred mode is a unicast response. The host uses a Landmark Option to ask if a prefix is being advertised on a link, and any router can unicast a response including a Landmark Option indicating yes or no for that prefix. The DNA Option is used in multicast RAs as a fallback position when a unicast is not possible (due to rate limiting or insufficient information). It allows the RA to contain enough information for hosts to be able to make a decision on their own. The intention is that this is a fallback position, however, and that the normal state of affairs would be a simple "Is prefix X being advertised on this link?" - "Yes, prefix X is" or "no, prefix X isn't". Brett. From dna-owner@webcamserver.eng.monash.edu.au Thu May 12 02:40:47 2005 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 CAA28208 for ; Thu, 12 May 2005 02:40:45 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LO6EF3ED7Y9ANGVI@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 12 May 2005 16:40:01 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E0692AB547; Thu, 12 May 2005 16:39:58 +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 996D94FB07; Thu, 12 May 2005 16:39:58 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4C6dOH18335 for dna-list; Thu, 12 May 2005 16:39:24 +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 j4C6dNr18331 for ; Thu, 12 May 2005 16:39:23 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LO6EE9QIC499HKU3@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 12 May 2005 16:39:19 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 149E6AB546; Thu, 12 May 2005 16:39:19 +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 CDEF14FB0A; Thu, 12 May 2005 16:39:18 +1000 (EST) Date: Thu, 12 May 2005 16:39:15 +1000 From: Greg Daley Subject: Re: [DNA] Design Team solution 1: Question about DNA Option In-reply-to: <4282CC8B.1020601@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <4282FA13.1060800@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 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <42804572.5090508@eng.monash.edu.au> <4282CC8B.1020601@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, Please be aware that any hats I have are off, and I'm trying to work on engineering issues, providing personal opinions. Brett Pentland wrote: > Greg Daley wrote: > >> from draft-pentland-dna-protocol-00.txt: >> >> Section 4.3: >> >> The learned prefixes in the DNA option are not >> 8 octet aligned, and include prefix lengths. > > > Yes this is something that needs more thought. > >> Assuming that advertised prefixes are global >> addresses, can't the prefixes be: >> 1) 8 octet aligned and > > > Probably necessary. > >> 2) 8 octets (64 bits) long >> >> With no prefix length field. >> >> From RFC 3513 (S2.5.1): >> >> For all unicast addresses, except those that start with binary value >> 000, Interface IDs are required to be 64 bits long and to be >> constructed in Modified EUI-64 format. > > > Does this imply that all advertised prefixes MUST be 64 bits long? > If so it would simplify the DNAO considerably. 2462Bis Section 5.5.3 talks about this in some detail. The prefixes in PIOs in 2462Bis are described as being potentially variable length. What would be sufficient here is to use the DNAO header to identify the number of 64 bit prefixes present in the option (which would consume a portion of the option's size), with the space after that explicitly ignored. This would allow for arbitrary sized prefixes later, and not penalize existing 3513 compliant systems which advertise 64 bit IIDs (and 64 bit Prefixes), except for 8 bits which are reserved (out of 40). >> This would lead to 6 octets overhead (which is the minimum additional >> cost when you consider the size of prefix lengths). >> One of those octets could indicate the known number of prefixes, >> and the option length could indicate how many prefixes are advertised >> (effectively indicating if the RA is complete or not when the PIOs >> are counted). > > > The known number of prefixes is something which we had in there and > removed. The thinking was that if the number didn't match the number of > prefixes in PIOs and the DNAO, then it wasn't really much use, and thus > its function was no greater than a "complete" bit. That bit could go in > the DNAO, but then the DNAO would need to be included, even when there > were no learned prefixes (ie. when routers all advertise the same set of > prefixes on a given link). This would then mean that 64 bits were > being included to carry one bit of information. Well the document either does CompleteRA (on every unsolicited RA) now, or it has a prefix landmark in it. The benefits of putting the completeness information into all the unsolicited RAs is of very marginal benefit (only helps for packet loss, since the initial assumption of the document is that L2 hints are available). The solicited RAs then already have space for either a landmark or a completeRA (DNA) Option. Each of the specifications will have wasted space, which can be put to use for other purposes. It's actually not one bit of information either. The fact that a host knows all the number of prefixes but can't fit them in an RA can be used to compose a complete prefix list which is provably (with SEND) complete. At least the MN can stop hunting for new prefixes if in the responses from two or more routers, it can see that a conjoined (and complete) set of prefixes is available. >> This would remove the need to get two bits from the RA header in the >> case of >> >> Also, if there is a requested landmark prefix, could it not appear >> in the DNA option, even if the option is does not provide complete RA? >> The minimum NACK for an unknown landmark would then be 8 octets >> (no prefixes in the list), on top of the existing RA. >> >> The DNA option could then be used in both solicitor and receiver. > > > Yes, I think this could be done. It would be overloading two separate > functions on the DNAO. Does it provide some advantage to do this? Yes. One option is defined for solicitor and receiver. The storage of the prefixes for both completeRA and Prefix Landmarks are the same (they both collect a list of prefixes). The selection of a prefix from the known prefix set for transmission is just an ordering issue (for example, if it's not possible to transmit the whole set). So the option contents are the same, I guess the option should be too. > As the draft stands, we have two modes of operation and the Landmark > Option is used for one, and the DNA Option for the other. The preferred > mode is a unicast response. The host uses a Landmark Option to ask > if a prefix is being advertised on a link, and any router can unicast a > response including a Landmark Option indicating yes or no for that > prefix. The DNA Option is used in multicast RAs as a fallback position > when a unicast is not possible (due to rate limiting or insufficient > information). It allows the RA to contain enough information for hosts > to be able to make a decision on their own. The intention is that this > is a fallback position, however, and that the normal state of affairs > would be a simple "Is prefix X being advertised on this link?" - "Yes, > prefix X is" or "no, prefix X isn't". I don't like the yes/no either. Well, SEND already has better response matching than this using its Nonce Options (which are mandaroty for SEND responses). It's also possible to use this without SEND as detailed in: draft-daley-dna-nonce-resp-01.txt Sorry about the self plug, but I think it's a good solution. (much cleaner than the yes/no as a faked up response match). Greg From dna-owner@webcamserver.eng.monash.edu.au Thu May 12 03:56:21 2005 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 DAA02847 for ; Thu, 12 May 2005 03:56:20 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LO6H1OFK9494K3UL@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 12 May 2005 17:55:37 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6919780003; Thu, 12 May 2005 17:55:27 +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 022E13C009; Thu, 12 May 2005 17:55:27 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4C7swu19155 for dna-list; Thu, 12 May 2005 17:54:58 +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 j4C7swr19151 for ; Thu, 12 May 2005 17:54:58 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LO6H118BS2971YM8@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 12 May 2005 17:54:56 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 221A280002; Thu, 12 May 2005 17:54:56 +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 E6D9A3C007; Thu, 12 May 2005 17:54:55 +1000 (EST) Date: Thu, 12 May 2005 17:54:50 +1000 From: Brett Pentland Subject: Re: [DNA] Design Team solution 1: Question about DNA Option In-reply-to: <4282FA13.1060800@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <42830BCA.9080906@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) References: <42804572.5090508@eng.monash.edu.au> <4282CC8B.1020601@eng.monash.edu.au> <4282FA13.1060800@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT >>> This would lead to 6 octets overhead (which is the minimum additional >>> cost when you consider the size of prefix lengths). >>> One of those octets could indicate the known number of prefixes, >>> and the option length could indicate how many prefixes are advertised >>> (effectively indicating if the RA is complete or not when the PIOs >>> are counted). >> >> >> >> The known number of prefixes is something which we had in there and >> removed. The thinking was that if the number didn't match the number of >> prefixes in PIOs and the DNAO, then it wasn't really much use, and thus >> its function was no greater than a "complete" bit. That bit could go in >> the DNAO, but then the DNAO would need to be included, even when there >> were no learned prefixes (ie. when routers all advertise the same set of >> prefixes on a given link). This would then mean that 64 bits were >> being included to carry one bit of information. > > > Well the document either does CompleteRA (on every unsolicited RA) now, > or it has a prefix landmark in it. > > The benefits of putting the completeness information into all the > unsolicited RAs is of very marginal benefit (only helps for > packet loss, since the initial assumption of the document is that > L2 hints are available). Yes, the primary reason for it being there was for a fallback when the unicast response isn't possible. > The solicited RAs then already have space for either a landmark or > a completeRA (DNA) Option. Each of the specifications will have > wasted space, which can be put to use for other purposes. > > It's actually not one bit of information either. > > The fact that a host knows all the number of prefixes but can't fit > them in an RA can be used to compose a complete prefix list which is > provably (with SEND) complete. At least the MN can stop hunting for new > prefixes if in the responses from two or more routers, it can see that > a conjoined (and complete) set of prefixes is available. Yes, and this is why we originally had it there. The result of our discussion was that since the RA is not complete and the host would not be able to make a decision based on that RA alone, there wasn't all that much value in it. If folks think that the assistance this provides in building a CPL is worthwhile, it could be put back. >>> This would remove the need to get two bits from the RA header in the >>> case of >>> >>> Also, if there is a requested landmark prefix, could it not appear >>> in the DNA option, even if the option is does not provide complete RA? >>> The minimum NACK for an unknown landmark would then be 8 octets >>> (no prefixes in the list), on top of the existing RA. >>> >>> The DNA option could then be used in both solicitor and receiver. >> >> >> >> Yes, I think this could be done. It would be overloading two separate >> functions on the DNAO. Does it provide some advantage to do this? > > > Yes. > > One option is defined for solicitor and receiver. > > The storage of the prefixes for both completeRA and Prefix Landmarks > are the same (they both collect a list of prefixes). > > The selection of a prefix from the known prefix set for transmission > is just an ordering issue (for example, if it's not possible to transmit > the whole set). > > So the option contents are the same, I guess the option should be > too. They are the same if you don't use the yes/no flags for answering the landmark question. If you do, then you need to tie the flags to a particular prefix in the option (maybe there is only one in that case) or match the RS/RA with a nonce as you suggest below, and the overload get a bit uglier. >> As the draft stands, we have two modes of operation and the Landmark >> Option is used for one, and the DNA Option for the other. The preferred >> mode is a unicast response. The host uses a Landmark Option to ask >> if a prefix is being advertised on a link, and any router can unicast a >> response including a Landmark Option indicating yes or no for that >> prefix. The DNA Option is used in multicast RAs as a fallback position >> when a unicast is not possible (due to rate limiting or insufficient >> information). It allows the RA to contain enough information for hosts >> to be able to make a decision on their own. The intention is that this >> is a fallback position, however, and that the normal state of affairs >> would be a simple "Is prefix X being advertised on this link?" - "Yes, >> prefix X is" or "no, prefix X isn't". > > > I don't like the yes/no either. > > Well, SEND already has better response matching than this > using its Nonce Options (which are mandaroty for SEND responses). > > It's also possible to use this without SEND as detailed in: > > draft-daley-dna-nonce-resp-01.txt > > Sorry about the self plug, but I think it's a good solution. > > (much cleaner than the yes/no as a faked up response match). It's true that you can match responses with a SEND nonce, but I wouldn't call this a faked up response match because response matching was not the primary goal. The matching is being done between the answer and the question, and one could argue that it's cleaner doing that match fully contained within the RA, rather than across the RS/RA using a nonce. Brett. From dna-owner@webcamserver.eng.monash.edu.au Thu May 12 04:13:00 2005 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 EAA03707 for ; Thu, 12 May 2005 04:12:58 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LO6HM8WF6Y94JOWG@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 12 May 2005 18:12:38 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0C81BAB544; Thu, 12 May 2005 18:12:02 +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 AE9454FB02; Thu, 12 May 2005 18:12:01 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4C8Bs819383 for dna-list; Thu, 12 May 2005 18:11:54 +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 j4C8Bsr19379 for ; Thu, 12 May 2005 18:11:54 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LO6HKZQ7OK94JOWG@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 12 May 2005 18:11:01 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A629380004; Thu, 12 May 2005 18:11:01 +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 8846F3C00B; Thu, 12 May 2005 18:11:01 +1000 (EST) Date: Thu, 12 May 2005 18:10:59 +1000 From: Greg Daley Subject: Re: [DNA] Design Team solution 1: Question about DNA Option In-reply-to: <42830BCA.9080906@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42830F93.5090500@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 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <42804572.5090508@eng.monash.edu.au> <4282CC8B.1020601@eng.monash.edu.au> <4282FA13.1060800@eng.monash.edu.au> <42830BCA.9080906@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett. Thanks for this. In case people aren't aware I'm travelling to Cairns next week (hat off again) to the IEEE wireless (802.21/802.11) interim meeting. It's a chance to express opinions just before my e-mail becomes intermittent. Brett Pentland wrote: [cut] >> Well the document either does CompleteRA (on every unsolicited RA) now, >> or it has a prefix landmark in it. >> >> The benefits of putting the completeness information into all the >> unsolicited RAs is of very marginal benefit (only helps for >> packet loss, since the initial assumption of the document is that >> L2 hints are available). > > > Yes, the primary reason for it being there was for a fallback when the > unicast response isn't possible. I guess that if we're prepared to accept "no additional prefixes" option as a tax for solicited RAs even if there's no requested landmark (even if it's multicast), Then the DNAO could be used as both completeRA and landmarking solution, without consuming RA header bits. Please note that I'm not worried about completeRA for unsolicited RA, or even the "Completeness" part, although that's neat. What I'm thinking of is: Here are a bunch of prefixes I've learned are on the link: it didn't cost me much more to send them (even if the set is incomplete). [cut] >> >> So the option contents are the same, I guess the option should be >> too. > > > They are the same if you don't use the yes/no flags for answering > the landmark question. If you do, then you need to tie the flags to > a particular prefix in the option (maybe there is only one in that > case) or match the RS/RA with a nonce as you suggest below, and the > overload get a bit uglier. Well, if you guarantee a "MUST" on the requested prefix if it is known, then it doesn't matter with overload. You'd just advertise "I'm overloaded, please don't infer that the prefix is absent". Note that overloaded is different to "decided not to advertise". >>> As the draft stands, we have two modes of operation and the Landmark >>> Option is used for one, and the DNA Option for the other. The preferred >>> mode is a unicast response. The host uses a Landmark Option to ask >>> if a prefix is being advertised on a link, and any router can unicast a >>> response including a Landmark Option indicating yes or no for that >>> prefix. The DNA Option is used in multicast RAs as a fallback position >>> when a unicast is not possible (due to rate limiting or insufficient >>> information). It allows the RA to contain enough information for hosts >>> to be able to make a decision on their own. The intention is that this >>> is a fallback position, however, and that the normal state of affairs >>> would be a simple "Is prefix X being advertised on this link?" - "Yes, >>> prefix X is" or "no, prefix X isn't". >> >> >> >> I don't like the yes/no either. >> >> Well, SEND already has better response matching than this >> using its Nonce Options (which are mandaroty for SEND responses). >> >> It's also possible to use this without SEND as detailed in: >> >> draft-daley-dna-nonce-resp-01.txt >> >> Sorry about the self plug, but I think it's a good solution. >> >> (much cleaner than the yes/no as a faked up response match). > > > It's true that you can match responses with a SEND nonce, but I > wouldn't call this a faked up response match because response > matching was not the primary goal. The matching is being done > between the answer and the question, and one could argue that it's > cleaner doing that match fully contained within the RA, rather than > across the RS/RA using a nonce. Well I thought SEND was a SHOULD anyway. If we SHOULD send it it will already be present in most RS's, nodes interested but otherwise unwilling to implement SEND may be able to buy in at a fairly low cost (16 octets over the combined RS/RA). Reception of an RA with your nonce means that other information, like which question you were asking (is this a valid prefix?) Don't need to be contained in the message. The gain may be considered to be marginal, except that the "No" response is required (perhaps in a separate option), every time movement occurs. That's the case to optimize... Sure the host would have to remember the question, to match the Nonce, but I'd argue that it probably would anyway, in order to modify state. Plus the nonce makes a good basis for a hash lookup key ;) Greg From dna-owner@webcamserver.eng.monash.edu.au Thu May 12 14:11:33 2005 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 OAA17286 for ; Thu, 12 May 2005 14:11:32 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LO72H9T60G94K03E@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 13 May 2005 04:09:04 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id ED040AB543; Fri, 13 May 2005 04:08:55 +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 A44C64FB03; Fri, 13 May 2005 04:08:55 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4CI7ga26070 for dna-list; Fri, 13 May 2005 04:07:42 +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 j4CI7er26066 for ; Fri, 13 May 2005 04:07:40 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LO72FBDVWC9720ZW@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 13 May 2005 04:07:21 +1000 Received: by localhost (Postfix, from userid 510) id 80ACAAB543; Fri, 13 May 2005 04:07:21 +1000 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by curly.its.monash.edu.au (Postfix) with ESMTP id 4A4B54FB08; Fri, 13 May 2005 04:07:20 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.224.130]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j4CI7Ii7005925; Thu, 12 May 2005 12:07:18 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j4CI7Gw9646400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 12 May 2005 11:07:17 -0700 (PDT) Date: Thu, 12 May 2005 11:07:24 -0700 From: Erik Nordmark Subject: Re: [DNA] Design Team solution 1: Question about DNA Option In-reply-to: <42804572.5090508@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <42839B5C.7090609@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 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <42804572.5090508@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > from draft-pentland-dna-protocol-00.txt: > > Section 4.3: > > The learned prefixes in the DNA option are not > 8 octet aligned, and include prefix lengths. > > Assuming that advertised prefixes are global > addresses, can't the prefixes be: > 1) 8 octet aligned and > > 2) 8 octets (64 bits) long > > With no prefix length field. Since prefixes can be of arbitrary length (0-127 bits) [there is nothing that constrains the length for the 000/3 part of the address space, and I wouldn't be surprised if over time we relax the /64 recommendation either], the only way you can ensure that *all* the prefixes in the DNAO are 8 byte aligned is to include 16 bytes for every prefix. From an implementation perspective there aren't any benefits to ensure that some prefixes are 8 byte aligned, since you need to write code to handle the unaligned cases anyway. Up leveling, I'd expect that in the wast majority of IPv6 links, all the routers would advertise the same set of prefixes. While RFC 2461 in its generality allows for different set of prefixes being advertised by different routers, I see no operational use for this when running a stable network. When all routers advertise the same set of prefixes, DNA would never need to send a DNAO option. Thus spending a lot of complexity on trying to optimize the DNAO option layout doesn't make much sense to me. > Also, if there is a requested landmark prefix, could it not appear > in the DNA option, even if the option is does not provide complete RA? > The minimum NACK for an unknown landmark would then be 8 octets > (no prefixes in the list), on top of the existing RA. Since in the wast majority of cases there wouldn't be a DNAO, I don't see the benefits of overloading the DNAO with the landmark question/answer parts. > The solicited RAs then already have space for either a landmark or > a completeRA (DNA) Option. Each of the specifications will have > wasted space, which can be put to use for other purposes. What is the wasted space and in which case? We have 3 cases: 1. LO with "yes" answer (just the RA header + LO). 2. LO with "no" answer (RA+LO+misc options+PIOs) ["misc" being MTU etc] 3. Multicast RA (periodic and solicited): RA+misc options+PIOs and DNAO if there are any learned prefixes I don't see much wasted space in either one of them. > It's actually not one bit of information either. > > The fact that a host knows all the number of prefixes but can't fit s/host/router/>>> > them in an RA can be used to compose a complete prefix list which is > provably (with SEND) complete. At least the MN can stop hunting for new > prefixes if in the responses from two or more routers, it can see that > a conjoined (and complete) set of prefixes is available. The DT discussed whether a count of prefixes was useful when not all advertised and learned prefixes fit in one RA, but came to the conclusion that due to the prefix not being static, it actually doesn't help. The routers might at any time be reconfigured to advertise an additional prefix, one less prefix, or replace one prefix with another. Combining this with the fact that the host in question plus the N routers on the link form a distributed system, and there is no definable order of the events in a distributed system (see "Time, clocks, and the ordering of events in a distributed system" by Leslie Lamport), the DT couldn't come up with any host processing rules that would use a count of prefixes that actually worked. > I don't like the yes/no either. Did you have some technical comments, our should we switch to discussing our personal tastes and distastes :-) > Well, SEND already has better response matching than this > using its Nonce Options (which are mandatory for SEND responses). > > It's also possible to use this without SEND as detailed in: > > draft-daley-dna-nonce-resp-01.txt > > Sorry about the self plug, but I think it's a good solution. But that solves the question of making matching the RA with the RS, which isn't a problem we need to solve. The problem we need to solve with landmark is making sure that the answer applies to the question. This problem is solved in the draft by repeating the question with the answer. (A technique which is also used in the DNS protocol.) For example, if host H1 and H2 have duplicate addresses, and send the RS while being in optimistic DAD mode, then it might be that the RS sent by H2 results in a unicast RA being delivered to H1. This is harmless, since the host verifies that the question in the LO is indeed the question they asked, and if not ignore the answer. And if both hosts asked the same landmark question then H1 will happily accept the LO answer that was a result of H2 sending an RS. This never gets things wrong. A nonce scheme is making a probabilistic argument about the likelihood of the two hosts picking the same nonce, hence needs to depend on good random number generators. And with a non-zero probability it will end up with two hosts picking the same nonce. Note that using nonces in SEND is a bit different. First of all, to do security you need a good random number generator. Second, SeND doesn't fail if two hosts by chance pick the same nonce; SeND just needs to make it unlikely that a nonce value gets repeated, since it would allow an attacker to replay an old message. Erik From dna-owner@webcamserver.eng.monash.edu.au Thu May 12 22:55:47 2005 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 WAA07406 for ; Thu, 12 May 2005 22:55:45 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LO7KRURJNM94KB3K@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 13 May 2005 12:53:47 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5F1C3AB54B; Fri, 13 May 2005 12:52: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 188D44FB09; Fri, 13 May 2005 12:52:51 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4D2qFK31507 for dna-list; Fri, 13 May 2005 12:52:15 +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 j4D2qFr31503 for ; Fri, 13 May 2005 12:52:15 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LO7KQWH24O9ANHCL@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 13 May 2005 12:52:06 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8ECBF80004; Fri, 13 May 2005 12:52:05 +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 5FDBE3C005; Fri, 13 May 2005 12:52:05 +1000 (EST) Date: Fri, 13 May 2005 12:52:05 +1000 From: Greg Daley Subject: Re: [DNA] Design Team solution 1: Question about DNA Option In-reply-to: <42839B5C.7090609@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42841655.7070309@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 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <42804572.5090508@eng.monash.edu.au> <42839B5C.7090609@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, I know there are a lot of opinions expressed here. Firstly, you'll probably be aware that these are discussions of details. The general trend of the ideas in the proposal are OK to me personally, so the main thing I'm trying to see is if the solution can be simplified. Really, the minimum requirement is one method for link identification in DNA. So it's arguable that the meeting of Prefix Landmarking and CompleteRA in the proposal can be seen as an either/o choice between them. Actually, I think that they're not just aimed at reaching the same end goal (link identification), but are actually variants of each other. In prefix landmarking, an explicit question is asked: Am I here? This divulges additional information about the previous, location of the host, but implies that the host wishes to know its actual location. In Complete RA (or non-landmarked at least), an implicit question is being asked, that of: Where am I? In the movement case, both of the responses have to say "You are here". So my argument is that there's flexibility in allowing both of these, so long as the implementation cost on the router is low enough. Some of the opinions expressed are informed by current work I'm doing with the DNAPrefixList on RADVD. Once again, some of them aren't informed ;) Erik Nordmark wrote: > Greg Daley wrote: > >> from draft-pentland-dna-protocol-00.txt: >> >> Section 4.3: >> >> The learned prefixes in the DNA option are not >> 8 octet aligned, and include prefix lengths. >> >> Assuming that advertised prefixes are global >> addresses, can't the prefixes be: >> 1) 8 octet aligned and >> >> 2) 8 octets (64 bits) long >> >> With no prefix length field. > > > Since prefixes can be of arbitrary length (0-127 bits) [there is nothing > that constrains the length for the 000/3 part of the address space, and > I wouldn't be surprised if over time we relax the /64 recommendation > either], the only way you can ensure that *all* the prefixes in the DNAO > are 8 byte aligned is to include 16 bytes for every prefix. Well, 000/3 can't be autoconfigured today, and there's host code which would be broken for a while if we did so... > From an implementation perspective there aren't any benefits to ensure > that some prefixes are 8 byte aligned, since you need to write code to > handle the unaligned cases anyway. I think 8 byte alignment is required for IPv6 addresses and their components. Only DHCP doesn't do this (for legacy reasons?). So the issue is: how many octets do you want to assign to a prefix? It's clearly more than 16 octets if you want to handle the completely general case (7bit prefix len, +128 bits of prefix). Unless there's some mapping done in the first portion of the option (at least 17 octets/prefix anyway), there will be 20/24 octets per prefix. For the small number of prefixes you're likely to send in the option, it would be better to have a specially marked PIO. So, if we want to make it attractive to send additional information, keeping the size down is fairly important. 8 octets a prefix for the common case (these are autoconfigured EUI-64/3041/CGA addresses! which are bound to 64 bit). > Up leveling, I'd expect that in the wast majority of IPv6 links, all the > routers would advertise the same set of prefixes. While RFC 2461 in its > generality allows for different set of prefixes being advertised by > different routers, I see no operational use for this when running a > stable network. Other than cellular infrastructure sharing (which is theoretical)... And a router which decides not to send all prefixes in 32 octet PIOs, but wants to advertise their complete prefix set nonetheless (there's some flexibility in 2461 on this). We're not necessarily talking about disjoint prefixes anyway. We're talking about routers with incomplete lists being able to answer authoritatively about any prefix on the link (in response to a direct question, or a request for the set of prefixes). It's reasonable to assume that not every router will advertise all prefixes. > When all routers advertise the same set of prefixes, DNA would never > need to send a DNAO option. Thus spending a lot of complexity on trying > to optimize the DNAO option layout doesn't make much sense to me. Well, it doesn't really seem to be useful to de-optimize things explicitly for IIDs which aren't supported in the IPv6 Addressing Architecture, and RFC 2374. If the format of the option can easily be extended later (by leaving unallocated space, which is ignored by the receiver), existing networks could be supported easily, and fairly efficently. Since the bulk of networks for the next X years will be 64 bit PLen, either the benefits of CompleteRA have to be realized for them, or the concept of sending multiple non-PIO prefixes discarded. Here's what I'm thinking: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | OnLinkPrefs | #FixedRecs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 64 bit prefix #1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 64 bit prefix #N | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Free Space: Future Use, Ignored by receivers ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The number of fixed records (which may be zero for a NACK) and the length of the option define the length used for 64 bit prefixes (Length may be 1 and/or #fixed may be zero?) This is the basic scheme adopted with MLDv2 (rfc3810 Section 5.1.12. Additional Data, 5.2.10 Auxilliary Data), which allows future extensions without explicitly defining record types and formats for something which won't be used in the forseeable future. This has the lowest cost for a scheme which supports advertisement of autoconfigured 64-bit addresses. You could even put a note restricting the addition of prefixes to the advertisement to those which are 64-bit into the 'completeness' set. This could be updated later if needed (if 000/3 comes out?). >> Also, if there is a requested landmark prefix, could it not appear >> in the DNA option, even if the option is does not provide complete RA? >> The minimum NACK for an unknown landmark would then be 8 octets >> (no prefixes in the list), on top of the existing RA. > > Since in the wast majority of cases there wouldn't be a DNAO, I don't > see the benefits of overloading the DNAO with the landmark > question/answer parts. Well, the storage requirements for DNAO sending and Prefix Landmarks are _exactly_ the same. The questions answered are the same (except the landmark asks a different question, and the completeRA adds information if the answer is affirmative). The transmission requirements for the Landmark option in an RA match or exceed the costs of a DNA option carrying the same information. So I'd guess my idea is to have only one option, used for answering questions in solicited RAs. Whether the DNAO and Landmark can be combined, and what that means for individual prefixes is the (fairly) important part to discuss. > > The solicited RAs then already have space for either a landmark or > > a completeRA (DNA) Option. Each of the specifications will have > > wasted space, which can be put to use for other purposes. > > What is the wasted space and in which case? > We have 3 cases: > 1. LO with "yes" answer (just the RA header + LO). I think this is a premature optimization myself... After all, it is a solicited RA. The draft is asking the host to make a decision as to whether it wants to learn about movement (use an LO), or gather more prefixes (when no movement occurrs, with no LO) when sending an RS. The host shouldn't have to make that distinction. > 2. LO with "no" answer (RA+LO+misc options+PIOs) ["misc" being MTU etc] Then the DNAO (if needed) will have to be sent too. That's potentially wasteful. > 3. Multicast RA (periodic and solicited): RA+misc options+PIOs and DNAO > if there are any learned prefixes Failing to make a distinction between Solicited and Unsolicited Multicast RAs fails to help with a landmark request, which has to go out multicast. The addition of a landmark (or a PIO/DNAO) containing a response to a landmark solicitation would help lots of devices checking at the same time (at essentially only the cost of the prefix beign advertised). Also the distinction helps with solicited multicast RAs, where even if you don't want to answer all the landmark requests, you can still indicate completeness. Unsolicited Multicast RAs really don't need additional data except rarely. This is because the document assumes L2 hints on hosts. > I don't see much wasted space in either one of them. > > > It's actually not one bit of information either. > > > > The fact that a host knows all the number of prefixes but can't fit > > s/host/router/>>> Sorry, > > them in an RA can be used to compose a complete prefix list which is > > provably (with SEND) complete. At least the MN can stop hunting for new > > prefixes if in the responses from two or more routers, it can see that > > a conjoined (and complete) set of prefixes is available. > > The DT discussed whether a count of prefixes was useful when not all > advertised and learned prefixes fit in one RA, but came to the > conclusion that due to the prefix not being static, it actually doesn't > help. The routers might at any time be reconfigured to advertise an > additional prefix, one less prefix, or replace one prefix with another. > Combining this with the fact that the host in question plus the N > routers on the link form a distributed system, and there is no definable > order of the events in a distributed system (see "Time, clocks, and the > ordering of events in a distributed system" by Leslie Lamport), the DT > couldn't come up with any host processing rules that would use a count > of prefixes that actually worked. We're not talking about crossing the Internet here. The timesteps are all deltas from the original information transmitted link-locally. In the infrastructure side, where the Routers gather their prefix identities, the granularity where there would be crossover would be subsecond (assuming no loss??), on added prefixes. So the worst thing that can happen is that for a short interval, the number of advertised prefixes can be wrong. The same problem exists for CompleteRA, in that it can advertise completeness, but not include a newly introduced prefix. We've already agreed to let the worst of the prefix add and subtract issue be handled by ND and renumbering anyway, so I don't accept the argument. The essential thing about an appearing/disappearing prefix is that it doesn't last long enough in an advertisement to cause problems in a new/old network upon reallocation or link partition. The argument I'd have is that the cost of the one bit for completeness in the header of the RA is actually a lot higher than the one octet within the RA, and the absence of a DNA option (or a Landmark Option) in a DNA solicited RA is sufficient in itself to show completeness (without using up more than one bit of header), if you can match the response to the question. > > I don't like the yes/no either. > > Did you have some technical comments, our should we switch to discussing > our personal tastes and distastes :-) Elegance is a matter of taste, and of great importance in design :) Unfortunately, I often feel the shape of something before I can describe it succinctly. The problem with Yes/No in the header is that the presence or absence of something can be used to answer the same question. Showing that the question was heard (by explicit response matching), or that the response is complete in and of itself, is better IMHO than devising a separate scheme to do the job in more space, less neatly. I guess it's a matter of taste to some extent, but separation of the response matching from the identification (and the Fast RA scheme) seems straightforward to me. > > Well, SEND already has better response matching than this > > using its Nonce Options (which are mandatory for SEND responses). > > > > It's also possible to use this without SEND as detailed in: > > > > draft-daley-dna-nonce-resp-01.txt > > > > Sorry about the self plug, but I think it's a good solution. > > But that solves the question of making matching the RA with the RS, > which isn't a problem we need to solve. > > The problem we need to solve with landmark is making sure that the > answer applies to the question. This problem is solved in the draft by > repeating the question with the answer. (A technique which is also used > in the DNS protocol.) Well matching the content of the question, can either be done in-band (with the landmark option), or out-of-band by identifying the message channel. I'm not too worried about DNS. We can talk about Radius too, which uses a session ID... So long as there's some identifying state for matching the response it should work. So I guess we're actually agreed on that :) > For example, if host H1 and H2 have duplicate addresses, and send the RS > while being in optimistic DAD mode, then it might be that the RS sent by > H2 results in a unicast RA being delivered to H1. This is harmless, > since the host verifies that the question in the LO is indeed the > question they asked, and if not ignore the answer. And if both hosts > asked the same landmark question then H1 will happily accept the LO > answer that was a result of H2 sending an RS. > > This never gets things wrong. > A nonce scheme is making a probabilistic argument about the likelihood > of the two hosts picking the same nonce, hence needs to depend on good > random number generators. And with a non-zero probability it will end up > with two hosts picking the same nonce. Granted the devices may choose the same address from a broken RNG, but this is a transient problem at best (since one or both devices will leave the network anyway independent of the Router's RA response). Also, unless the devices are doing Optimistic DAD, neither would have sent a specified source address RS anyway. Optimistic DAD puts requirements on selection of addresses, based on strong randomness (RFC 1750/3041), CGA (which has strong encyption and SEND implications) or unique MAC addresses (if they're not unique we have other problems)! So I think we have a counterexample. For devices which send specified address RS's we have a good enough RNG to send Nonce Options. The Source address breaks ties for nonces which happen to collide. Greg From dna-owner@webcamserver.eng.monash.edu.au Fri May 13 05:40:56 2005 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 FAA26446 for ; Fri, 13 May 2005 05:40:55 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LO7Z07XCN294KDGW@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 13 May 2005 19:40:47 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F2F2F80005; Fri, 13 May 2005 19:40:27 +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 A59093C007; Fri, 13 May 2005 19:40:27 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4D9cIJ03456 for dna-list; Fri, 13 May 2005 19:38: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 j4D9cIr03452 for ; Fri, 13 May 2005 19:38:18 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LO7YX8QQPG972D3Y@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 13 May 2005 19:38:04 +1000 Received: by localhost (Postfix, from userid 510) id 4094EAB542; Fri, 13 May 2005 19:38:04 +1000 (EST) Received: from animal.inescn.pt (animal.inescn.pt [192.35.246.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 2C0604FB03 for ; Fri, 13 May 2005 19:37:57 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.12.10/8.12.11/24) with ESMTP id j4D9bpGL011211 for ; Fri, 13 May 2005 10:37:51 +0100 (WEST) Received: from pong.inescporto.pt (pong.inescn.pt [194.117.26.74]) by animal.inescn.pt (8.12.10/8.12.11/10) with ESMTP id j4D9benF011192 for ; Fri, 13 May 2005 10:37:41 +0100 (WEST) Received: from tamburix (tamburix.inescn.pt [194.117.26.61]) by pong.inescporto.pt (Postfix) with ESMTP id D1BD5100515 for ; Fri, 13 May 2005 10:36:56 +0100 (WEST) Date: Fri, 13 May 2005 10:37:35 +0100 From: Rui Campos Subject: [DNA] Question about DNAv6 Internet Draft Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <20050513093656.D1BD5100515@pong.inescporto.pt> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: multipart/alternative; boundary="Boundary_(ID_Il48qumigCLBdHs763lCMg)" Thread-Index: AcVXn2TnLAWUASCBRb6TpyQu2s8ryg== X-Virus-Scanned: by amavisd-new at inescporto.pt X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) This is a multi-part message in MIME format. --Boundary_(ID_Il48qumigCLBdHs763lCMg) Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Hi all, I have been reading the DNAv6 I-D and I have a doubt: What are the possible events triggering the DNAv6 process? I am aware of "link up" notifications. Are there others? Thanks in advance for your answer! BR, Rui Campos --Boundary_(ID_Il48qumigCLBdHs763lCMg) Content-type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7BIT

Hi all,

 

I have been reading the DNAv6 I-D and I have a doubt: What are the possible events triggering the DNAv6 process? I am aware of “link up” notifications. Are there others?

 

Thanks in advance for your answer!

 

BR,

Rui Campos

--Boundary_(ID_Il48qumigCLBdHs763lCMg)-- From dna-owner@webcamserver.eng.monash.edu.au Sat May 14 09:17:50 2005 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 JAA01473 for ; Sat, 14 May 2005 09:17:49 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LO9KVOZPBI9ANIKW@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 14 May 2005 23:17:37 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7832AAB545; Sat, 14 May 2005 23:17:32 +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 33EDC4FB06; Sat, 14 May 2005 23:17:32 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4EDEL821041 for dna-list; Sat, 14 May 2005 23:14:21 +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 j4EDEKr21037 for ; Sat, 14 May 2005 23:14:20 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LO9KRI7EHQ9ANIKW@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 14 May 2005 23:14:10 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E58E180002; Sat, 14 May 2005 23:14:09 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id D05073C00B; Sat, 14 May 2005 23:14:09 +1000 (EST) Received: from [211.28.113.203] by mail-store-2.its.monash.edu.au (mshttpd) ; Sat, 14 May 2005 23:14:09 +1000 Date: Sat, 14 May 2005 23:14:09 +1000 From: Greg Daley Subject: Re: [DNA] Question about DNAv6 Internet Draft Sender: owner-dna@ecselists.eng.monash.edu.au To: Rui Campos Cc: dna@eng.monash.edu.au Message-id: <18987319027c.19027c189873@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 Patch 2 (built Jul 14 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Rui, ----- Original Message ----- From: Rui Campos Date: Friday, May 13, 2005 7:37 pm Subject: [DNA] Question about DNAv6 Internet Draft > Hi all, > > > > I have been reading the DNAv6 I-D and I have a doubt: What are the > possibleevents triggering the DNAv6 process? I am aware of "link > up" notifications. > Are there others? Other people may have a more comprehensive answer. draft-ietf-dna-hosts-00.txt describes roughly the initiation procedurs for DNA. It talks about: Internal (network layer) timers, transport layer notifications, link-layer notifications, and unexpected packet reception (RA reception). There are lots of warnings about handling external information though, because of security issues. If this needs to be more explicit please tell us: We want that section to be useful. Greg From dna-owner@webcamserver.eng.monash.edu.au Sat May 14 13:37:37 2005 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 NAA21761 for ; Sat, 14 May 2005 13:37:36 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LO9TXLRJVK972K7C@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sun, 15 May 2005 03:37:26 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 27A7BAB545; Sun, 15 May 2005 03:37:10 +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 943694FB05; Sun, 15 May 2005 03:37:08 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4EHaPk23891 for dna-list; Sun, 15 May 2005 03:36:25 +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 j4EHaOr23887 for ; Sun, 15 May 2005 03:36:24 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LO9TWCDFCM9ANFKK@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sun, 15 May 2005 03:36:09 +1000 Received: by localhost (Postfix, from userid 510) id 55A9180002; Sun, 15 May 2005 03:36:09 +1000 (EST) Received: from animal.inescn.pt (ns.inescn.pt [192.35.246.1]) (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 4382F3C00B; Sun, 15 May 2005 03:36:05 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.12.10/8.12.11/24) with ESMTP id j4EHZrGL019996; Sat, 14 May 2005 18:35:53 +0100 (WEST) Received: from pong.inescporto.pt (pong.inescn.pt [194.117.26.74]) by animal.inescn.pt (8.12.10/8.12.11/10) with ESMTP id j4EHWMnF019904; Sat, 14 May 2005 18:32:23 +0100 (WEST) Received: by pong.inescporto.pt (Postfix, from userid 33) id C4AA4627B5; Sat, 14 May 2005 18:31:35 +0100 (WEST) Received: from 82.154.123.231 (SquirrelMail authenticated user rcampos) by telecom.inescporto.pt with HTTP; Sat, 14 May 2005 18:31:35 +0100 (WEST) Date: Sat, 14 May 2005 18:31:35 +0100 (WEST) From: rcampos@inescporto.pt Subject: Re: [DNA] Question about DNAv6 Internet Draft In-reply-to: <18987319027c.19027c189873@monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: Rui Campos , dna@eng.monash.edu.au Message-id: <1298.82.154.123.231.1116091895.squirrel@telecom.inescporto.pt> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) User-Agent: SquirrelMail/1.4.4 X-Virus-Scanned: by amavisd-new at inescporto.pt X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <18987319027c.19027c189873@monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, Thank very much for your reply and informations! I will read that Internet Draft then! BR, Rui Campos > Hi Rui, > > ----- Original Message ----- > From: Rui Campos > Date: Friday, May 13, 2005 7:37 pm > Subject: [DNA] Question about DNAv6 Internet Draft > >> Hi all, >> >> >> >> I have been reading the DNAv6 I-D and I have a doubt: What are the >> possibleevents triggering the DNAv6 process? I am aware of "link >> up" notifications. >> Are there others? > > Other people may have a more comprehensive answer. > > draft-ietf-dna-hosts-00.txt describes roughly the > initiation procedurs for DNA. It talks about: > Internal (network layer) timers, transport layer notifications, > link-layer notifications, and unexpected packet reception > (RA reception). > > There are lots of warnings about handling external information > though, because of security issues. > > If this needs to be more explicit please tell us: > We want that section to be useful. > > Greg > > From dna-owner@webcamserver.eng.monash.edu.au Wed May 18 19:07:21 2005 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 TAA03806 for ; Wed, 18 May 2005 19:07:19 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOFQMGHSRG973KLM@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 19 May 2005 09:06:52 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B165AAB546; Thu, 19 May 2005 09:06:38 +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 68F614FB02; Thu, 19 May 2005 09:06:38 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4IN5GX29199 for dna-list; Thu, 19 May 2005 09:05:16 +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 j4IN5Fr29195 for ; Thu, 19 May 2005 09:05:15 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOFQKIAU3A9ANMSK@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 19 May 2005 09:05:04 +1000 Received: by localhost (Postfix, from userid 510) id 949DAAB546; Thu, 19 May 2005 09:05:04 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by curly.its.monash.edu.au (Postfix) with ESMTP id CD3194FB02 for ; Thu, 19 May 2005 09:05:02 +1000 (EST) 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 <0IGP00BVMK4CSE@mailout1.samsung.com> for dna@eng.monash.edu.au; Thu, 19 May 2005 08:05:00 +0900 (KST) Received: from Alperyegin ([105.253.155.25]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IGP000E2K48QV@mmp1.samsung.com> for dna@eng.monash.edu.au; Thu, 19 May 2005 08:05:00 +0900 (KST) Date: Wed, 18 May 2005 16:04:07 -0700 From: Alper Yegin Subject: [DNA] RE: (forward) Review of Link-information In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: aboba@internaut.com Cc: dna@eng.monash.edu.au Message-id: <039e01c55bfd$e725b9f0$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Hi Bernard, Thanks for the comments. Please see below for my response. > > Here you go. My comments denoted with [BA]. > > > ------------------------------------------------------------------------ - > Review of draft-ietf-dna-link-information-01.txt > > [BA] Overall, my take is that this document does not clearly > distinguish > Link Establishment/Termination events from "Up"/"Down" link state > changes. > As I understand it, DNA cares mostly about Link Establishment events, > not > about whether a link is encountering low or high frame loss at a given > instant. In DNA, bi-directional reachability at the IP layer > determines whether a link is suitable for use, so that link quality > monitoring is not required. Link up is meant to reflect Link Establishment, and Link Down is for Link Termination. I'll make sure to clarify this in the document. > > It is important for the document to clarify the usage of terms, since > the > definition of the "Up" and "Down" link states can be somewhat murky in > wireless networks. Please see: "The Mistaken Axioms of Wireless Network > Research": > http://www.pdos.lcs.mit.edu/decouto/papers/kotz03.pdf > > 1. Introduction > > " The changes on the underlying link-layer status can be relayed to > IP > in the form of link-layer event notifications. Establishment and > tear down of a link-layer connection are two basic events types." > > [BA] I think you are referring to explicit messages resulting in > establishment (e.g. PPP IPCP) or teardown (PPP LCP-terminate) of the > link-layer. However, in wireless technologies the mobile node can > wander > out of range or suffer from high frame loss for other reasons; in > these > cases there can be links in intermediate states between "up" (low loss) > and "down" (high loss). The distinction between link > establishment/teardown events and the link state is an important one. These intermediate states are not as interesting to DNA, as they do not change the IP configuration. They make the current configuration not useful (e.g., no IP packets received), but that does not call for changing the configuration. I'll clarify this in the document as well. > "Additional information can be conveyed in addition to the event > type, > such as the identifier of the network attachment point, or > network-layer configuration parameters obtained via the link-layer > attachment process." > > [BA] By identifier I assume you mean MAC layer address, no? Of are you > referring perhaps to "network identifiers" such as SSID? Both are possible, depending on the technology. But since they are not used in this document, I have not got into the details of what they might be. But I guess I can give these as examples, good idea. > I would add > "if available" to the end of the sentence, since some link technologies > do not provide network-layer configuration. OK, will do. > > For example, the > notification indicating that the node has established a new > link-layer connection can be used for immediately probing the > network > for a possible configuration change. In the absence of such a > notification from the link-layer, IP has to wait for indications > that > are not immediately available, such as receipt of next scheduled > router advertisement, unreachability of the default gateway, etc. > > [BA] This seems to imply that assignment of a new address via PPP IPCP > (an event) would need to be "confirmed" by DNA. I'll soften the text to make sure reader don't think confirmation is always done. PPP is a good example when it is not needed. > The current DNAv4 spec > assumes that this is not necessary; essentially the bi-directional > reachability established via PPP IPCP is "good enough" to not require > an additional demonstration of default gateway reachability. > > " Two basic link-layer events are considered potentially useful to DNA > process: link up and link down. Both of these events are > deterministic, and their notifications are provided to IP-layer > after > the events successfully conclude." > > [BA] The "Up" and "Down" link states are only determinstic on wired > networks. On wireless networks, frame loss can be intermediate between > the "up" and "down" states, so that link state indications may not be > reliable. OK. > > Node's establishment of a link-layer connection with an attachment > point that signifies the availability of IP service (i.e., being > able > to send and receive IP packets) between the two is considered a link > up event. > > [BA] I think we need to distinguish changes in link state due to frame > loss from "Link Establishment" and "Link Termination" events. As used > in this document I am not clear whether "Link Up" refers to the state > of the link or whether we are really talking about a "Link > Establishment" > event. For example, a link can be established, and then experience high > frame loss (e.g. mobile node wanders out of range). Does this then > constitute a "Link Down" event, followed by a "Link Up" event when > frame loss becomes low again? For the purposes of DNA, don't we > only need to care about "Link Establishment" events (not even > "Link Termination")? Yes, and I will take care of this. > > [TO-DO: How about ad-hoc networks? Attached neighbors may be > considered attachment points]. > > [BA] Adhoc networks are tricky because each adjacency is a "link" which > may be in an intermediate state between "up" and "down". Also, there > may not be a clearly delineated point at which IP traffic can be sent. > For example, in 802.11 adhoc it is possible to send data frames with > "For DS" and "To DS" both set to zero, even in state 1 (unassociated, > unauthenticated). Given this, when is the link "established"? One > view could be that it is only established when the destination is > enabled to forward packets to other nodes. This is really tricky... What would you recommend we do about this? > By the time the notification is > delivered, the link-layer of the node must be ready to accept IP > packets from the IP and the physical-layers. > > [BA] This sentence and other text related to specific link technologies > leads me to believe that "Link Up" as used in this document refers to a > "Link Establishment" event, rather than the link state. Is that right? Yes. > > Link down event signifies the discontinuation of the IP service > between the node and the attachment point. When the link-layer > connection is physically or logically torn down and it can no longer > carry IP packets, this is considered to be a link down event. > > [BA] Here you are mixing "Link Termination" events with the "down" > link state. There may be no explicit teardown event. A node may > wander out of range, or may experience multi-path interference, causing > high loss. In the absence of an explicit tear-down, the MAC layer should have some timeout mechanism to locally decide the link is terminated. That should generate the link down notification. > > Among these two events the first one to take place after an > interface > becomes enabled must be a link up event. During the time a network > interface is enabled, it may go through a series of link up and down > events. Each time the interface changes its point of attachment, a > link down event with the previous attachment point must be followed > by a link up event with the new one. > > [BA] The problem is that in some implementations the "Link Down" event > may (mistakenly) result in teardown of TCP connections. As a result, > only > a series of "Link Establishment" messages are seen. I didn't understand how what TCP does relates to lost "link downs"? These event notifications are generated by L2, consumed by L3. > Also in the above > paragraph I am not clear if you are talking about the up/down link > states > or explicit establishment/termination events. > > Furthermore, IP-layer configuration > parameters obtained during link-layer connection may be exactly what > the DNA process is trying to discover (e.g., IP address configured > during PPP link establishment). > > [BA] This confuses me. Why would DNA need to be invoked in the case > where the network configuration is set by the link layer? The DNA process can subscribe to L2 event notifications on all interfaces available. On a PPP interface, it does not have to really perform much "DNA" for the reasons discussed above (NULL operation). Nevertheless, DNA process can be the central module that has a system-level view of the interfaces and connectivity. > > 3GPP2 networks use the Point-to-Point Protocol (PPP [RFC1661]) as > the > link-layer protocol between the MS and the PDSN. Before any IP > packets may be sent or received, PPP must reach the Network-Layer > Protocol phase, and the IP Control Protocol (IPCP [RFC1332], IPV6CP > [RFC2472]) reach the Opened state. When these states are reached in > PPP, a link up event notification must be delivered to the IP-layer. > > [BA] It is also true that most hosts interface to GPRS/EDGE/UMTS > networks > via PPP as well. So the statement above seems more general, and you > might > include a subsection on PPP early on, then reference it. The 3GPP text is not discussing PPP at all. It's built around the PDP context. As I understand, PDP is in fact implemented using PPP. I thought it is better to keep the discussion as high-level as possible (i.e., talking PDP instead of PPP). For that, 3GPP2 is the only place detailed PPP discussion is taking place for now. > > Since there is no > standards-mandated correlation between the interface-identifier and > other IP-layer configuration parameters, this information is deemed > not useful for DNA (hence it is not provided as auxiliary > information). > > [BA] Saying it is useful for DNA is not the same as saying it is not > provided. Since the information may be used, it does need to be > available > to the Internet layer. OK, I'll fix that. > > 2.3 IEEE 802.11/WiFi > > A STA must establish a IEEE > 802.11 link with an AP in order to send and receive IP packets. In > a > WiFi network that supports Robust Secure Network (RSN > [IEEE-802.11i]), successful completion of 4-way handshake between > the > STA and AP commences the availability of IP service. The link up > event notification must be generated upon this event. In > non-RSN-based networks, successful association or re-association > events on the link-layer must cause a link up notification sent to > the IP-layer. > > As part of the link establishment, Basic Service Set Identification > (BSSID) and Service Set Identifier (SSID) associated with the AP is > learned by the STA. BSSID is a unique identifier of the AP. Its > value is set to the MAC address of the AP. > > [BA] I would delete the last sentence; an AP may have multiple MAC > addresses (e.g. on the wired side and on the wireless side). I see, OK. > > In ad-hoc mode, mobile station (STA) in range may directly > communicate with others, i.e., without any infrastructure or > intermediate hop. The set of communicating STAs is called IBSS for > Indepedant Basic Service Set. In an IBSS, only station services are > > Indepedant -> Independent > > available, i.e. authentication, deauthentication, privacy and MSDU > delivery. STAs do not associate with each other, and therefore may > exchange data frames in state 2 (authenticated and not associated) > or > even in state 1 (unauthenticated and unassociated) if authentication > is not used. > > [BA] They can exchange data frames in state 1 only if "To DS" and "From > DS" bits are clear. This is not dependent on authentication (e.g. > State > 1, not State 2). I'd need to ask co-author Nicolas to look at this. I'm not too familiar with these details. > > Although a link up indication can be generated upon > authentication, one may not be present per latter usage. If > authentication is performed, a deauthentication event is used for > generating the link down indication. Concerning the link layer > identification, both the BSSID (which is a random MAC address chosen > by a STA of the IBSS) and SSID may be used to identify a link, but > not to make any assumptions on the IP network configuration. > > [BA] This is a reasonable guess at how it should work, but I'm not > clear > that it is strictly correct. If the goal is only for two nodes to > exchange data frames, this can occur in State 1 without authentication. > So if the packets can be exchanged, the link can be "up". Without > explicit link establishment, whether the link is "up" or "down" becomes > dependent on the frame loss, which is non-deterministic. > > To clear this up, you might ask Bob O'Hara, editor of 802.11ma. I'm deferring this to Nicolas as well. > > [IEEE-802.11i] > Institute of Electrical and Electronics Engineers, "Draft > Supplement to STANDARD FOR Telecommunications and > Information Exchange between Systems - LAN/MAN Specific > Requirements - Part 11: Wireless Medium Access Control > (MAC) and physical layer (PHY) specifications: > Specification for Enhanced Security", IEEE Draft 802.11I/ > D8, February 2004. > > [BA] This document is final now. Thanks for the useful comments. We'll incorporate them to the next rev. Alper From dna-owner@webcamserver.eng.monash.edu.au Sat May 21 08:13:44 2005 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 IAA11448 for ; Sat, 21 May 2005 08:13:43 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOIQ13F00W9ANPS0@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 21 May 2005 12:21:49 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EE7DF80002; Sat, 21 May 2005 12:21:47 +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 90A413C009; Sat, 21 May 2005 12:21:47 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4L2Kh429429 for dna-list; Sat, 21 May 2005 12:20:43 +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 j4L2Kgr29425 for ; Sat, 21 May 2005 12:20:42 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOIPYKD9329ANPS0@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 21 May 2005 12:20:32 +1000 Received: by localhost (Postfix, from userid 510) id 9D55BAB543; Sat, 21 May 2005 12:20:32 +1000 (EST) Received: from [192.168.1.2] (cust1648.vic01.dataco.com.au [202.63.56.112]) (user brett) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 0BA894FB04; Sat, 21 May 2005 12:20:31 +1000 (EST) Date: Sat, 21 May 2005 12:20:35 +1000 From: Brett Pentland Subject: [DNA] Interactions with DHCPv6 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <428E9AF3.7080202@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Hi folks, Section 18.1.2 of RFC 3315 (DHCPv6) contains a DNA procedure. How this interacts with any proposed solution for DNA (including the BCP documents) needs to be considered. The DT has started discussing this over the last day or so and I have pasted that thread into an issue with the proposal we submitted a few weeks ago. This can be found at: http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNASoln1Issue017 All comment appreciated. Cheers, Brett. From dna-owner@webcamserver.eng.monash.edu.au Sun May 22 22:23:14 2005 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 WAA29525 for ; Sun, 22 May 2005 22:23:13 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOLIMPW0CQ99ILZQ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 23 May 2005 12:22:38 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5FB2EAB545; Mon, 23 May 2005 12:22:32 +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 F16854FB0A; Mon, 23 May 2005 12:22:31 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4N2LLJ31143 for dna-list; Mon, 23 May 2005 12:21:21 +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 j4N2LKr31139 for ; Mon, 23 May 2005 12:21:20 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOLIL4KJAK94MKNY@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 23 May 2005 12:21:19 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 90AECAB543; Mon, 23 May 2005 12:21:15 +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 6E8B04FB11; Mon, 23 May 2005 12:21:15 +1000 (EST) Date: Mon, 23 May 2005 12:21:10 +1000 From: Greg Daley Subject: [DNA] DNAO format revision? Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au, Erik Nordmark Reply-to: greg.daley@eng.monash.edu.au Message-id: <42913E16.4020600@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 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Hi DNA, I've been talking to Erik and most of my questions regarding the DNA proposal have been answered. What I'd like to do now is to ask questions about message formats and text, in a way which reinforces the hard work undertaken by the DT. Here's Q number 1: Is there a DNA option format which we can agree upon which preserves Prefix alignment on 8 octet boundaries? I guess alignment is desirable to allow consistency with earlier specifications 2461, 3810, and potentially allow word-size based operations on some hosts. At the moment, the option format contains a list of sequential 17 octet records. With 2 prefixes, the current format is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Len 1 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | | + Prefix 1 + | | + +-+-+-+-+-+-+-+-+ | | Prefix Len 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix 2 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (32bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Erik has convinced me of the need to support 128 bit prefixes in DNA, for future expansion, but it may be possible to achieve this while preserving alignment. One variant makes use of the ordering of prefixes and their lengths but uses two separate lists (one for the lengths and one for the prefixes. Pad is introduced at the end of the list of prefix lengths, instead of at the end of the option. I'll call this Variant #1: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Len 1 | Prefix Len 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (32bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix 1 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix 2 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It's also possible to have differing storage for prefixes, so long as it is 8 octet aligned: The differing legnths of prefix mean that a number of prefixes indication is required a the front of the prefix length list, to remove ambiguity (it's not inferred just by the option length). I'll call this variant 2: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | # prefixes | Prefix Len 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Len 2 | Padding (24 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix 1 (128 bits) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Prefix 2 (64bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Variant 1 (along with the current option format) has the advantage that records are constant length, and that the prefix lengths don't have to be read in order to locate any particular prefix. Variant 2 has the advantage that if the prefix length is less than or equal to 64 (today's common case), the storage used is only 8 bytes. A host would have to read the list of prefix lengths in order to parse the prefixes though. Does anyone have an opinion as to whether a change to the DNA option would be good or not? Please respond indicating if you like any of the existing proposals (Current, Variant 1 or Variant 2), or prefer something different. Greg From dna-owner@webcamserver.eng.monash.edu.au Mon May 23 01:50:29 2005 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 BAA29628 for ; Mon, 23 May 2005 01:50:27 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOLPUA3L6G9ANQ4I@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 23 May 2005 15:49:33 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B2EB5AB545; Mon, 23 May 2005 15:49:27 +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 2A48A4FB18; Mon, 23 May 2005 15:49:27 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4N5muC00854 for dna-list; Mon, 23 May 2005 15:48:56 +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 j4N5mtr00850 for ; Mon, 23 May 2005 15:48:55 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOLPTD3T249ANQ4I@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 23 May 2005 15:48:43 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7EB33AB542 for ; Mon, 23 May 2005 15:48:43 +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 56C634FB0D for ; Mon, 23 May 2005 15:48:43 +1000 (EST) Date: Mon, 23 May 2005 15:48:43 +1000 From: Greg Daley Subject: [DNA] Ordering Hash-based RAs Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42916EBB.3060506@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 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Content-Transfer-Encoding: 7BIT Dear DT, I really like the hash based RA scheme indicated in the document draft-pentland-dna-protocol-00. I think there's an issue with its robustness to false or hijacking routers, which may limit its usefulness though. The text presented allows a particular router to select an interface identifier such that its SHA-1 hash will XOR with the solicitor's received IID to provide the fastest ranked response with high likelihood? This is because the hijacking router knows the other Router's addresses and their SHA-1 hashes. It can precompute a hash likely to XOR with the lowest value. That is: it can generate a hash with all leading zeros, by repeated computation of SHA-1 with different link-local addresses. With existing EUI-64 addresses, the high order bits of the IPv6 IID aren't well distributed. In fact, there's a likelihood that the seven of the first 8 bits of the IID will be zero. Considering that, the XOR will be lowest if the first few bits in the usurping router's SHA-1 hash are zero. In this way, a router has to perform O(2^zeros) SHA-1 computations in order to find out a valid IID for generating a sequence of leading zeros for the hash. Link-local addresses with known low hashes could even be precomputed. The essential issue here is that the solicitors' addresses aren't well distributed. Two alternatives which overcome this issue are: 1) Perform the XOR comparison with the low order bytes of the IID first (either reverse the XORed bit strings, or do bytewise comparisons starting at the 16th byte). 2) Ensure that the solicitors' input values are well distributed, perhaps using a hash. I'd lean towards 1). It's probably fastest computationally, and was easy to implement in 16th-to 1st byte comparison form. Please let me know what you think... Greg From dna-owner@webcamserver.eng.monash.edu.au Mon May 23 02:10:45 2005 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 CAA11132 for ; Mon, 23 May 2005 02:10:44 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOLQL8SU729ANPD5@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 23 May 2005 16:10:28 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2D291AB548; Mon, 23 May 2005 16:10:25 +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 CFD5F4FB07; Mon, 23 May 2005 16:10:24 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4N6AFh01132 for dna-list; Mon, 23 May 2005 16:10:15 +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 j4N6AEr01128 for ; Mon, 23 May 2005 16:10:14 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOLQKVVMZK974NZ5@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 23 May 2005 16:10:08 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CBB53AB54B; Mon, 23 May 2005 16:10:07 +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 curly.its.monash.edu.au (Postfix) with ESMTP id 777AC4FB02; Mon, 23 May 2005 16:10:07 +1000 (EST) Date: Mon, 23 May 2005 16:10:07 +1000 From: Brett Pentland Subject: Re: [DNA] DNAO format revision? In-reply-to: <42913E16.4020600@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au, Erik Nordmark Message-id: <429173BF.1010709@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) References: <42913E16.4020600@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, We started discussing the DNA option format, but didn't settle on a fix before needing to get the document out to the WG. I think either of these options would be an improvement. Variant 2 would save quite a few bytes in the common case where 64-bit prefixes are used. I'd be in favour of it. Brett. Greg Daley wrote: > Hi DNA, > > I've been talking to Erik and most of my questions regarding > the DNA proposal have been answered. > > What I'd like to do now is to ask questions about message > formats and text, in a way which reinforces the hard work > undertaken by the DT. > > > Here's Q number 1: > > Is there a DNA option format which we can agree upon which > preserves Prefix alignment on 8 octet boundaries? > > I guess alignment is desirable to allow consistency with > earlier specifications 2461, 3810, and potentially allow > word-size based operations on some hosts. > > At the moment, the option format contains a list of > sequential 17 octet records. > > With 2 prefixes, the current format is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Prefix Len 1 | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + > | | > + + > | | > + Prefix 1 + > | | > + +-+-+-+-+-+-+-+-+ > | | Prefix Len 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Prefix 2 + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Padding (32bits) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > Erik has convinced me of the need to support 128 bit > prefixes in DNA, for future expansion, but it may be > possible to achieve this while preserving alignment. > > > One variant makes use of the ordering of prefixes and > their lengths but uses two separate lists (one for > the lengths and one for the prefixes. Pad is introduced > at the end of the list of prefix lengths, instead > of at the end of the option. > > I'll call this Variant #1: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Prefix Len 1 | Prefix Len 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Padding (32bits) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Prefix 1 + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Prefix 2 + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > It's also possible to have differing storage for > prefixes, so long as it is 8 octet aligned: > > The differing legnths of prefix mean that a number of prefixes > indication is required a the front of the prefix length list, > to remove ambiguity (it's not inferred just by the option length). > > I'll call this variant 2: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | # prefixes | Prefix Len 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix Len 2 | Padding (24 bits) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Prefix 1 (128 bits) + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Prefix 2 (64bits) + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Variant 1 (along with the current option format) has > the advantage that records are constant length, and that > the prefix lengths don't have to be read in order to > locate any particular prefix. > > Variant 2 has the advantage that if the prefix length is > less than or equal to 64 (today's common case), the > storage used is only 8 bytes. A host would have to read > the list of prefix lengths in order to parse the prefixes though. > > Does anyone have an opinion as to whether a change to the > DNA option would be good or not? > > Please respond indicating if you like any of the > existing proposals (Current, Variant 1 or Variant 2), > or prefer something different. > > Greg From dna-owner@webcamserver.eng.monash.edu.au Mon May 23 02:26:30 2005 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 CAA22667 for ; Mon, 23 May 2005 02:26:29 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOLR3XCSDI94MABY@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 23 May 2005 16:25:43 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C762DAB54D; Mon, 23 May 2005 16:25:28 +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 80A0B4FB02; Mon, 23 May 2005 16:25:28 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4N6PGs01340 for dna-list; Mon, 23 May 2005 16:25:16 +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 j4N6PFr01336 for ; Mon, 23 May 2005 16:25:15 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOLR3IZJ0I99IQFQ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 23 May 2005 16:25:09 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A7ADDAB542; Mon, 23 May 2005 16:25: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 curly.its.monash.edu.au (Postfix) with ESMTP id 808E44FB05; Mon, 23 May 2005 16:25:09 +1000 (EST) Date: Mon, 23 May 2005 16:25:09 +1000 From: Brett Pentland Subject: Re: [DNA] Ordering Hash-based RAs In-reply-to: <42916EBB.3060506@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <42917745.3050901@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) References: <42916EBB.3060506@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > Dear DT, > > I really like the hash based RA scheme indicated in the > document draft-pentland-dna-protocol-00. :) That's good to hear. > I think there's an issue with its robustness to false > or hijacking routers, which may limit its usefulness though. Aside: There will be many things that rogue devices can do to disrupt things if SEND is not used. If SEND is used then I don't think the following scenario is a problem, however... > The text presented allows a particular router to select an > interface identifier such that its SHA-1 hash will XOR with > the solicitor's received IID to provide the fastest ranked > response with high likelihood? > > This is because the hijacking router knows the other Router's > addresses and their SHA-1 hashes. It can precompute a hash likely > to XOR with the lowest value. That is: it can generate a hash with > all leading zeros, by repeated computation of SHA-1 with different > link-local addresses. > > With existing EUI-64 addresses, the high order bits of the > IPv6 IID aren't well distributed. In fact, there's a likelihood > that the seven of the first 8 bits of the IID will be zero. > > Considering that, the XOR will be lowest if the first few bits in the > usurping router's SHA-1 hash are zero. > > In this way, a router has to perform O(2^zeros) SHA-1 computations > in order to find out a valid IID for generating a sequence of > leading zeros for the hash. > > Link-local addresses with known low hashes could even be precomputed. > > The essential issue here is that the solicitors' addresses aren't > well distributed. Agreed. > Two alternatives which overcome this issue are: > > 1) Perform the XOR comparison with the low order bytes of the IID > first (either reverse the XORed bit strings, or do bytewise > comparisons starting at the 16th byte). > > 2) Ensure that the solicitors' input values are well distributed, > perhaps using a hash. > > I'd lean towards 1). It's probably fastest computationally, and > was easy to implement in 16th-to 1st byte comparison form. I'd also lean towards 1) since it doesn't require calculating a hash for each RS received. Doing the bytewise comparison starting at the low order byte (the 8th since there's only 64 bits in the IID) sounds like the better option to me, and sounds worth doing. Cheers, Brett. From dna-owner@webcamserver.eng.monash.edu.au Mon May 23 12:06:14 2005 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 MAA09665 for ; Mon, 23 May 2005 12:06:13 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOMBCSHROW9ANQKU@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 24 May 2005 02:05:19 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7DE95AB543; Tue, 24 May 2005 02:05:17 +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 1EE9A4FB06; Tue, 24 May 2005 02:05:17 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4NG4ag07393 for dna-list; Tue, 24 May 2005 02:04:36 +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 j4NG4Zr07389 for ; Tue, 24 May 2005 02:04:35 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOMBBP712U9756XR@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 24 May 2005 02:04:25 +1000 Received: by localhost (Postfix, from userid 510) id C526CAB543; Tue, 24 May 2005 02:04:24 +1000 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by curly.its.monash.edu.au (Postfix) with ESMTP id 1E0214FB07; Tue, 24 May 2005 02:04:22 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j4NG4LGJ027750; Mon, 23 May 2005 09:04:22 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j4NG4JBi990046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 23 May 2005 09:04:21 -0700 (PDT) Date: Mon, 23 May 2005 09:07:09 -0700 From: Erik Nordmark Subject: Re: [DNA] DNAO format revision? In-reply-to: <42913E16.4020600@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <4291FFAD.1070408@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 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <42913E16.4020600@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > Please respond indicating if you like any of the > existing proposals (Current, Variant 1 or Variant 2), > or prefer something different. I think either one is an improvement over the current one in the draft. Whether we want the smaller #2 option (with a bit more complexity) depends on how important we think it is to minimize the size of the DNAO. The DNAO is only sent by a routers when not all routers on the link are configured to advertise the same set of prefixes. However, RFC 2461 does allow that the routers advertise different sets of prefixes. I'd suspect that in all well-run IPv6 networks the routers advertise the same set of prefixes (so that they all can be backups for each other). So optimizing the size of the DNAO might not be terribly important. But I don't have a problem with format #2 - just questioning the necessity of minimizing something which might not be used much in the real world (but is mostly there to deal with the - perhaps unnecessary - generality in RFC 2461). Erik From dna-owner@webcamserver.eng.monash.edu.au Mon May 23 12:18:11 2005 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 MAA10651 for ; Mon, 23 May 2005 12:18:10 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOMBR1UPQM9722SD@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 24 May 2005 02:17:02 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4EB61AB54A; Tue, 24 May 2005 02:16: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 093394FB03; Tue, 24 May 2005 02:16:47 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4NGGcS07565 for dna-list; Tue, 24 May 2005 02:16: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 j4NGGcr07561 for ; Tue, 24 May 2005 02:16:38 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOMBQQZ7RG94LSM7@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 24 May 2005 02:16:34 +1000 Received: by localhost (Postfix, from userid 510) id 9E234AB542; Tue, 24 May 2005 02:16:32 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id B74294FB03; Tue, 24 May 2005 02:16:30 +1000 (EST) Date: Mon, 23 May 2005 09:17:37 -0700 From: James Kempf Subject: Re: [DNA] Interactions with DHCPv6 Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland , dna@eng.monash.edu.au Message-id: <006101c55fb2$f207c4e0$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <428E9AF3.7080202@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, I can't think of any case where CONFIRM would come up with a diffferent answer from DNA. I think the DNA spec ought to say that DHCP CONFIRM isn't necessary if DNA confirms that the host is still on-link. Unfortunately, RFC 3315 says MUST, so the statement will probably have to be phrased as SHOULD or MAY until the DHCP spec changed is changed. jak ----- Original Message ----- From: "Brett Pentland" To: Sent: Friday, May 20, 2005 7:20 PM Subject: [DNA] Interactions with DHCPv6 > Hi folks, > > Section 18.1.2 of RFC 3315 (DHCPv6) contains a DNA procedure. > How this interacts with any proposed solution for DNA > (including the BCP documents) needs to be considered. > > The DT has started discussing this over the last day or so > and I have pasted that thread into an issue with the > proposal we submitted a few weeks ago. This can be found at: > > http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNASoln1Issue017 > > All comment appreciated. > Cheers, > Brett. > From dna-owner@webcamserver.eng.monash.edu.au Mon May 23 12:30:13 2005 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 MAA11445 for ; Mon, 23 May 2005 12:30:12 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOMC7CCBQU94I1JJ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 24 May 2005 02:29:26 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 77BAFAB544; Tue, 24 May 2005 02:29:08 +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 23E5D4FB0E; Tue, 24 May 2005 02:29:08 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4NGSxH07725 for dna-list; Tue, 24 May 2005 02:28:59 +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 j4NGSwr07721 for ; Tue, 24 May 2005 02:28:58 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOMC71J32Q99ISHD@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 24 May 2005 02:28:54 +1000 Received: by localhost (Postfix, from userid 510) id 120FAAB543; Tue, 24 May 2005 02:28:54 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id 1B4B34FB02; Tue, 24 May 2005 02:28:52 +1000 (EST) Date: Mon, 23 May 2005 09:30:00 -0700 From: James Kempf Subject: Re: [DNA] Ordering Hash-based RAs Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland , greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <009901c55fb4$ad740120$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <42916EBB.3060506@eng.monash.edu.au> <42917745.3050901@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT 1 sounds fine. jak ----- Original Message ----- From: "Brett Pentland" To: Cc: Sent: Sunday, May 22, 2005 11:25 PM Subject: Re: [DNA] Ordering Hash-based RAs > Greg Daley wrote: > > Dear DT, > > > > I really like the hash based RA scheme indicated in the > > document draft-pentland-dna-protocol-00. > > :) That's good to hear. > > > I think there's an issue with its robustness to false > > or hijacking routers, which may limit its usefulness though. > > Aside: There will be many things that rogue devices can do to > disrupt things if SEND is not used. If SEND is used then I don't > think the following scenario is a problem, however... > > > The text presented allows a particular router to select an > > interface identifier such that its SHA-1 hash will XOR with > > the solicitor's received IID to provide the fastest ranked > > response with high likelihood? > > > > This is because the hijacking router knows the other Router's > > addresses and their SHA-1 hashes. It can precompute a hash likely > > to XOR with the lowest value. That is: it can generate a hash with > > all leading zeros, by repeated computation of SHA-1 with different > > link-local addresses. > > > > With existing EUI-64 addresses, the high order bits of the > > IPv6 IID aren't well distributed. In fact, there's a likelihood > > that the seven of the first 8 bits of the IID will be zero. > > > > Considering that, the XOR will be lowest if the first few bits in the > > usurping router's SHA-1 hash are zero. > > > > In this way, a router has to perform O(2^zeros) SHA-1 computations > > in order to find out a valid IID for generating a sequence of > > leading zeros for the hash. > > > > Link-local addresses with known low hashes could even be precomputed. > > > > The essential issue here is that the solicitors' addresses aren't > > well distributed. > > Agreed. > > > Two alternatives which overcome this issue are: > > > > 1) Perform the XOR comparison with the low order bytes of the IID > > first (either reverse the XORed bit strings, or do bytewise > > comparisons starting at the 16th byte). > > > > 2) Ensure that the solicitors' input values are well distributed, > > perhaps using a hash. > > > > I'd lean towards 1). It's probably fastest computationally, and > > was easy to implement in 16th-to 1st byte comparison form. > > I'd also lean towards 1) since it doesn't require calculating a hash > for each RS received. Doing the bytewise comparison starting at the > low order byte (the 8th since there's only 64 bits in the IID) sounds > like the better option to me, and sounds worth doing. > > Cheers, > Brett. > From dna-owner@webcamserver.eng.monash.edu.au Mon May 23 17:02:06 2005 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 RAA20935 for ; Mon, 23 May 2005 17:02:05 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOMLPMIZTQ99IWSW@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 24 May 2005 07:02:01 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2B7E2AB54C; Tue, 24 May 2005 07:01:58 +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 D9EBD4FB03; Tue, 24 May 2005 07:01:57 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4NL1KX10915 for dna-list; Tue, 24 May 2005 07:01: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 j4NL1Kr10911 for ; Tue, 24 May 2005 07:01:20 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOMLONAAP894MN1O@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 24 May 2005 07:01:11 +1000 Received: by localhost (Postfix, from userid 510) id F05DBAB54B; Tue, 24 May 2005 07:01:10 +1000 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by curly.its.monash.edu.au (Postfix) with ESMTP id C6CBC4FB02; Tue, 24 May 2005 07:01:08 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.58.166]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j4NL170R017177; Mon, 23 May 2005 15:01:07 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j4NL143v207950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 23 May 2005 14:01:06 -0700 (PDT) Date: Mon, 23 May 2005 14:03:55 -0700 From: Erik Nordmark Subject: Re: [DNA] Ordering Hash-based RAs In-reply-to: <42916EBB.3060506@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <4292453B.5030601@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 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <42916EBB.3060506@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > Dear DT, > > I really like the hash based RA scheme indicated in the > document draft-pentland-dna-protocol-00. > > I think there's an issue with its robustness to false > or hijacking routers, which may limit its usefulness though. > > The text presented allows a particular router to select an > interface identifier such that its SHA-1 hash will XOR with > the solicitor's received IID to provide the fastest ranked > response with high likelihood? Greg, I'm not sure I understand the attack and the impact of it. Are you saying that an attacker on the link can pretend to be a DNA router and select its IID so that it is more or less guaranteed to be the router ranked first? Then the "attack" is that this router will just ignore the RAs, with the impact being that the hosts have to wait a few tens of milliseconds until the next ranked router responds? That doesn't sound like a serious attack, given that an attacker on the link can cause all sorts of havoc (listed in the SeND threats RFC). However, it seems like the algorithm in the draft doesn't do a good job of spreading which router will respond first, since as you point out, the first bits of the IID of the host are the same for EUI-64 based IIDs. So I think we need to fix this for reasons other than security. > Two alternatives which overcome this issue are: > > 1) Perform the XOR comparison with the low order bytes of the IID > first (either reverse the XORed bit strings, or do bytewise > comparisons starting at the 16th byte). > > 2) Ensure that the solicitors' input values are well distributed, > perhaps using a hash. > > I'd lean towards 1). It's probably fastest computationally, and > was easy to implement in 16th-to 1st byte comparison form. #1 sounds good to me. Erik From dna-owner@webcamserver.eng.monash.edu.au Mon May 23 20:57:11 2005 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 UAA18979 for ; Mon, 23 May 2005 20:57:10 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOMTWL5D2M99IPYJ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 24 May 2005 10:56:43 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C4E50AB54D; Tue, 24 May 2005 10:56:38 +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 76B724FB07; Tue, 24 May 2005 10:56:38 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4O0tt713349 for dna-list; Tue, 24 May 2005 10:55:55 +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 j4O0tsr13345 for ; Tue, 24 May 2005 10:55:54 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOMTVJBCY69ANSR7@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 24 May 2005 10:55:48 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1486AAB543; Tue, 24 May 2005 10:55:48 +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 DD27F4FB19; Tue, 24 May 2005 10:55:47 +1000 (EST) Date: Tue, 24 May 2005 10:55:42 +1000 From: Greg Daley Subject: Re: [DNA] Ordering Hash-based RAs In-reply-to: <4292453B.5030601@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42927B8E.200@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 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <42916EBB.3060506@eng.monash.edu.au> <4292453B.5030601@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Erik Nordmark wrote: [cut] > > > Greg, > > I'm not sure I understand the attack and the impact of it. > Are you saying that an attacker on the link can pretend to be a DNA > router and select its IID so that it is more or less guaranteed to be > the router ranked first? > Then the "attack" is that this router will just ignore the RAs, with the > impact being that the hosts have to wait a few tens of milliseconds > until the next ranked router responds? > > That doesn't sound like a serious attack, given that an attacker on the > link can cause all sorts of havoc (listed in the SeND threats RFC). > > However, it seems like the algorithm in the draft doesn't do a good job > of spreading which router will respond first, since as you point out, > the first bits of the IID of the host are the same for EUI-64 based IIDs. > So I think we need to fix this for reasons other than security. I agree that the effects aren't necessarily severe. In some environments though, it may be possible for a bogus router to then advertise additional addresses to generate further delays. This is much harder to do if the ordering of the router ranks is unpredictable. Spreading out the responses sounds like a good thing to do in any case, as you point out though. Greg From dna-owner@webcamserver.eng.monash.edu.au Mon May 23 20:57:13 2005 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 UAA18986 for ; Mon, 23 May 2005 20:57:11 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOMTWRFWXK9ANSR7@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 24 May 2005 10:56:51 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 54F38AB554; Tue, 24 May 2005 10: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 DCF0C4FB0C; Tue, 24 May 2005 10:56:46 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4O0uac13363 for dna-list; Tue, 24 May 2005 10:56:36 +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 j4O0uZr13359 for ; Tue, 24 May 2005 10:56:35 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOMTW6V9U099IPYJ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 24 May 2005 10:56:19 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C23A2AB54D; Tue, 24 May 2005 10:56:19 +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 A26DA4FB17; Tue, 24 May 2005 10:56:19 +1000 (EST) Date: Tue, 24 May 2005 10:56:19 +1000 From: Greg Daley Subject: Re: [DNA] Ordering Hash-based RAs In-reply-to: <42917745.3050901@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42927BB3.2020608@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 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <42916EBB.3060506@eng.monash.edu.au> <42917745.3050901@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett. Brett Pentland wrote: > Greg Daley wrote: > >> Dear DT, >> >> I really like the hash based RA scheme indicated in the >> document draft-pentland-dna-protocol-00. > > > :) That's good to hear. > >> I think there's an issue with its robustness to false >> or hijacking routers, which may limit its usefulness though. > > > Aside: There will be many things that rogue devices can do to > disrupt things if SEND is not used. If SEND is used then I don't > think the following scenario is a problem, however... The trick with SEND is to allow explicit trust of the other routers using common trust anchors, and then most importantly, closing FastRA to non-trusted SEND or non-SEND routers. This is not really what the hash based RA mechanism was aimed at, without diminishing the usability significantly. There's a SEND configuration flag already (defaulting to off) which allows unsecured messages to be ignored. I don't think we'd need to define anything for DNA. Unless that flag is used, the hash-based RA scheme is subject to the attacks you alluded to (but may be fairly robust to them). [cut] >> The essential issue here is that the solicitors' addresses aren't >> well distributed. > > > Agreed. > >> Two alternatives which overcome this issue are: >> >> 1) Perform the XOR comparison with the low order bytes of the IID >> first (either reverse the XORed bit strings, or do bytewise >> comparisons starting at the 16th byte). >> >> 2) Ensure that the solicitors' input values are well distributed, >> perhaps using a hash. >> >> I'd lean towards 1). It's probably fastest computationally, and >> was easy to implement in 16th-to 1st byte comparison form. > > > I'd also lean towards 1) since it doesn't require calculating a hash > for each RS received. Doing the bytewise comparison starting at the > low order byte (the 8th since there's only 64 bits in the IID) sounds > like the better option to me, and sounds worth doing. Oops Sorry about that. Greg From dna-owner@webcamserver.eng.monash.edu.au Mon May 23 20:58:39 2005 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 UAA19039 for ; Mon, 23 May 2005 20:58:38 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOMTY8DYLG99IPYJ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 24 May 2005 10:58:20 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 16020AB54D; Tue, 24 May 2005 10:57:58 +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 BA4F94FB0C; Tue, 24 May 2005 10:57:57 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4O0vsd13437 for dna-list; Tue, 24 May 2005 10:57:54 +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 j4O0vsr13433 for ; Tue, 24 May 2005 10:57:54 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOMTXZBNW899IPYJ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 24 May 2005 10:57:47 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1403EAB54F; Tue, 24 May 2005 10:57:39 +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 B3FD74FB0D; Tue, 24 May 2005 10:57:38 +1000 (EST) Date: Tue, 24 May 2005 10:57:37 +1000 From: Greg Daley Subject: Re: [DNA] DNAO format revision? In-reply-to: <4291FFAD.1070408@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: dna@eng.monash.edu.au, brett.pentland@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <42927C01.8020103@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 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <42913E16.4020600@eng.monash.edu.au> <4291FFAD.1070408@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Erik Nordmark wrote: > Greg Daley wrote: > >> Please respond indicating if you like any of the >> existing proposals (Current, Variant 1 or Variant 2), >> or prefer something different. > > > I think either one is an improvement over the current one in the draft. > Whether we want the smaller #2 option (with a bit more complexity) > depends on how important we think it is to minimize the size of the DNAO. > > The DNAO is only sent by a routers when not all routers on the link are > configured to advertise the same set of prefixes. However, RFC 2461 does > allow that the routers advertise different sets of prefixes. I'd suspect > that in all well-run IPv6 networks the routers advertise the same set of > prefixes (so that they all can be backups for each other). So optimizing > the size of the DNAO might not be terribly important. > But I don't have a problem with format #2 - just questioning the > necessity of minimizing something which might not be used much in the > real world (but is mostly there to deal with the - perhaps unnecessary - > generality in RFC 2461). I understand that this is not the normal case for IPv6 networks. My testbed is currently set up to handle this case though, as one of the tricky cases in DNA. I'm not sure if it's terribly important to optimize, other than seeing a few zeros in the Variant 1 which I implemented before trying Variant 2 (since #1 was slightly easier). Both work though, and I'm happy to go with either. What's probably most important is that it works with mismatched (even if poorly configured???) prefixes, rather than worrying about the size. If we want to follow the 'keep it simple' principle, then we could probably choose Variant 1, but keep track of the alternatives in the issues list. Does this sound like a good idea? Greg From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 02:37:13 2005 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 CAA29866 for ; Tue, 24 May 2005 02:37:12 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LON5RYQAL094MRQR@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 24 May 2005 16:36:50 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 093A7AB546; Tue, 24 May 2005 16:36:31 +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 B03C84FB0B; Tue, 24 May 2005 16:36:30 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4O6Xqf16929 for dna-list; Tue, 24 May 2005 16:33:52 +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 j4O6Xpr16925 for ; Tue, 24 May 2005 16:33:51 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LON5OHCYC29726S9@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 24 May 2005 16:33:43 +1000 Received: by localhost (Postfix, from userid 510) id A0FFA80005; Tue, 24 May 2005 16:33:42 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (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 9BB243C009; Tue, 24 May 2005 16:33:38 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DaSyt-000HNv-MP; Tue, 24 May 2005 02:33:35 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4O6XXQ24002; Mon, 23 May 2005 23:33:34 -0700 Date: Mon, 23 May 2005 23:33:33 -0700 (PDT) From: Bernard Aboba Subject: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: <428E9AF3.7080202@eng.monash.edu.au> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <428E9AF3.7080202@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Recently, in a liaison letter from IEEE 802.21, some questions were raised about the use of the terms "Link Up" and "Link Down" within draft-iab-link-indications-01.txt. In revising the document, I went about in search of definitions of these terms. However, I could not find a definition in the following documents: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-11.txt http://www.ietf.org/internet-drafts/draft-ietf-dna-link-information-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dna-goals-04.txt http://www.ietf.org/internet-drafts/draft-ietf-dna-soln-frame-00.txt http://www.watersprings.org/pub/id/draft-yamamoto-dna-term-00.txt This struck me as more than a little odd, particularly when I found myself asking basic questions about the meaning of these terms. For example, in wireless communications link quality can be highly transient; when multi-path interference is present, the S/N ratio can dip 20-30 dB within the space of a few feet. In a wired network, the "up" link state is one exhibiting very low frame loss, whereas the "down" state is one exhibiting 100 percent loss. It is therefore clear when a link transitions from "down" to "up"; a "Link Up" event is sent upon this transition. Similarly, it is clear when a link transitions from "up" to "down" and a "Link Down" event is sent upon this transition. However, on a wireless network, intermediate frame loss rates are often observed, so that links may be neither "up" nor "down" according to the idealized definition. In this case, when are "Link Up" and "Link Down" events sent? Does the term "Link Up" refer to an event that only occurs when a link has entered a link layer protocol state associated with the initial ability to handle IP traffic? For example, within PPP does a "Link Up" event only occur after the completion of IPCP negotiation? Or in 802.11i, only after completion of the 4-way handshake? Or can a "Link Up" event occur when a STA wanders out of range of an access point, retransmits packets multiple times without a response, scans, and then returns within range of the same AP, all without changing state within the link layer state machine? In this scenario, is a "Link Down" event also sent? Similarly, does "Link Down" refer only to an event that occurs when a link has entered a link layer protocol state that is not associated with the ability to handle IP traffic? For example, in PPP a "Link Down" event is presumably sent on receipt of an LCP-Terminate; in 802.11, a Disassociate or Deauthenticate frame might trigger a "Link Down" event. But can a "Link Down" event also be sent due to a transient decline in link quality? For example, can this event be sent when a host wanders out of range and retransmits a frame until it gives up? Or is a more substantial outage required, affecting several distinct frames? In other words, is a "Link Down" event, unlike a "Link Up" event, affected by link quality? I ask these questions because it seems to me that the precise definition of these events may determine whether they are likely to be spurious, as well as whether they arrive in a timely way. For example, I have observed 802.11 NICs that will retransmit a lost frame for >30 seconds after an AP is turned off before scanning for another point of attachment. I have observed other NICs that will begin to scan after two retransmissions. From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 07:20:44 2005 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 HAA18214 for ; Tue, 24 May 2005 07:20:43 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LONFOHHW9U99ITGC@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 24 May 2005 21:20:25 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 357C580006; Tue, 24 May 2005 21:20:02 +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 BA4E03C005; Tue, 24 May 2005 21:20:01 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4OBJPE19917 for dna-list; Tue, 24 May 2005 21:19:25 +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 j4OBJOr19913 for ; Tue, 24 May 2005 21:19:24 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LONFNFKLZQ94MHH1@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 24 May 2005 21:19:12 +1000 Received: by localhost (Postfix, from userid 510) id D2C1AAB543; Tue, 24 May 2005 21:19:11 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by curly.its.monash.edu.au (Postfix) with ESMTP id 515154FB03; Tue, 24 May 2005 21:19:10 +1000 (EST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IGZ0087HRFVUA@mailout2.samsung.com>; Tue, 24 May 2005 20:19:08 +0900 (KST) Received: from wable ([107.108.71.65]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IGZ00IGMRFP25@mmp2.samsung.com>; Tue, 24 May 2005 20:19:07 +0900 (KST) Date: Tue, 24 May 2005 16:47:03 +0530 From: Ranjitsinh Wable Subject: Re: [DNA] DNAO format revision? Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: <034401c56052$202f1b30$41476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <42913E16.4020600@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, If my understanding is correct we can analyse three prefix options as follows. Current format: does not suit bcoz of the 8 byte alignment. But it has good characterstic of having the prefix length for each of the prefix mentioned just before the prefix. So processing is easier. About varient 1: What if the number of prefixes exceed the 6? I know still We can add the additional 8 bytes for the prefix length with appropriate padding. to start prefix on 8 byte alignment. also we can find the starting of the prefix information using length field in the DNAO and assuming the length of each prefix as 128. About varient 2: Again the same problem when number of prefixes exceed 5. (again same solution can do). Here the additional problem is that - How we will decide the length of the prefix exactly represented. Shall we assume whenever the length is less than or equal to 64 bits it will be always 8 bytes? In that case: If in future a need arised to advertise 16 bytes to represent the address even though the prefix is 64 bit. (Same as 'R' bit in MIPv6). Then with this approach we are restricting such possibility. IMHO, desired features could be: 1) 8 byte alignment. (I think 4 byte alignment is also fine) 2) Save bytes when the prefix length is less than or equal to 64 bit. 3) Can represent prefix with 64 and 128 bit even the though the prefix length is less than 64. 4) Easy for processing. In this respect we can make changes to varient 2 to have prefix representation of any bytes. OR come up with different variant. Let me know your opinion on the same. Thanks and Regards, Wable R. U. ----- Original Message ----- From: "Greg Daley" To: ; "Erik Nordmark" Sent: Monday, May 23, 2005 7:51 AM Subject: [DNA] DNAO format revision? > Hi DNA, > > I've been talking to Erik and most of my questions regarding > the DNA proposal have been answered. > > What I'd like to do now is to ask questions about message > formats and text, in a way which reinforces the hard work > undertaken by the DT. > > > Here's Q number 1: > > Is there a DNA option format which we can agree upon which > preserves Prefix alignment on 8 octet boundaries? > > I guess alignment is desirable to allow consistency with > earlier specifications 2461, 3810, and potentially allow > word-size based operations on some hosts. > > At the moment, the option format contains a list of > sequential 17 octet records. > > With 2 prefixes, the current format is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Prefix Len 1 | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + > | | > + + > | | > + Prefix 1 + > | | > + +-+-+-+-+-+-+-+-+ > | | Prefix Len 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Prefix 2 + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Padding (32bits) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > Erik has convinced me of the need to support 128 bit > prefixes in DNA, for future expansion, but it may be > possible to achieve this while preserving alignment. > > > One variant makes use of the ordering of prefixes and > their lengths but uses two separate lists (one for > the lengths and one for the prefixes. Pad is introduced > at the end of the list of prefix lengths, instead > of at the end of the option. > > I'll call this Variant #1: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Prefix Len 1 | Prefix Len 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Padding (32bits) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Prefix 1 + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Prefix 2 + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > It's also possible to have differing storage for > prefixes, so long as it is 8 octet aligned: > > The differing legnths of prefix mean that a number of prefixes > indication is required a the front of the prefix length list, > to remove ambiguity (it's not inferred just by the option length). > > I'll call this variant 2: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | # prefixes | Prefix Len 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix Len 2 | Padding (24 bits) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Prefix 1 (128 bits) + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Prefix 2 (64bits) + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Variant 1 (along with the current option format) has > the advantage that records are constant length, and that > the prefix lengths don't have to be read in order to > locate any particular prefix. > > Variant 2 has the advantage that if the prefix length is > less than or equal to 64 (today's common case), the > storage used is only 8 bytes. A host would have to read > the list of prefix lengths in order to parse the prefixes though. > > Does anyone have an opinion as to whether a change to the > DNA option would be good or not? > > Please respond indicating if you like any of the > existing proposals (Current, Variant 1 or Variant 2), > or prefer something different. > > Greg > > > From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 12:35:01 2005 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 MAA16854 for ; Tue, 24 May 2005 12:35:00 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LONQOGSKOQ9ANRPE@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 02:34:45 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1CB5D80003; Wed, 25 May 2005 02:34:36 +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 CCFE83C006; Wed, 25 May 2005 02:34:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4OGY3U23190 for dna-list; Wed, 25 May 2005 02:34:03 +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 j4OGY2r23186 for ; Wed, 25 May 2005 02:34:02 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LONQNLZTRA975FPK@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 02:33:55 +1000 Received: by localhost (Postfix, from userid 510) id E1BAD80002; Wed, 25 May 2005 02:33:54 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id A4A373C00B; Wed, 25 May 2005 02:33:51 +1000 (EST) Date: Tue, 24 May 2005 09:34:56 -0700 From: James Kempf Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba , Brett Pentland Cc: dna@eng.monash.edu.au Message-id: <03b001c5607e$893c8dc0$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <428E9AF3.7080202@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Bernard, As a practical matter, I think the definition of Link Up for DNA is: is it now possible to push an IP packet across the link? And the definition of link down is: is it now not possible to push an IP packet across the link? Given the diversity of link technologies, I think that is really all one can say from the IP layer. The details of what constitutes acceptable link quality to rule that an IP packet can be pushed across the link are likely to be different for UWB than for Super 3G or 802.16 from a radio technical standpoint. In addition, there are likely to be other policy matters - how the radio transport is used (like, for example, actual number of ARQs v.s. the maximum number, which is typically in the radio link standard), whether reauthorization is required on handover, etc. - that can differ even between two different terminals utilizing the same transport, or even two of the same terminals talking to two different wireless service providers. That said, I'm not saying that defining exactly what constitutes acceptable link quality for a particular radio transport isn't an interesting and important problem. Actually, it is quite vital and I would expect that any radio link specification would have that kind of information available for the packet data service. If the WG can arrive at a concensus definition of Link Up and Link Down for DNA, do you think it would be worthwhile writing it down, possibly in the solution framework document? jak ----- Original Message ----- From: "Bernard Aboba" To: "Brett Pentland" Cc: Sent: Monday, May 23, 2005 11:33 PM Subject: [DNA] Definition of "Link Up" and "Link Down" events? > Recently, in a liaison letter from IEEE 802.21, some questions were raised > about the use of the terms "Link Up" and "Link Down" within > draft-iab-link-indications-01.txt. > > In revising the document, I went about in search of definitions of these > terms. However, I could not find a definition in the following documents: > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-11.txt > http://www.ietf.org/internet-drafts/draft-ietf-dna-link-information-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-dna-goals-04.txt > http://www.ietf.org/internet-drafts/draft-ietf-dna-soln-frame-00.txt > http://www.watersprings.org/pub/id/draft-yamamoto-dna-term-00.txt > > This struck me as more than a little odd, particularly when I found myself > asking basic questions about the meaning of these terms. > > For example, in wireless communications link quality can be highly > transient; when multi-path interference is present, the S/N ratio can dip > 20-30 dB within the space of a few feet. > > In a wired network, the "up" link state is one exhibiting very low > frame loss, whereas the "down" state is one exhibiting 100 percent loss. > It is therefore clear when a link transitions from "down" to "up"; a > "Link Up" event is sent upon this transition. Similarly, it is clear > when a link transitions from "up" to "down" and a "Link Down" event > is sent upon this transition. > > However, on a wireless network, intermediate frame loss rates are often > observed, so that links may be neither "up" nor "down" according to the > idealized definition. In this case, when are "Link Up" and "Link Down" > events sent? > > Does the term "Link Up" refer to an event that only occurs when a link > has entered a link layer protocol state associated with the > initial ability to handle IP traffic? For example, within PPP does a > "Link Up" event only occur after the completion of IPCP negotiation? > Or in 802.11i, only after completion of the 4-way handshake? > > Or can a "Link Up" event occur when a STA wanders out of range of an > access point, retransmits packets multiple times without a response, > scans, and then returns within range of the same AP, all without > changing state within the link layer state machine? In this scenario, > is a "Link Down" event also sent? > > Similarly, does "Link Down" refer only to an event that occurs when a link > has entered a link layer protocol state that is not associated with the > ability to handle IP traffic? For example, in PPP a "Link Down" event > is presumably sent on receipt of an LCP-Terminate; in 802.11, a > Disassociate or Deauthenticate frame might trigger a "Link Down" event. > > But can a "Link Down" event also be sent due to a transient decline in > link quality? For example, can this event be sent when a host wanders > out of range and retransmits a frame until it gives up? Or is a more > substantial outage required, affecting several distinct frames? In > other words, is a "Link Down" event, unlike a "Link Up" event, affected > by link quality? > > I ask these questions because it seems to me that the precise definition > of these events may determine whether they are likely to be spurious, as > well as whether they arrive in a timely way. > > For example, I have observed 802.11 NICs that will retransmit a lost frame > for >30 seconds after an AP is turned off before scanning for another > point of attachment. I have observed other NICs that will begin to scan > after two retransmissions. > From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 13:53:24 2005 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 NAA26255 for ; Tue, 24 May 2005 13:53:23 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LONTEQSHQG975IQ4@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 03:53:19 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 111E680004; Wed, 25 May 2005 03:53: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 A91AB3C00F; Wed, 25 May 2005 03:53:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4OHqeh24081 for dna-list; Wed, 25 May 2005 03:52:40 +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 j4OHqdr24077 for ; Wed, 25 May 2005 03:52:39 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LONTE4U2HA94MIZS@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 03:52:34 +1000 Received: by localhost (Postfix, from userid 510) id D3B6A80002; Wed, 25 May 2005 03:52:33 +1000 (EST) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by larry.its.monash.edu.au (Postfix) with ESMTP id 64FFA3C007; Wed, 25 May 2005 03:52:30 +1000 (EST) Received: from pimout7-ext.prodigy.net (pimout7-int.prodigy.net [207.115.4.147]) by ylpvm15.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j4OHqTNs031538; Tue, 24 May 2005 13:52:30 -0400 Received: from JenEric (ppp-67-126-22-153.dsl.snfc21.pacbell.net [67.126.22.153]) by pimout7-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j4OHqJvx139254; Tue, 24 May 2005 13:52:24 -0400 Date: Tue, 24 May 2005 10:51:22 -0700 From: Jim Busse Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba , Brett Pentland Cc: dna@eng.monash.edu.au Reply-to: Jim Busse Message-id: <004d01c56089$3746cca0$7b01a8c0@JenEric> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-ORBL: [67.126.22.153] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: * References: <428E9AF3.7080202@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Historically, a lot of IETF documents use "link up" as triggers for other events, without defining the meaning of "link up" state. Scary. Sun defines the "link up" state on an ethernet device as the result of the link meeting a basic set of tunable parameters. These statistics determine when the Sun OS sets the "link up" state. Sun docs reprinted here without permission.... "When auto-negotiation is enabled, the adv_*_cap statistics show which capabilities are advertised to the link partner. When auto-negotiation is disabled in forced mode, the statistics precisely show how a link should function and that it must be matched on the link partner to achieve a valid link up. "The lp_cap_* parameters exist as kernel statistics for an Ethernet device. The statistics are the advertised capabilities provided by the link partner on completion of auto-negotiation. If the capabilities match the capabilities provided in the local advertisement, the link can proceed to a link up state. If no match is found, the link remains down. In two other instances, lp_cap_* values might all be zero: when a cable is not present, when forced mode is enabled." Microsoft and Apple may have similar definitions, but I couldn't find any in my MS references or on-line. I don't know how to look at Apple stuff... :-( There are a couple of instances of Link Up definition in other IETF docs, but the definitions are pretty loose: From draft-pentland-dna-protocol-00.txt DNAv6 assumes that the host's wireless link interface software and hardware is capable of delivering a 'link up' event notification when layer 2 on the host is configured and sufficiently stable for IP traffic. " Link down is not defined in that document. From draft-jung-mobileip-fastho-chain-00.txt "two simple triggers of Layer 2 are required. One is the Link Up trigger. MN or new AR receive the Link Up trigger when the MN arrives on the link with the new AR. " I'm not sure if the definition of "link up" and "link down" states are within the scope of the DNA charter. I think the OS determines whether the link is stable enough to perform the duties required by the OS, and is therefore an OS construct, not a DNA construct. Best regards Jim Busse ----- Original Message ----- From: "Bernard Aboba" To: "Brett Pentland" Cc: Sent: Monday, May 23, 2005 11:33 PM Subject: [DNA] Definition of "Link Up" and "Link Down" events? > Recently, in a liaison letter from IEEE 802.21, some questions were raised > about the use of the terms "Link Up" and "Link Down" within > draft-iab-link-indications-01.txt. > > In revising the document, I went about in search of definitions of these > terms. However, I could not find a definition in the following documents: > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-11.txt > http://www.ietf.org/internet-drafts/draft-ietf-dna-link-information-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-dna-goals-04.txt > http://www.ietf.org/internet-drafts/draft-ietf-dna-soln-frame-00.txt > http://www.watersprings.org/pub/id/draft-yamamoto-dna-term-00.txt > > This struck me as more than a little odd, particularly when I found myself > asking basic questions about the meaning of these terms. > > For example, in wireless communications link quality can be highly > transient; when multi-path interference is present, the S/N ratio can dip > 20-30 dB within the space of a few feet. > > In a wired network, the "up" link state is one exhibiting very low > frame loss, whereas the "down" state is one exhibiting 100 percent loss. > It is therefore clear when a link transitions from "down" to "up"; a > "Link Up" event is sent upon this transition. Similarly, it is clear > when a link transitions from "up" to "down" and a "Link Down" event > is sent upon this transition. > > However, on a wireless network, intermediate frame loss rates are often > observed, so that links may be neither "up" nor "down" according to the > idealized definition. In this case, when are "Link Up" and "Link Down" > events sent? > > Does the term "Link Up" refer to an event that only occurs when a link > has entered a link layer protocol state associated with the > initial ability to handle IP traffic? For example, within PPP does a > "Link Up" event only occur after the completion of IPCP negotiation? > Or in 802.11i, only after completion of the 4-way handshake? > > Or can a "Link Up" event occur when a STA wanders out of range of an > access point, retransmits packets multiple times without a response, > scans, and then returns within range of the same AP, all without > changing state within the link layer state machine? In this scenario, > is a "Link Down" event also sent? > > Similarly, does "Link Down" refer only to an event that occurs when a link > has entered a link layer protocol state that is not associated with the > ability to handle IP traffic? For example, in PPP a "Link Down" event > is presumably sent on receipt of an LCP-Terminate; in 802.11, a > Disassociate or Deauthenticate frame might trigger a "Link Down" event. > > But can a "Link Down" event also be sent due to a transient decline in > link quality? For example, can this event be sent when a host wanders > out of range and retransmits a frame until it gives up? Or is a more > substantial outage required, affecting several distinct frames? In > other words, is a "Link Down" event, unlike a "Link Up" event, affected > by link quality? > > I ask these questions because it seems to me that the precise definition > of these events may determine whether they are likely to be spurious, as > well as whether they arrive in a timely way. > > For example, I have observed 802.11 NICs that will retransmit a lost frame > for >30 seconds after an AP is turned off before scanning for another > point of attachment. I have observed other NICs that will begin to scan > after two retransmissions. From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 14:55:40 2005 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 OAA00890 for ; Tue, 24 May 2005 14:55:39 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LONVKYDX9I94MLVV@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 04:55:28 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AE86DAB543; Wed, 25 May 2005 04:55:19 +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 6F6874FB02; Wed, 25 May 2005 04:55:19 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4OIsgD24991 for dna-list; Wed, 25 May 2005 04:54:42 +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 j4OIsfr24987 for ; Wed, 25 May 2005 04:54:41 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LONVJVGY9G99I8Z0@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 04:54:27 +1000 Received: by localhost (Postfix, from userid 510) id 833EBAB543; Wed, 25 May 2005 04:54:27 +1000 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9064D4FB0D; Wed, 25 May 2005 04:54:25 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.17.57]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j4OIsOME000260; Tue, 24 May 2005 11:54:24 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j4OIsNCM593750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 May 2005 11:54:24 -0700 (PDT) Date: Tue, 24 May 2005 11:54:42 -0700 From: Erik Nordmark Subject: Re: [DNA] Ordering Hash-based RAs In-reply-to: <42927B8E.200@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Message-id: <42937872.6020106@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 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <42916EBB.3060506@eng.monash.edu.au> <4292453B.5030601@sun.com> <42927B8E.200@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > I agree that the effects aren't necessarily severe. > > In some environments though, it may be possible for a bogus router to > then advertise additional addresses to generate further delays. > This is much harder to do if the ordering of the router ranks is > unpredictable. Yes, but it is probably much easier to just generate RAs claiming to be a router (and generating "spoofed" RAs declaring that the real routers have a zero default router lifetime), which would make the link more or less stop functioning. > Spreading out the responses sounds like a good thing to do in any case, > as you point out though. Yep. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 14:56:28 2005 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 OAA00929 for ; Tue, 24 May 2005 14:56:26 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LONVM5OTXM9ANSLY@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 04:56:20 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DAC00AB543; Wed, 25 May 2005 04:56:17 +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 7CF4E4FB02; Wed, 25 May 2005 04:56:17 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4OIuFp25042 for dna-list; Wed, 25 May 2005 04:56:15 +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 j4OIuEr25038 for ; Wed, 25 May 2005 04:56:14 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LONVLV65K49755H3@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 04:56:04 +1000 Received: by localhost (Postfix, from userid 510) id BA3C0AB542; Wed, 25 May 2005 04:56:03 +1000 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by curly.its.monash.edu.au (Postfix) with ESMTP id BECD54FB07; Wed, 25 May 2005 04:56:01 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.58.166]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j4OItx0R013398; Tue, 24 May 2005 12:55:59 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j4OItwKn597318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 May 2005 11:55:58 -0700 (PDT) Date: Tue, 24 May 2005 11:56:16 -0700 From: Erik Nordmark Subject: Re: [DNA] DNAO format revision? In-reply-to: <42927C01.8020103@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au, brett.pentland@eng.monash.edu.au Message-id: <429378D0.7000004@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 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <42913E16.4020600@eng.monash.edu.au> <4291FFAD.1070408@sun.com> <42927C01.8020103@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Greg Daley wrote: > If we want to follow the 'keep it simple' principle, then we could > probably choose Variant 1, but keep track of the alternatives in the > issues list. > > Does this sound like a good idea? Works for me. Hopefully we'll then get some more WG feedback whether it is worth making the DNAO smaller for prefixes <= 64 bits. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 15:03:35 2005 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 PAA01499 for ; Tue, 24 May 2005 15:03:34 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LONVU9RMR6975GK8@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 05:03:01 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4C0C6AB54B; Wed, 25 May 2005 05:02:50 +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 ACB644FB05; Wed, 25 May 2005 05:02:49 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4OJ2hf25176 for dna-list; Wed, 25 May 2005 05:02:43 +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 j4OJ2gr25172 for ; Wed, 25 May 2005 05:02:42 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LONVTW5DNQ99HSRX@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 05:02:32 +1000 Received: by localhost (Postfix, from userid 510) id 29F97AB543; Wed, 25 May 2005 05:02:32 +1000 (EST) Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by curly.its.monash.edu.au (Postfix) with ESMTP id D8B624FB06 for ; Wed, 25 May 2005 05:02:27 +1000 (EST) Received: from pc6 (1Cust46.tnt24.lnd4.gbr.da.uu.net [62.188.151.46]) by blaster.systems.pipex.net (Postfix) with SMTP id BE54CE00024D; Tue, 24 May 2005 20:02:23 +0100 (BST) Date: Tue, 24 May 2005 19:23:24 +0200 From: Tom Petch Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: dna@eng.monash.edu.au Reply-to: Tom Petch Message-id: <02d501c5608a$21951960$0601a8c0@pc6> 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 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <428E9AF3.7080202@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT The terms have been in use by the IETF since at least RFC1157 (May 1990) and while I have seen no formal definition in that or subsequent documents, manufacturers have shown fair consensus on the meaning, about the ability to send an IP packet. The beauty of IP being an unreliable network is linkUp tells you nothing about what happens to the packet after it has left the box, only that nothing stopped it leaving:-) Tom Petch ----- Original Message ----- From: "Bernard Aboba" To: "Brett Pentland" Cc: Sent: Tuesday, May 24, 2005 8:33 AM Subject: [DNA] Definition of "Link Up" and "Link Down" events? > Recently, in a liaison letter from IEEE 802.21, some questions were raised > about the use of the terms "Link Up" and "Link Down" within > draft-iab-link-indications-01.txt. > > In revising the document, I went about in search of definitions of these > terms. However, I could not find a definition in the following documents: > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-11.txt > http://www.ietf.org/internet-drafts/draft-ietf-dna-link-information-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-dna-goals-04.txt > http://www.ietf.org/internet-drafts/draft-ietf-dna-soln-frame-00.txt > http://www.watersprings.org/pub/id/draft-yamamoto-dna-term-00.txt > > This struck me as more than a little odd, particularly when I found myself > asking basic questions about the meaning of these terms. > > For example, in wireless communications link quality can be highly > transient; when multi-path interference is present, the S/N ratio can dip > 20-30 dB within the space of a few feet. > > In a wired network, the "up" link state is one exhibiting very low > frame loss, whereas the "down" state is one exhibiting 100 percent loss. > It is therefore clear when a link transitions from "down" to "up"; a > "Link Up" event is sent upon this transition. Similarly, it is clear > when a link transitions from "up" to "down" and a "Link Down" event > is sent upon this transition. > > However, on a wireless network, intermediate frame loss rates are often > observed, so that links may be neither "up" nor "down" according to the > idealized definition. In this case, when are "Link Up" and "Link Down" > events sent? > > Does the term "Link Up" refer to an event that only occurs when a link > has entered a link layer protocol state associated with the > initial ability to handle IP traffic? For example, within PPP does a > "Link Up" event only occur after the completion of IPCP negotiation? > Or in 802.11i, only after completion of the 4-way handshake? > > Or can a "Link Up" event occur when a STA wanders out of range of an > access point, retransmits packets multiple times without a response, > scans, and then returns within range of the same AP, all without > changing state within the link layer state machine? In this scenario, > is a "Link Down" event also sent? > > Similarly, does "Link Down" refer only to an event that occurs when a link > has entered a link layer protocol state that is not associated with the > ability to handle IP traffic? For example, in PPP a "Link Down" event > is presumably sent on receipt of an LCP-Terminate; in 802.11, a > Disassociate or Deauthenticate frame might trigger a "Link Down" event. > > But can a "Link Down" event also be sent due to a transient decline in > link quality? For example, can this event be sent when a host wanders > out of range and retransmits a frame until it gives up? Or is a more > substantial outage required, affecting several distinct frames? In > other words, is a "Link Down" event, unlike a "Link Up" event, affected > by link quality? > > I ask these questions because it seems to me that the precise definition > of these events may determine whether they are likely to be spurious, as > well as whether they arrive in a timely way. > > For example, I have observed 802.11 NICs that will retransmit a lost frame > for >30 seconds after an AP is turned off before scanning for another > point of attachment. I have observed other NICs that will begin to scan > after two retransmissions. From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 15:17:42 2005 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 PAA03519 for ; Tue, 24 May 2005 15:17:41 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LONWD344CK975O20@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 05:17:24 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7D93380003; Wed, 25 May 2005 05:17:13 +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 1CCCA3C00D; Wed, 25 May 2005 05:17:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4OJH2O25376 for dna-list; Wed, 25 May 2005 05:17:02 +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 j4OJH2r25372 for ; Wed, 25 May 2005 05:17:02 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LONWCHIS8E975O20@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 05:16:45 +1000 Received: by localhost (Postfix, from userid 510) id B2894AB543; Wed, 25 May 2005 05:16:44 +1000 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by curly.its.monash.edu.au (Postfix) with ESMTP id BE2474FB03; Wed, 25 May 2005 05:16:42 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.228.50]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j4OJFuME021919; Tue, 24 May 2005 12:16:38 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j4OJFF00640805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 May 2005 12:15:16 -0700 (PDT) Date: Tue, 24 May 2005 12:15:33 -0700 From: Erik Nordmark Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: Brett Pentland , dna@eng.monash.edu.au Message-id: <42937D55.9040107@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 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <428E9AF3.7080202@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Bernard Aboba wrote: > However, on a wireless network, intermediate frame loss rates are often > observed, so that links may be neither "up" nor "down" according to the > idealized definition. In this case, when are "Link Up" and "Link Down" > events sent? If we are trying to solve the DNA issue, and ignore that hosts might have multiple NICs, then we can come up with what we need operationally. My take is that this should be sufficient: They layer 2 probably has some internal set of states at which it is known that no IP packets can be passed. Thus the loss probability is 100% due to the state at the driver/NIC/AP/whatever. For DNAs purposes it is useful to get a 'link up' notification from L2 when L2 moves out of the state(s) where no IP packets are passed. Likewise, if DNA needs a 'link down' notification, it is probably most useful for DNA if that notification arrives when L2 moves from a state where IP packets might be passed, to a state where they are guaranteed to not pass. We do need to ensure that at least a 'link up' notification is generated when the L2 connectivity changes, even if that change is near instantaneous (quickly unplugging the Ethernet cable and plugging one back in again; associating with an 802.11 AP even if the old AP was believed to still be reachable). With the above definitions we'll minimize what DNA would consider spurious notifications just because of signal strength, yet never miss the case when the layer 3 link is different. That is the simple case. Enter multihoming (multi-NICcing if you'd like)... When a host has multiple NICs there might be any number of policy related ways the host wants to choose. This could be based on a combination of signal strength, "flakiness history", cost, and it might be different for different applications running on the same host. I think that is out of scope for DNA, but it probably makes sense to explicitly mention it in the context of the L2 event notifications, saying that the host implementation can benefit from finding out about significant changes in signal strength, observed L2 retransmissions, etc., as some of the inputs to the hosts policy choices. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 16:29:17 2005 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 QAA22084 for ; Tue, 24 May 2005 16:29:16 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LONYUY8B869ANT9G@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 06:28:55 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A6153AB543; Wed, 25 May 2005 06:28:53 +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 654CB4FB07; Wed, 25 May 2005 06:28:53 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4OKSTC26124 for dna-list; Wed, 25 May 2005 06:28:29 +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 j4OKSSr26120 for ; Wed, 25 May 2005 06:28:28 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LONYU3RKRS975EV3@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 06:28:13 +1000 Received: by localhost (Postfix, from userid 510) id E2A4EAB543; Wed, 25 May 2005 06:28:12 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 43A3F4FB02; Wed, 25 May 2005 06:28:11 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1Dag0W-0009Oi-AK; Tue, 24 May 2005 16:28:08 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4OKS6w11342; Tue, 24 May 2005 13:28:06 -0700 Date: Tue, 24 May 2005 13:28:05 -0700 (PDT) From: Bernard Aboba Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: <03b001c5607e$893c8dc0$016115ac@dcml.docomolabsusa.com> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Brett Pentland , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <428E9AF3.7080202@eng.monash.edu.au> <03b001c5607e$893c8dc0$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT > As a practical matter, I think the definition of Link Up for DNA is: is it > now possible to push an IP packet across the link? And the definition of > link down is: is it now not possible to push an IP packet across the link? I would suggest that there is an important distinction between "the link layer state is now such that IP transport is permitted" versus "at this moment, the link quality is such that communication is likely to be successful." The former is typically well defined within a link layer, whereas the latter is a matter of judgement. My belief is that "Link Up" only reflects the former but not the latter consideration. > The details of what constitutes acceptable link > quality to rule that an IP packet can be pushed across the link are likely > to be different for UWB than for Super 3G or 802.16 from a radio technical > standpoint. Yes, but that will eventually be reflected in a state transition within the link layer state machine. > Actually, it is quite vital and I would expect that any > radio link specification would have that kind of information available for > the packet data service. Yes, but that may be considered separately from "Link Up" and "Link Down" indications. For example, a link may have made a transition to a state in which IP packet transmission is permitted, yet extensive frame loss may be observed. Such a link may provide information on the frame loss to upper layers which may affect routing metrics, but it does not send a "Link Down" indication until the loss is sufficiently persistent to cause the link layer state machine to transition. > If the WG can arrive at a concensus definition of Link Up and Link Down for > DNA, do you think it would be worthwhile writing it down, possibly in the > solution framework document? There was a terminology document at one point, so that might be the best place to include it. However, it also seems necessary to include that definition in other places which use the term, such as the DNAv4 document. From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 16:44:33 2005 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 QAA23113 for ; Tue, 24 May 2005 16:44:32 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LONZDZNUCQ975HAG@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 06:44:23 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B0DB1AB545; Wed, 25 May 2005 06:44:14 +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 5ED9F4FB02; Wed, 25 May 2005 06:44:14 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4OKi3726338 for dna-list; Wed, 25 May 2005 06:44:03 +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 j4OKi2r26334 for ; Wed, 25 May 2005 06:44:02 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LONZDF4RHU94MOKV@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 06:43:47 +1000 Received: by localhost (Postfix, from userid 510) id 3481BAB545; Wed, 25 May 2005 06:43:47 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 72DFA4FB09; Wed, 25 May 2005 06:43:45 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DagFa-000Cjc-WB; Tue, 24 May 2005 16:43:43 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4OKhf912257; Tue, 24 May 2005 13:43:41 -0700 Date: Tue, 24 May 2005 13:43:41 -0700 (PDT) From: Bernard Aboba Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: <42937D55.9040107@sun.com> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Brett Pentland , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <428E9AF3.7080202@eng.monash.edu.au> <42937D55.9040107@sun.com> Content-Transfer-Encoding: 7BIT > With the above definitions we'll minimize what DNA would consider > spurious notifications just because of signal strength, yet never miss > the case when the layer 3 link is different. Yes, I think that is a reasonable approach. > When a host has multiple NICs there might be any number of policy > related ways the host wants to choose. I think it's important to distinguish what choices we are talking about. If we are talking about choosing which NIC to transmit on, that is influenced by a variety of factors such as routing metrics, Strong/Weak host model. So link indications only influence this to the extent that they are taken into account within the routing metrics. Just because a link is not preferred in terms of routing to a particular destination prefix does not mean it is "down". If we are talking about the decision to bring a link up or down (e.g. "dial in demand" or "idle timeout") that is a different decision. I'd argue that "Link Up" or "Link Down" events are the consequence of these decisions. > This could be based on a combination of signal strength, "flakiness > history", cost, and it might be different for different applications > running on the same host. "Cost" and "flakiness history" (frame loss) have in the past been incorporated into routing metrics, whereas signal strength has been used in the decision about whether to bring a link up, since in these circumstances frame loss cannot yet be observed. In most implementations all applications share the same routing table and interfaces, and the decision to bring links "up" or "down" is typically handled below the application, which makes the decision on which interface(s) to bind to. > saying that the host implementation can benefit from finding out about > significant changes in signal strength, observed L2 retransmissions, > etc., as some of the inputs to the hosts policy choices. Sure, but I'd suggest that we should be clear that this additional info is not a determinant of "Link Up" and "Link Down" events. From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 16:49:57 2005 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 QAA23380 for ; Tue, 24 May 2005 16:49:56 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LONZKWJGR89ANSHV@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 06:49:50 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2E774AB543; Wed, 25 May 2005 06:49:49 +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 D3B764FB05; Wed, 25 May 2005 06:49:48 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4OKniR26431 for dna-list; Wed, 25 May 2005 06:49: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 j4OKnhr26427 for ; Wed, 25 May 2005 06:49:43 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LONZKHASLC9ANSHV@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 06:49:28 +1000 Received: by localhost (Postfix, from userid 510) id C640580002; Wed, 25 May 2005 06:49:28 +1000 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by larry.its.monash.edu.au (Postfix) with ESMTP id DB4FA3C008; Wed, 25 May 2005 06:49:26 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.68.36]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j4OKnPjO021717; Tue, 24 May 2005 14:49:25 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j4OKnOpR162442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 May 2005 13:49:25 -0700 (PDT) Date: Tue, 24 May 2005 13:49:43 -0700 From: Erik Nordmark Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: Brett Pentland , dna@eng.monash.edu.au Message-id: <42939367.3020108@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 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <428E9AF3.7080202@eng.monash.edu.au> <42937D55.9040107@sun.com> Content-Transfer-Encoding: 7BIT Bernard Aboba wrote: >>saying that the host implementation can benefit from finding out about >>significant changes in signal strength, observed L2 retransmissions, >>etc., as some of the inputs to the hosts policy choices. > > > Sure, but I'd suggest that we should be clear that this additional info is > not a determinant of "Link Up" and "Link Down" events. Agree 100%. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 17:50:38 2005 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 RAA27068 for ; Tue, 24 May 2005 17:50:36 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOO1OE746094MYJC@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 07:50:13 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E0FF3AB542; Wed, 25 May 2005 07:49:53 +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 9BC5E4FB02; Wed, 25 May 2005 07:49:53 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4OLnKn27067 for dna-list; Wed, 25 May 2005 07:49:20 +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 j4OLnJr27063 for ; Wed, 25 May 2005 07:49:19 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOO1ND32V699IVSX@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 07:49:04 +1000 Received: by localhost (Postfix, from userid 510) id 3C2F1AB543; Wed, 25 May 2005 07:49:04 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id 50AE64FB04; Wed, 25 May 2005 07:49:02 +1000 (EST) Date: Tue, 24 May 2005 14:50:07 -0700 From: James Kempf Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: Brett Pentland , dna@eng.monash.edu.au Message-id: <05a201c560aa$915523b0$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <428E9AF3.7080202@eng.monash.edu.au> <03b001c5607e$893c8dc0$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT > > As a practical matter, I think the definition of Link Up for DNA is: is it > > now possible to push an IP packet across the link? And the definition of > > link down is: is it now not possible to push an IP packet across the link? > > I would suggest that there is an important distinction between "the link > layer state is now such that IP transport is permitted" versus "at this > moment, the link quality is such that communication is likely to be > successful." The former is typically well defined within a link layer, > whereas the latter is a matter of judgement. My belief is that "Link Up" > only reflects the former but not the latter consideration. > Agree. > > The details of what constitutes acceptable link > > quality to rule that an IP packet can be pushed across the link are likely > > to be different for UWB than for Super 3G or 802.16 from a radio technical > > standpoint. > > Yes, but that will eventually be reflected in a state transition within > the link layer state machine. > But is this really of concern to IP? The IP layer just wants to know whether or not the link layer thinks there's a high probability of getting a packet across. The details of how that's done are indeed part of the state machine in the driver, but are they of any concern to the IP stack? > > Actually, it is quite vital and I would expect that any > > radio link specification would have that kind of information available for > > the packet data service. > > Yes, but that may be considered separately from "Link Up" and "Link Down" > indications. For example, a link may have made a transition to a state in > which IP packet transmission is permitted, yet extensive frame loss may be > observed. Such a link may provide information on the frame loss to upper > layers which may affect routing metrics, but it does not send a "Link > Down" indication until the loss is sufficiently persistent to cause the > link layer state machine to transition. > Right, that's what I was trying to get at with the statement on policy. In the case you've cited, the NIC policy is that extensive frame loss is not sufficient to trigger a "Link Down". That might not always be the case, for example, other NIC cards might have different policies, or the policy might be configurable. > > If the WG can arrive at a concensus definition of Link Up and Link Down for > > DNA, do you think it would be worthwhile writing it down, possibly in the > > solution framework document? > > There was a terminology document at one point, so that might be the best > place to include it. However, it also seems necessary to include that > definition in other places which use the term, such as the DNAv4 document. > OK. >> saying that the host implementation can benefit from finding out about >> significant changes in signal strength, observed L2 retransmissions, >> etc., as some of the inputs to the hosts policy choices. > >Sure, but I'd suggest that we should be clear that this additional info is >not a determinant of "Link Up" and "Link Down" events. Hmm, what about the case where 802.1x authentication must complete prior to "Link Up"? That has nothing whatsoever to do with the quality of the link from a frame transmission standpoint? jak From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 18:06:32 2005 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 SAA28588 for ; Tue, 24 May 2005 18:06:30 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOO29TAX569AMTSO@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 08:06:26 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2EC18AB545; Wed, 25 May 2005 08:06: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 DADCE4FB03; Wed, 25 May 2005 08:06:22 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4OM6Bs27309 for dna-list; Wed, 25 May 2005 08:06:11 +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 j4OM6Ar27305 for ; Wed, 25 May 2005 08:06:11 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOO29CQ7VA9AMTLJ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 08:06:01 +1000 Received: by localhost (Postfix, from userid 510) id 17D0D80002; Wed, 25 May 2005 08:06:01 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by larry.its.monash.edu.au (Postfix) with ESMTP id 540963C003; Wed, 25 May 2005 08:05:58 +1000 (EST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IH000GPVLDV6D@mailout3.samsung.com>; Wed, 25 May 2005 07:05:55 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IH000K82LDTOA@mmp1.samsung.com>; Wed, 25 May 2005 07:05:55 +0900 (KST) Date: Tue, 24 May 2005 15:04:59 -0700 From: Alper Yegin Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "'Bernard Aboba'" , "'Brett Pentland'" Cc: dna@eng.monash.edu.au Message-id: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Hi Bernard, > http://www.ietf.org/internet-drafts/draft-ietf-dna-link-information-01.t xt We have the definitions as: Node's establishment of a link-layer connection with an attachment point that signifies the availability of IP service (i.e., being able to send and receive IP packets) between the two is considered a link up event. Link down event signifies the discontinuation of the IP service between the node and the attachment point. When the link-layer connection is physically or logically torn down and it can no longer carry IP packets, this is considered to be a link down event. > Does the term "Link Up" refer to an event that only occurs when a link > has entered a link layer protocol state associated with the > initial ability to handle IP traffic? Yes. This event should be associated with a state transition within the L2. In the new state, the L2 should be willing to accept IP packets from L3, and look for an opportunity to transmit them. (as opposed to returning an immediate error message stating the request cannot be fulfilled -- interface is down, IP service not available, etc.) > For example, within PPP does a > "Link Up" event only occur after the completion of IPCP negotiation? > Or in 802.11i, only after completion of the 4-way handshake? Yes and yes, as we stated in the dna-link-info I-D. > Or can a "Link Up" event occur when a STA wanders out of range of an > access point, retransmits packets multiple times without a response, > scans, and then returns within range of the same AP, all without > changing state within the link layer state machine? In this scenario, > is a "Link Down" event also sent? I don't think so. > Similarly, does "Link Down" refer only to an event that occurs when a link > has entered a link layer protocol state that is not associated with the > ability to handle IP traffic? For example, in PPP a "Link Down" event > is presumably sent on receipt of an LCP-Terminate; in 802.11, a > Disassociate or Deauthenticate frame might trigger a "Link Down" event. Yes, we covered those in the same I-D as well. > But can a "Link Down" event also be sent due to a transient decline in > link quality? For example, can this event be sent when a host wanders > out of range and retransmits a frame until it gives up? Or is a more > substantial outage required, affecting several distinct frames? In > other words, is a "Link Down" event, unlike a "Link Up" event, affected > by link quality? Eventually a continued "low quality" may lead to the L2 deciding a state change that leads to a "link down", but this is a L2 design and implementation decision. > For example, I have observed 802.11 NICs that will retransmit a lost frame > for >30 seconds after an AP is turned off before scanning for another > point of attachment. I have observed other NICs that will begin to scan > after two retransmissions. I think this is a L2 implementation issue. At what point the L2 decides that it has lost its connection to an access network. Alper From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 18:38:12 2005 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 SAA01638 for ; Tue, 24 May 2005 18:38:11 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOO3CV763E94MSFZ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 08:38:00 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4267380002; Wed, 25 May 2005 08:37: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 EE6293C00B; Wed, 25 May 2005 08:37:51 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4OMbfZ27685 for dna-list; Wed, 25 May 2005 08:37:41 +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 j4OMbfr27681 for ; Wed, 25 May 2005 08:37:41 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOO3C9SDBY94MSFZ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 08:37:23 +1000 Received: by localhost (Postfix, from userid 510) id A6741AB543; Wed, 25 May 2005 08:37:23 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id F224A4FB05; Wed, 25 May 2005 08:37:21 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1Dai1X-000EDV-5w; Tue, 24 May 2005 18:37:19 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4OMbHQ19187; Tue, 24 May 2005 15:37:17 -0700 Date: Tue, 24 May 2005 15:37:16 -0700 (PDT) From: Bernard Aboba Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: <05a201c560aa$915523b0$016115ac@dcml.docomolabsusa.com> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Brett Pentland , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <428E9AF3.7080202@eng.monash.edu.au> <03b001c5607e$893c8dc0$016115ac@dcml.docomolabsusa.com> <05a201c560aa$915523b0$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT > But is this really of concern to IP? The IP layer just wants to know whether > or not the link layer thinks there's a high probability of getting a packet > across. The details of how that's done are indeed part of the state machine > in the driver, but are they of any concern to the IP stack? "High probability" is different from "the link layer is in a state where IP packet transmission is not possible". The former depends on link quality, whereas the latter depends on the link layer state machine. As a result, the former is likely to be highly transient, while the latter is likely to be less so. > Right, that's what I was trying to get at with the statement on policy. In > the case you've cited, the NIC policy is that extensive frame loss is not > sufficient to trigger a "Link Down". That might not always be the case, for > example, other NIC cards might have different policies, or the policy might > be configurable. Experiments do indicate that NICs behave quite differently, and some of that difference is due to different approaches taken by reasonable implementations as opposed to obviously broken behavior. For example, better 802.11 NIC implementations start scanning after only a few retransmissions (~3) since 3 consecutive lost frames is unlikely to be caused by collisions. These implementations still obey the 802.11 default shortretrylimit (7) so they continue retransmitting even as the NIC is interleaving scans to find another potential point of attachment. In most cases a "Link Down" is not signalled unless frame loss continues and another suitable AP cannot be found within the ESS. > >Sure, but I'd suggest that we should be clear that this additional info is > >not a determinant of "Link Up" and "Link Down" events. > > Hmm, what about the case where 802.1x authentication must complete prior to > "Link Up"? That has nothing whatsoever to do with the quality of the link > from a frame transmission standpoint? Since EAP supports retransmission, and on 802.11 802.1X frames are sent to a unicast address, it is possible for 802.1X authentication to complete even in situations where there is high frame loss. So it is possible for an 802.11i link to reach the "Link Up" state even though link quality is poor. From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 18:41:39 2005 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 SAA02002 for ; Tue, 24 May 2005 18:41:38 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOO3GYBCFG94MT8E@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 08:41:19 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 06FCDAB544; Wed, 25 May 2005 08:41:10 +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 BCE244FB08; Wed, 25 May 2005 08:41:09 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4OMf6k27767 for dna-list; Wed, 25 May 2005 08:41: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 j4OMf5r27763 for ; Wed, 25 May 2005 08:41:05 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOO3GK0LVS9ANTS1@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 08:40:51 +1000 Received: by localhost (Postfix, from userid 510) id CC307AB545; Wed, 25 May 2005 08:40:50 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 1F3544FB07; Wed, 25 May 2005 08:40:49 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1Dai4s-000FBc-NI; Tue, 24 May 2005 18:40:46 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4OMei719370; Tue, 24 May 2005 15:40:45 -0700 Date: Tue, 24 May 2005 15:40:44 -0700 (PDT) From: Bernard Aboba Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: Alper Yegin Cc: "'Brett Pentland'" , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> Content-Transfer-Encoding: 7BIT > Node's establishment of a link-layer connection with an attachment > point that signifies the availability of IP service (i.e., being able > to send and receive IP packets) between the two is considered a link > up event. Does this preclude "Link Up" from being sent on a uni-directional link? In other words, must the link layer demonstrate bi-directional reachability prior to sending a "Link Up" event? > Link down event signifies the discontinuation of the IP service > between the node and the attachment point. When the link-layer > connection is physically or logically torn down and it can no longer > carry IP packets, this is considered to be a link down event. This seems compatible with existing usage and some of the previous discussion. > > Or can a "Link Up" event occur when a STA wanders out of range of an > > access point, retransmits packets multiple times without a response, > > scans, and then returns within range of the same AP, all without > > changing state within the link layer state machine? In this scenario, > > is a "Link Down" event also sent? > > I don't think so. I would agree. > Eventually a continued "low quality" may lead to the L2 deciding a state > change that leads to a "link down", but this is a L2 design and > implementation decision. Agree that the operative term is "eventually" (e.g. link layer state transition). From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 19:00:21 2005 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 TAA03210 for ; Tue, 24 May 2005 19:00:20 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOO45AI6XK9ANF6A@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 09:00:08 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7743BAB546; Wed, 25 May 2005 09:00: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 30F6A4FB09; Wed, 25 May 2005 09:00:00 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4OMxgw27997 for dna-list; Wed, 25 May 2005 08:59:42 +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 j4OMxgr27993 for ; Wed, 25 May 2005 08:59:42 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOO44TT1QA9ANRM5@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 08:59:38 +1000 Received: by localhost (Postfix, from userid 510) id 1D208AB542; Wed, 25 May 2005 08:59:38 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 72C624FB06 for ; Wed, 25 May 2005 08:59:36 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DaiN4-000Lvz-2N for dna@eng.monash.edu.au; Tue, 24 May 2005 18:59:34 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4OMxWC20478 for ; Tue, 24 May 2005 15:59:32 -0700 Date: Tue, 24 May 2005 15:59:31 -0700 (PDT) From: Bernard Aboba Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> Content-Transfer-Encoding: 7BIT Using Alper's definition as a starting point, here a proposed definition of "Link Down" and "Link Up". What do people think? Link Down An event provided by the link layer that signifies that the link is no longer capable of communicating IP packets. Link Up An event provided by the link layer that signifies that the link has become capable of communicating IP packets. From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 19:09:07 2005 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 TAA03950 for ; Tue, 24 May 2005 19:09:06 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOO4FF6Z0O975C8U@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 09:08:36 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5845680002; Wed, 25 May 2005 09:08:10 +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 109153C004; Wed, 25 May 2005 09:08:10 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4ON81K28145 for dna-list; Wed, 25 May 2005 09:08:01 +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 j4ON80r28139 for ; Wed, 25 May 2005 09:08:00 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOO4F4O3GI9ANTED@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 09:07:56 +1000 Received: by localhost (Postfix, from userid 510) id 731A0AB543; Wed, 25 May 2005 09:07:56 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id 908C64FB06; Wed, 25 May 2005 09:07:54 +1000 (EST) Date: Tue, 24 May 2005 16:08:59 -0700 From: James Kempf Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: Brett Pentland , dna@eng.monash.edu.au Message-id: <060c01c560b5$957f9280$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <428E9AF3.7080202@eng.monash.edu.au> <03b001c5607e$893c8dc0$016115ac@dcml.docomolabsusa.com> <05a201c560aa$915523b0$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT > > But is this really of concern to IP? The IP layer just wants to know whether > > or not the link layer thinks there's a high probability of getting a packet > > across. The details of how that's done are indeed part of the state machine > > in the driver, but are they of any concern to the IP stack? > > "High probability" is different from "the link layer is in a state where > IP packet transmission is not possible". The former depends on link > quality, whereas the latter depends on the link layer state machine. As a > result, the former is likely to be highly transient, while the latter is > likely to be less so. > Ok, so is ~(IP packet transmission not possible) == (IP packet transmission possible)? From your previous emails, I have the impression that you think this is an oversimplification, is that right? > > >Sure, but I'd suggest that we should be clear that this additional info is > > >not a determinant of "Link Up" and "Link Down" events. > > > > Hmm, what about the case where 802.1x authentication must complete prior to > > "Link Up"? That has nothing whatsoever to do with the quality of the link > > from a frame transmission standpoint? > > Since EAP supports retransmission, and on 802.11 802.1X frames are sent to > a unicast address, it is possible for 802.1X authentication to complete > even in situations where there is high frame loss. So it is possible for > an 802.11i link to reach the "Link Up" state even though link quality is > poor. > From the IP stack's standpoint, "Link Up" on a link where 802.1x is required means: "802.1x is complete and the controlled port is now open for traffic". Even if the link is of stellar quality, the IP stack can't get any packets out prior to that. If the state is: "802.1x is complete and has failed, the controlled port is closed" means the link is still down. This particular state transition has nothing to do with the link quality, from the IP stack's viewpoint, even though the transition of the state machine regarding whether frames can successfully get across the link does affect whether or not 802.1x completes. If 802.1x is not required on the link, then the transition of interest to the IP stack is controlled by the link quality alone. So my point was, link quality is not the only factor that influences whether the driver can report "Link Up" to the IP stack. Sorry for being not clear. jak From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 19:43:51 2005 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 TAA06459 for ; Tue, 24 May 2005 19:43:49 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOO5NCR0JG99J0U1@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 09:43:40 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7F13080004; Wed, 25 May 2005 09:43:35 +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 39A663C006; Wed, 25 May 2005 09:43:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4ONhOo28561 for dna-list; Wed, 25 May 2005 09:43:24 +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 j4ONhNr28556 for ; Wed, 25 May 2005 09:43:23 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOO5MQD96E94N04F@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 09:43:06 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 900E3AB54A; Wed, 25 May 2005 09:43:05 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id 791154FB03; Wed, 25 May 2005 09:43:05 +1000 (EST) Received: from [211.28.184.51] by mail-store-2.its.monash.edu.au (mshttpd) ; Wed, 25 May 2005 09:43:05 +1000 Date: Wed, 25 May 2005 09:43:05 +1000 From: Greg Daley Subject: Re: [DNA] DNAO format revision? Sender: owner-dna@ecselists.eng.monash.edu.au To: Ranjitsinh Wable Cc: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: <48d32848a082.48a08248d328@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 Patch 2 (built Jul 14 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Wable, ----- Original Message ----- From: Ranjitsinh Wable Date: Tuesday, May 24, 2005 9:17 pm Subject: Re: [DNA] DNAO format revision? > Hi Greg, > > If my understanding is correct we can analyse three prefix options as > follows. > > Current format: does not suit bcoz of the 8 byte alignment. > But it has good characterstic of having the prefix length for each > of the > prefix mentioned just before the prefix. So processing is easier. One pointer/reference is needed rather than two, so I guess that may be called easier. > About varient 1: What if the number of prefixes exceed the 6? I > know still > We can add the additional 8 bytes for the prefix length with > appropriate > padding. > to start prefix on 8 byte alignment. also we can find the starting > of the > prefix information > using length field in the DNAO and assuming the length of each > prefix as > 128. Yes, it was intentional to use the length to describe the number of prefixes. This is only available since the records are constant length, though. Also, the padding beyond the sixth is intentional also. > About varient 2: Again the same problem when number of prefixes > exceed 5. > (again same solution can do). Here the additional problem is that - > How we > will decide the > length of the prefix exactly represented. Shall we assume whenever > the > length is less than or equal to > 64 bits it will be always 8 bytes? In that case: If in future a > need arised > to advertise > 16 bytes to represent the address even though the prefix is 64 > bit. (Same as > 'R' bit in MIPv6). > Then with this approach we are restricting such possibility. The mechanism provides for 65-128 bit addresses to have a length of 16 octets (actually, I'm providing 8 << ((unsigned) plen - 64) octets of space in RADVD). > IMHO, desired features could be: > 1) 8 byte alignment. (I think 4 byte alignment is also fine) > 2) Save bytes when the prefix length is less than or equal to 64 bit. > 3) Can represent prefix with 64 and 128 bit even the though the > prefix > length is less than 64. I'm unsure as to the application for this though. More elaboration may be needed. > 4) Easy for processing. Sounds good. If you've got some ideas of how these can be put together, I think we'd be interested. > In this respect we can make changes to varient 2 to have prefix > representation of any bytes. > OR come up with different variant. Perhaps. There's a trade off between future proofing an idea (depends a lot on the future), and goal 4... > Let me know your opinion on the same. Perhaps the idea of Variant 1 would suit in the short term... It's sufficiently simple, and though it doesn't reduce the number of octets used, it may be able to support future use... I'd be happy to see more ideas, but perhaps Variant 1 will do for now (for the reasons Erik mentioned). Greg From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 19:46:13 2005 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 TAA06562 for ; Tue, 24 May 2005 19:46:11 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOO5Q29S9G94N0XT@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 09:45:58 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6538D80006; Wed, 25 May 2005 09:45:46 +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 D6E113C007; Wed, 25 May 2005 09:45:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4ONjhX28629 for dna-list; Wed, 25 May 2005 09:45:43 +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 j4ONjgr28625 for ; Wed, 25 May 2005 09:45:43 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOO5PN9DQE9ANSU4@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 09:45:26 +1000 Received: by localhost (Postfix, from userid 510) id 1CA73AB548; Wed, 25 May 2005 09:45:25 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 61D554FB0B; Wed, 25 May 2005 09:45:23 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1Daj5M-0004p5-NV; Tue, 24 May 2005 19:45:20 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4ONjIw23261; Tue, 24 May 2005 16:45:19 -0700 Date: Tue, 24 May 2005 16:45:18 -0700 (PDT) From: Bernard Aboba Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: <060c01c560b5$957f9280$016115ac@dcml.docomolabsusa.com> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Brett Pentland , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <428E9AF3.7080202@eng.monash.edu.au> <03b001c5607e$893c8dc0$016115ac@dcml.docomolabsusa.com> <05a201c560aa$915523b0$016115ac@dcml.docomolabsusa.com> <060c01c560b5$957f9280$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT > > "High probability" is different from "the link layer is in a state where > > IP packet transmission is not possible". The former depends on link > > quality, whereas the latter depends on the link layer state machine. As a > > result, the former is likely to be highly transient, while the latter is > > likely to be less so. > > Ok, so is ~(IP packet transmission not possible) == (IP packet transmission > possible)? From your previous emails, I have the impression that you think > this is an oversimplification, is that right? IP packet transmission "possible" is an indication that the link layer will accept an IP packet for transmission. Whether it actually arrives depends on the link quality. Where we have perhaps over-simplified is in assuming that links are either "up" or "down" in terms of their frame loss (e.g. either low loss or high loss in both directions). In some cases (e.g. outdoor mesh networks) the data shows that links can be in intermediate states as well as exhibiting considerable asymmetry. However, those over-simplifications won't affect DNA as long as our definition of "Link Up" is not dependent on frame loss. However, it is not clear to me that other "link indications" are as robust. For example, are indications such as "Link Going Down" dependent on frame loss, are they indicative of a decision to bring the link down? > > > > >Sure, but I'd suggest that we should be clear that this additional info > is > > > >not a determinant of "Link Up" and "Link Down" events. > > > > > > Hmm, what about the case where 802.1x authentication must complete prior > to > > > "Link Up"? That has nothing whatsoever to do with the quality of the > link > > > from a frame transmission standpoint? > > > > Since EAP supports retransmission, and on 802.11 802.1X frames are sent to > > a unicast address, it is possible for 802.1X authentication to complete > > even in situations where there is high frame loss. So it is possible for > > an 802.11i link to reach the "Link Up" state even though link quality is > > poor. > > > > >From the IP stack's standpoint, "Link Up" on a link where 802.1x is required > means: "802.1x is complete and the controlled port is now open for traffic". > Even if the link is of stellar quality, the IP stack can't get any packets > out prior to that. If the state is: "802.1x is complete and has failed, the > controlled port is closed" means the link is still down. This particular > state transition has nothing to do with the link quality, from the IP > stack's viewpoint, even though the transition of the state machine regarding > whether frames can successfully get across the link does affect whether or > not 802.1x completes. > > If 802.1x is not required on the link, then the transition of interest to > the IP stack is controlled by the link quality alone. > > So my point was, link quality is not the only factor that influences whether > the driver can report "Link Up" to the IP stack. Sorry for being not clear. > > jak > > From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 19:54:11 2005 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 TAA07234 for ; Tue, 24 May 2005 19:54:10 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOO5XKDY4S975ESZ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 09:52:14 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7E763AB544; Wed, 25 May 2005 09:51:49 +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 303DD4FB08; Wed, 25 May 2005 09:51:49 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4ONpg128743 for dna-list; Wed, 25 May 2005 09:51:42 +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 j4ONpfr28739 for ; Wed, 25 May 2005 09:51:41 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOO5XBCNR694N0XT@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 09:51:37 +1000 Received: by localhost (Postfix, from userid 510) id 8B792AB546; Wed, 25 May 2005 09:51:37 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by curly.its.monash.edu.au (Postfix) with ESMTP id CEAC24FB08; Wed, 25 May 2005 09:51:35 +1000 (EST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IH000JIPQ9XX4@mailout3.samsung.com>; Wed, 25 May 2005 08:51:33 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IH000I12Q9VQR@mmp2.samsung.com>; Wed, 25 May 2005 08:51:33 +0900 (KST) Date: Tue, 24 May 2005 16:50:37 -0700 From: Alper Yegin Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "'Bernard Aboba'" Cc: "'Brett Pentland'" , dna@eng.monash.edu.au Message-id: <03c201c560bb$6397a2c0$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT > > Node's establishment of a link-layer connection with an attachment > > point that signifies the availability of IP service (i.e., being able > > to send and receive IP packets) between the two is considered a link > > up event. > > Does this preclude "Link Up" from being sent on a uni-directional link? > In other words, must the link layer demonstrate bi-directional > reachability prior to sending a "Link Up" event? We haven't really considered uni-directional links... Hmmm, should DNA deal with that? Assuming we are only talking about bi-directional links, I presume the reachability test would be performed implicitly (e.g., 4-way handshake) or explicitly by the L2. Alper From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 20:09:23 2005 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 UAA08165 for ; Tue, 24 May 2005 20:09:22 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOO6IR0H2294MYN3@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 10:08:41 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 44EC7AB550; Wed, 25 May 2005 10:08:07 +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 F30B34FB0A; Wed, 25 May 2005 10:08:06 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4P07pA28966 for dna-list; Wed, 25 May 2005 10:07:51 +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 j4P07or28962 for ; Wed, 25 May 2005 10:07:50 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOO6I5YRLO99J1JS@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 10:07:39 +1000 Received: by localhost (Postfix, from userid 510) id 48D6F80003; Wed, 25 May 2005 10:07:39 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (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 C454C3C007; Wed, 25 May 2005 10:07:37 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DajQt-00092H-BD; Tue, 24 May 2005 20:07:35 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4P07Xs24535; Tue, 24 May 2005 17:07:34 -0700 Date: Tue, 24 May 2005 17:07:33 -0700 (PDT) From: Bernard Aboba Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: <03c201c560bb$6397a2c0$291d9069@sisa.samsung.com> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: Alper Yegin Cc: "'Brett Pentland'" , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <03c201c560bb$6397a2c0$291d9069@sisa.samsung.com> Content-Transfer-Encoding: 7BIT > > In other words, must the link layer demonstrate bi-directional > > reachability prior to sending a "Link Up" event? > > We haven't really considered uni-directional links... Hmmm, should DNA > deal with that? I'm not suggesting that DNA deal with this -- but I don't think that the "Link Up" event depends on demonstration of bi-directional connectivity, just on reaching a link layer state where "IP packet communication" is enabled. From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 21:13:39 2005 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 VAA13643 for ; Tue, 24 May 2005 21:13:38 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOO8S1O17S9750J7@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 11:13:17 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 15485AB547; Wed, 25 May 2005 11:12:53 +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 A5F164FB02; Wed, 25 May 2005 11:12:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4P1CM829684 for dna-list; Wed, 25 May 2005 11:12:22 +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 j4P1CLr29678 for ; Wed, 25 May 2005 11:12:21 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOO8R60XJE99J0C6@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 11:12:10 +1000 Received: by localhost (Postfix, from userid 510) id A6DEFAB54C; Wed, 25 May 2005 11:12:10 +1000 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8B7834FB09 for ; Wed, 25 May 2005 11:12:08 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.108.38]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j4P1C70R007626; Tue, 24 May 2005 19:12:07 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j4P1C5nC326728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 May 2005 18:12:07 -0700 (PDT) Date: Tue, 24 May 2005 18:12:25 -0700 From: Erik Nordmark Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: dna@eng.monash.edu.au Message-id: <4293D0F9.8070401@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 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> Content-Transfer-Encoding: 7BIT Bernard Aboba wrote: > Using Alper's definition as a starting point, here a proposed definition > of "Link Down" and "Link Up". What do people think? > > Link Down > An event provided by the link layer that signifies that the link is > no longer capable of communicating IP packets. > > Link Up > An event provided by the link layer that signifies that the link > has become capable of communicating IP packets. I think it would be good if the definitions would clarify that even if the link layer on the host sees 100% packet loss for a short while, it doesn't necessarily imply that a link down event should be generated. (It presumably shouldn't be generated until the link layer abandons the L2 association/connection/whatever.) Erik From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 21:24:46 2005 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 VAA14119 for ; Tue, 24 May 2005 21:24:45 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOO955DN82975D8F@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 11:23:40 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EC3B7AB545; Wed, 25 May 2005 11:23:26 +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 ACFB04FB02; Wed, 25 May 2005 11:23:26 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4P1NIF29845 for dna-list; Wed, 25 May 2005 11:23:18 +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 j4P1NIr29841 for ; Wed, 25 May 2005 11:23:18 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOO94X0IYI9ANTJ6@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 11:23:16 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B8FF4AB54B; Wed, 25 May 2005 11:23:15 +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 curly.its.monash.edu.au (Postfix) with ESMTP id 6C40A4FB0D; Wed, 25 May 2005 11:23:15 +1000 (EST) Date: Wed, 25 May 2005 11:23:14 +1000 From: Brett Pentland Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: dna@eng.monash.edu.au Message-id: <4293D382.6040506@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) References: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> Content-Transfer-Encoding: 7BIT Bernard Aboba wrote: > Using Alper's definition as a starting point, here a proposed definition > of "Link Down" and "Link Up". What do people think? > > Link Down > An event provided by the link layer that signifies that the link is > no longer capable of communicating IP packets. > > Link Up > An event provided by the link layer that signifies that the link > has become capable of communicating IP packets. Works for me. My only concern would be about what would happen if an L2 technology comes along that can move its attachment point without any intermediate period of disconnection, perhaps through some out-of-band pre-establishmment of the new connection (and it would be good if such a technology did!). Perhaps it would just be a matter of using these definitions, but ensuring that a transition like above causes a matched pair of Link Down / Link Up events to be generated. As an aside: for draft-pentland-dna-solution-00 we only really considered Link Up, because that is the point at which the network layer on that interface is able to take some action (sending an RS, in this case, to find out what the Link Up means). Link Down is probably useful for coordinating between multiple interfaces, as are some of the events that might be able to be triggered by the intermediate connectivity situations that you described, but that is outside the scope of what we tried to achieve in the proposal. Brett. From dna-owner@webcamserver.eng.monash.edu.au Tue May 24 21:30:29 2005 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 VAA14304 for ; Tue, 24 May 2005 21:30:27 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOO9B2ZBJM975D8F@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 11:28:45 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B686FAB54B; Wed, 25 May 2005 11:28:13 +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 737454FB09; Wed, 25 May 2005 11:28:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4P1S9829934 for dna-list; Wed, 25 May 2005 11:28:09 +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 j4P1S8r29930 for ; Wed, 25 May 2005 11:28:08 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOO9ASGNQ49ANS5L@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 11:28:00 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D772C80002; Wed, 25 May 2005 11:27:59 +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 B0A213C009; Wed, 25 May 2005 11:27:59 +1000 (EST) Date: Wed, 25 May 2005 11:27:59 +1000 From: Brett Pentland Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: <4293D0F9.8070401@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Bernard Aboba , dna@eng.monash.edu.au Message-id: <4293D49F.80905@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) References: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> <4293D0F9.8070401@sun.com> Content-Transfer-Encoding: 7BIT Erik Nordmark wrote: > Bernard Aboba wrote: > >> Using Alper's definition as a starting point, here a proposed definition >> of "Link Down" and "Link Up". What do people think? >> >> Link Down >> An event provided by the link layer that signifies that the link is >> no longer capable of communicating IP packets. >> >> Link Up >> An event provided by the link layer that signifies that the link >> has become capable of communicating IP packets. > > > I think it would be good if the definitions would clarify that even if > the link layer on the host sees 100% packet loss for a short while, it > doesn't necessarily imply that a link down event should be generated. > (It presumably shouldn't be generated until the link layer abandons the > L2 association/connection/whatever.) How about: Link Down An event provided by the link layer that signifies a state change associated with the interface no longer being capable of communicating IP packets. Link Up An event provided by the link layer that signifies a state change associated with the interface becoming capable of communicating IP packets. Brett. From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 01:11:29 2005 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 BAA00769 for ; Wed, 25 May 2005 01:11:28 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOOH2XZCTO94MMZO@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 15:10:54 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2B99CAB545; Wed, 25 May 2005 15:10:44 +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 D75854FB0F; Wed, 25 May 2005 15:10:43 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4P582Y32323 for dna-list; Wed, 25 May 2005 15:08:02 +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 j4P581r32319 for ; Wed, 25 May 2005 15:08:01 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOOGZJVMPY99IPBY@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 15:08:00 +1000 Received: by localhost (Postfix, from userid 510) id 28972AB544; Wed, 25 May 2005 15:08:00 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by curly.its.monash.edu.au (Postfix) with ESMTP id 668834FB0A for ; Wed, 25 May 2005 15:07:58 +1000 (EST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IH100DF94X8GS@mailout3.samsung.com> for dna@eng.monash.edu.au; Wed, 25 May 2005 14:07:56 +0900 (KST) Received: from jinchoe ([75.2.47.237]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IH100MHJ4X815@mmp2.samsung.com> for dna@eng.monash.edu.au; Wed, 25 May 2005 14:07:56 +0900 (KST) Date: Wed, 25 May 2005 14:07:55 +0900 From: JinHyeock Choi Subject: Re: [DNA] Last call: Detection of Network Attachment (DNA) in IPv4 (fwd) Sender: owner-dna@ecselists.eng.monash.edu.au To: iesg@DOMAIN.HIDDEN.cnri.reston.va.us Cc: Bernard Aboba , dna@eng.monash.edu.au Message-id: <011201c560e7$b6462790$ed2f024b@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 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Dear Bernard I'd like to mention a few differences between DNA for IPv4 (DNAv4) and DNA for IPv6 (DNAv6). 1. Abbreviation For IPv4, DNA stands for "Detection of Network Attachment", whereas for IPv6, DNA stands for "Detecting Network Attachment". 2. DNA Goal I understand DNAv4 aims to detects movement (or lack of movement) between subnets, and obtains (or continue to use) a valid IPv4 configuration. DNAv6 aims to detect movement (or lack of movement) between links to ascertain the validity of existing IP configuration but does not include the actual IP configuration procedure. 3. Point of Attachment In DNA mailing list, we define a term "Attachment Point", which represents the link-layer connection. For example, assume the case of two 802.11 b APs and a router on the same ethernet link. Each AP is an Attachment Point and if a host moves from one AP to another, it has moved to a different Attachment Point. It's my impression that the "Attachment Point" from DNA WG and "Point of Attachment" from the draft doesn't mean the same thing. Also I am glad & relieved to see that the draft no longer includes the term 'link identifier'. Though the draft still uses the term 'link' a few times, the meaning is clear from the context. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 02:24:26 2005 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 CAA00698 for ; Wed, 25 May 2005 02:24:25 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOOJMEVTU494MIV6@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 16:24:10 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D39BB80003; Wed, 25 May 2005 16:23:41 +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 8B9873C004; Wed, 25 May 2005 16:23:41 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4P6NJs00790 for dna-list; Wed, 25 May 2005 16:23:19 +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 j4P6NIr00786 for ; Wed, 25 May 2005 16:23:18 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOOJLK4LQM975MQV@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 16:23:01 +1000 Received: by localhost (Postfix, from userid 510) id B1E9DAB54A; Wed, 25 May 2005 16:23:00 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 028F44FB0A for ; Wed, 25 May 2005 16:23:00 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DapI7-0001Kn-Bv; Wed, 25 May 2005 02:22:55 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4P6Mo214452; Tue, 24 May 2005 23:22:50 -0700 Date: Tue, 24 May 2005 23:22:49 -0700 (PDT) From: Bernard Aboba Subject: Re: [DNA] Last call: Detection of Network Attachment (DNA) in IPv4 (fwd) In-reply-to: <011201c560e7$b6462790$ed2f024b@jinchoe> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <011201c560e7$b6462790$ed2f024b@jinchoe> Content-Transfer-Encoding: 7BIT Thank you very much for your review. On Wed, 25 May 2005, JinHyeock Choi wrote: > Dear Bernard > > I'd like to mention a few differences between DNA for IPv4 (DNAv4) > and DNA for IPv6 (DNAv6). > > 1. Abbreviation > For IPv4, DNA stands for "Detection of Network Attachment", whereas > for IPv6, DNA stands for "Detecting Network Attachment". We can change the title. > > 2. DNA Goal > I understand DNAv4 aims to detects movement (or lack of movement) > between subnets, and obtains (or continue to use) a valid IPv4 configuration. > > DNAv6 aims to detect movement (or lack of movement) between links > to ascertain the validity of existing IP configuration but does not include > the actual IP configuration procedure. I think DNAv4 also ascertains the validity of an existing IP configuration. If it is valid, then the host continues to use it. But if it is not valid then the host needs to obtain a new configuration using mechanisms outside of DNAv4 (e.g. DHCP). Is this different than DNAv6? > 3. Point of Attachment > In DNA mailing list, we define a term "Attachment Point", which represents > the link-layer connection. > > For example, assume the case of two 802.11 b APs and a router on the same > ethernet link. Each AP is an Attachment Point and if a host moves from > one AP to another, it has moved to a different Attachment Point. > > It's my impression that the "Attachment Point" from DNA WG and > "Point of Attachment" from the draft doesn't mean the same thing. In the case above, I think that the AP would also be called a "Point of Attachment", so they seem very similar. I can change the document to say "Attachment Point" instead. > Also I am glad & relieved to see that the draft no longer includes the term > 'link identifier'. Though the draft still uses the term 'link' a few times, > the meaning is clear from the context. I did get questions about the meaning of terms such as "link", "Link Up", "Link Down" etc. Perhaps I should post all the terminology that is used so that we can make sure we are consistent between DNAv4 and DNAv6. From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 03:03:55 2005 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 DAA13048 for ; Wed, 25 May 2005 03:03:51 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOOL0SFV0099IZJ6@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 17:03:40 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C8B12AB542; Wed, 25 May 2005 17:03:31 +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 752874FB0A; Wed, 25 May 2005 17:03:31 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4P72sI01243 for dna-list; Wed, 25 May 2005 17:02:54 +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 j4P72rr01237 for ; Wed, 25 May 2005 17:02:53 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOOKZV2M0I94MXZV@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 17:02:47 +1000 Received: by localhost (Postfix, from userid 510) id 2E4F1AB543; Wed, 25 May 2005 17:02:47 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2E3C44FB06 for ; Wed, 25 May 2005 17:02:45 +1000 (EST) Received: by zproxy.gmail.com with SMTP id 13so42069nzn for ; Wed, 25 May 2005 00:02:45 -0700 (PDT) Received: by 10.36.56.10 with SMTP id e10mr40464nza; Wed, 25 May 2005 00:02:45 -0700 (PDT) Received: by 10.36.3.6 with HTTP; Wed, 25 May 2005 00:02:45 -0700 (PDT) Date: Wed, 25 May 2005 16:02:45 +0900 From: JinHyeock Choi Subject: Re: [DNA] Last call: Detection of Network Attachment (DNA) in IPv4 (fwd) In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: JinHyeock Choi , dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb05052500023ebad2dd@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline 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:content-disposition:references; b=UW9GUCBRthkQX9Z691nsmJ0slU1QBv5qeGZQxsdaTW7BIZWEPsFUnnlyDftGO6+VYW5okQn9ErUlAzXBk0OrRTnxUNd89zJP8+rsDOlxLbjkHbkgC15AdkgPlB2/dbfeIT4FG19vQz2fSaH4EyW2m6RZxACCktpuCy1dAutj02I= X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <011201c560e7$b6462790$ed2f024b@jinchoe> Content-Transfer-Encoding: 7BIT Bernard > > 1. Abbreviation > > For IPv4, DNA stands for "Detection of Network Attachment", whereas > > for IPv6, DNA stands for "Detecting Network Attachment". > > We can change the title. ok. Thanks for your trouble. > > 2. DNA Goal > > I understand DNAv4 aims to detects movement (or lack of movement) > > between subnets, and obtains (or continue to use) a valid IPv4 configuration. > > > > DNAv6 aims to detect movement (or lack of movement) between links > > to ascertain the validity of existing IP configuration but does not include > > the actual IP configuration procedure. > > I think DNAv4 also ascertains the validity of an existing IP > configuration. If it is valid, then the host continues to use it. But if > it is not valid then the host needs to obtain a new configuration using > mechanisms outside of DNAv4 (e.g. DHCP). Is this different than DNAv6? The difference I had in mind is whether DNA includes IP configuration or not. In DNAv6, Goals draft says: DNA process does not include the actual IP configuration procedure. For example, with respect to DHCP, the DNA process may determine that the host needs to get some configuration information from a DHCP server. However, the process of actually retrieving the information from a DHCP server falls beyond the scope of DNA. Whereas, I assumed that DNAv4 process includes actual IP configuration process because of "2.3. IPv4 Address Acquisition". If not, I see little difference. > > 3. Point of Attachment > > In DNA mailing list, we define a term "Attachment Point", which represents > > the link-layer connection. > > > > For example, assume the case of two 802.11 b APs and a router on the same > > ethernet link. Each AP is an Attachment Point and if a host moves from > > one AP to another, it has moved to a different Attachment Point. > > > > It's my impression that the "Attachment Point" from DNA WG and > > "Point of Attachment" from the draft doesn't mean the same thing. > > In the case above, I think that the AP would also be called a "Point of > Attachment", so they seem very similar. I can change the document to say > "Attachment Point" instead. I might be mistaken. In the above example, I thought a router is the "Point of Attachment" because of the definition below. Point of Attachment A location within the network where a host may be connected. This attachment point can be characterized by its address prefix and ^^^^^^^^^^^^^^^^^^^^^^^^^^^ next hop routing information. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If not, I see little difference and no need to change term. But it may be of help to present an example of "Point of Attachment". > > Also I am glad & relieved to see that the draft no longer includes the term > > 'link identifier'. Though the draft still uses the term 'link' a few times, > > the meaning is clear from the context. > > I did get questions about the meaning of terms such as "link", "Link Up", > "Link Down" etc. Perhaps I should post all the terminology that is used > so that we can make sure we are consistent between DNAv4 and DNAv6. That would be of help. While writing Goals draft for DNAv6, we had much trouble from the ambiguity around the term "link". I still worry the issue will come back again, so would be glad, if we set this straight. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 03:24:37 2005 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 DAA14410 for ; Wed, 25 May 2005 03:24:36 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOOLQ4FWWA94MXAT@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 17:24:31 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 40233AB545; Wed, 25 May 2005 17:23:57 +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 F08F94FB0A; Wed, 25 May 2005 17:23:56 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4P7Ncb01508 for dna-list; Wed, 25 May 2005 17:23:38 +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 j4P7Nbr01504 for ; Wed, 25 May 2005 17:23:37 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOOLPBWZC894MNSG@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 17:23:23 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0A26480002; Wed, 25 May 2005 17:23:19 +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 DE4C83C007; Wed, 25 May 2005 17:23:18 +1000 (EST) Date: Wed, 25 May 2005 17:23:18 +1000 From: Brett Pentland Subject: Re: [DNA] Last call: Detection of Network Attachment (DNA) in IPv4 (fwd) In-reply-to: <92e919fb05052500023ebad2dd@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , Bernard Aboba Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <429427E6.6080006@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) References: <011201c560e7$b6462790$ed2f024b@jinchoe> <92e919fb05052500023ebad2dd@mail.gmail.com> Content-Transfer-Encoding: 7BIT >>>3. Point of Attachment >>>In DNA mailing list, we define a term "Attachment Point", which represents >>>the link-layer connection. >>> >>>For example, assume the case of two 802.11 b APs and a router on the same >>>ethernet link. Each AP is an Attachment Point and if a host moves from >>>one AP to another, it has moved to a different Attachment Point. >>> >>>It's my impression that the "Attachment Point" from DNA WG and >>>"Point of Attachment" from the draft doesn't mean the same thing. >> >>In the case above, I think that the AP would also be called a "Point of >>Attachment", so they seem very similar. I can change the document to say >>"Attachment Point" instead. > > > I might be mistaken. In the above example, I thought a router is the > "Point of Attachment" because of the definition below. > > Point of Attachment > A location within the network where a host may be connected. This > attachment point can be characterized by its address prefix and > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > next hop routing information. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > If not, I see little difference and no need to change term. But it may > be of help to present an example of "Point of Attachment". Yes, when I read this definition, I took it to mean the same as the term "link" (using the definition of link in 2460). Thus if two 802.11b APs were connected through an Ethernet hub to a router, then regardless of which AP a host associates with, it connects to the same "Point of Attachment". This is distinct from "Attachment Point" as we've discussed it on this list (as JinHyeock points out) where each AP would represent a separate "Attachment Point". Brett. From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 03:30:15 2005 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 DAA14775 for ; Wed, 25 May 2005 03:30:14 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOOLXC69NW94MVQ0@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 17:29:56 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 40E7BAB545; Wed, 25 May 2005 17:29:46 +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 F16E14FB0F; Wed, 25 May 2005 17:29:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4P7TgK01609 for dna-list; Wed, 25 May 2005 17:29:42 +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 j4P7Tfr01605 for ; Wed, 25 May 2005 17:29:41 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOOLX1AK7S99J1R5@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 17:29:32 +1000 Received: by localhost (Postfix, from userid 510) id C749F80002; Wed, 25 May 2005 17:29:31 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by larry.its.monash.edu.au (Postfix) with ESMTP id 27BFE3C00A; Wed, 25 May 2005 17:29:30 +1000 (EST) 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 <0IH1006V7BH4TF@mailout1.samsung.com>; Wed, 25 May 2005 16:29:28 +0900 (KST) Received: from wable ([107.108.71.65]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IH100B6VBH296@mmp1.samsung.com>; Wed, 25 May 2005 16:29:28 +0900 (KST) Date: Wed, 25 May 2005 12:57:27 +0530 From: Ranjitsinh Wable Subject: Re: [DNA] DNAO format revision? Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , dna@eng.monash.edu.au Message-id: <055101c560fb$34e8b190$41476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <48d32848a082.48a08248d328@monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, We can have different formats for the same. but everything comes with their own advantages and limitations. Below I suggested one more varients. Let me know your opinion on the same. But I also perfer the Varient 1 you proposed as it is more simple and no problem of 16 bytes representation of prefexes which are less than or equal to 64. Only problem it will waste some bytes. But its ok, unless somebody comes up with some good solution. Thanks and Regards, Wable R. U. Varient 3: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Len 1 | Resv | R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix 1 (128 bits) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Len 2 | Resv | R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Prefix 2 (64bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Len 3 | Resv | R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix 3 (64bits) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding(32 Bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Here the Prefix 1 is 128 bit R = 1. Prefix 2 R =0. Prefix 3 is 64 bit but still represented with the 16 byte so R=1. Assuming the fact that most of the time the prefix length will be less than or equal to 64 we will be able to save at max 4 bytes per prefix. Alignment will be 4 bytes. Also here we have reserved field to convey more informations about the prefixes. I agree there is no such need now and hence may be just place holders. From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 03:57:06 2005 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 DAA16713 for ; Wed, 25 May 2005 03:57:05 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOOMVPVQU69ANR9O@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 17:56:45 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9B09980004; Wed, 25 May 2005 17:56:42 +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 4F91D3C006; Wed, 25 May 2005 17:56:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4P7uXf01925 for dna-list; Wed, 25 May 2005 17:56:33 +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 j4P7uWr01921 for ; Wed, 25 May 2005 17:56:33 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOOMUG5ZZ89ANT8T@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 17:55:41 +1000 Received: by localhost (Postfix, from userid 510) id 4261DAB545; Wed, 25 May 2005 17:55:41 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by curly.its.monash.edu.au (Postfix) with ESMTP id 4A2054FB05 for ; Wed, 25 May 2005 17:55:39 +1000 (EST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IH100LCYCOPIR@mailout3.samsung.com> for dna@eng.monash.edu.au; Wed, 25 May 2005 16:55:37 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IH100D2GCOPSN@mmp1.samsung.com> for dna@eng.monash.edu.au; Wed, 25 May 2005 16:55:37 +0900 (KST) Date: Wed, 25 May 2005 16:55:33 +0900 From: "Soohong Daniel Park@samsung.com" Subject: RE: [DNA] Last call: Detection of Network Attachment (DNA) in IPv4 (fwd) In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "'Bernard Aboba'" , "'JinHyeock Choi'" Cc: dna@eng.monash.edu.au Message-id: <011501c560ff$20dabbe0$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT >> 2. DNA Goal >> I understand DNAv4 aims to detects movement (or lack of movement) >> between subnets, and obtains (or continue to use) a valid IPv4 configuration. >> >> DNAv6 aims to detect movement (or lack of movement) between links >> to ascertain the validity of existing IP configuration but does not include >> the actual IP configuration procedure. > >I think DNAv4 also ascertains the validity of an existing IP >configuration. If it is valid, then the host continues to use it. But if >it is not valid then the host needs to obtain a new configuration using >mechanisms outside of DNAv4 (e.g. DHCP). Is this different than DNAv6? > In my understanding, the origin of DNAv4 is quitely different from DNAv6 since it is basically based on DHCPv4 for obtaining its own IP address (LLA is used for DNAv4 of course). DNAv4 host must initiate its address configuration procedure with DHCPDISCOVER message. DNAv6 does may not consider DHCPv6 environment but totally RS/RA operation. In conclusion, the different DNA Goal seems appropriate. I am not sure why we need to harmonized between DNAv4 Goal and DNAv6 Goal. Thanks. --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 08:03:23 2005 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 IAA03193 for ; Wed, 25 May 2005 08:03:22 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOOVGB2DCG94N18Q@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 22:02:57 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 50102AB545; Wed, 25 May 2005 22:02: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 022164FB10; Wed, 25 May 2005 22:02:22 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4PC1ff04507 for dna-list; Wed, 25 May 2005 22:01:41 +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 j4PC1fr04503 for ; Wed, 25 May 2005 22:01:41 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOOVF6XKGO94MTAM@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 22:01:28 +1000 Received: by localhost (Postfix, from userid 510) id 8E2B280002; Wed, 25 May 2005 22:01:28 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (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 F24C53C006 for ; Wed, 25 May 2005 22:01:26 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DauZg-000DGu-6m; Wed, 25 May 2005 08:01:24 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4PC1MQ03090; Wed, 25 May 2005 05:01:22 -0700 Date: Wed, 25 May 2005 05:01:22 -0700 (PDT) From: Bernard Aboba Subject: Re: [DNA] Last call: Detection of Network Attachment (DNA) in IPv4 (fwd) In-reply-to: <92e919fb05052500023ebad2dd@mail.gmail.com> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <011201c560e7$b6462790$ed2f024b@jinchoe> <92e919fb05052500023ebad2dd@mail.gmail.com> Content-Transfer-Encoding: 7BIT > > DNA process does not include the actual > IP configuration procedure. For example, with respect to DHCP, the > DNA process may determine that the host needs to get some > configuration information from a DHCP server. However, the process > of actually retrieving the information from a DHCP server falls > beyond the scope of DNA. > > Whereas, I assumed that DNAv4 process includes actual IP configuration > process because of "2.3. IPv4 Address Acquisition". If not, I see > little difference. The DNAv4 draft does determine when the host needs to get some configuration information from a DHCP server. The process for that is governed by the DHCPv4 specification, though the DNAv4 spec does describe the state that the DHCPv4 client should be in (INIT-REBOOT, etc.). > I might be mistaken. In the above example, I thought a router is the > "Point of Attachment" because of the definition below. > > Point of Attachment > A location within the network where a host may be connected. This > attachment point can be characterized by its address prefix and Ah. This definition is perhaps misleading. Is there a definition for "Attachment Point" that we could substitute for it? > If not, I see little difference and no need to change term. But it may > be of help to present an example of "Point of Attachment". We will change the text to refer only to "Attachment Point". > That would be of help. While writing Goals draft for DNAv6, we had much > trouble from the ambiguity around the term "link". I still worry the issue will > come back again, so would be glad, if we set this straight. Great. We will new definitions for "Attachment Point", "Link Up" and "Link Down" and will then post all the terminology to the list. From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 08:06:09 2005 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 IAA03885 for ; Wed, 25 May 2005 08:06:07 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOOVKJ5WHE94N18Q@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 22:06:03 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B32E280004; Wed, 25 May 2005 22:05:46 +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 659B23C009; Wed, 25 May 2005 22:05:46 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4PC5hJ04589 for dna-list; Wed, 25 May 2005 22:05:43 +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 j4PC5hr04585 for ; Wed, 25 May 2005 22:05:43 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOOVK1GTIQ9ANJ5U@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 22:05:23 +1000 Received: by localhost (Postfix, from userid 510) id 1CFA7AB543; Wed, 25 May 2005 22:05:23 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 7F54E4FB08; Wed, 25 May 2005 22:05:21 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DaudS-000DyE-Vc; Wed, 25 May 2005 08:05:19 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4PC5HZ03533; Wed, 25 May 2005 05:05:17 -0700 Date: Wed, 25 May 2005 05:05:17 -0700 (PDT) From: Bernard Aboba Subject: Re: [DNA] Last call: Detection of Network Attachment (DNA) in IPv4 (fwd) In-reply-to: <429427E6.6080006@eng.monash.edu.au> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: JinHyeock Choi , JinHyeock Choi , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <011201c560e7$b6462790$ed2f024b@jinchoe> <92e919fb05052500023ebad2dd@mail.gmail.com> <429427E6.6080006@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT > Yes, when I read this definition, I took it to mean the same as the term > "link" (using the definition of link in 2460). Thus if two 802.11b APs > were connected through an Ethernet hub to a router, then regardless of > which AP a host associates with, it connects to the same "Point of > Attachment". This is distinct from "Attachment Point" as we've > discussed it on this list (as JinHyeock points out) where each AP would > represent a separate "Attachment Point". In reviewing the document, I think that the term "Most Likely Point of Attachment" really means "Most Likely Network", where as when the document refers to changing the "point of attachment" it really means changing the "attachment point". I will try to clean up the document to make it clear what is being discussed. From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 08:34:26 2005 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 IAA06413 for ; Wed, 25 May 2005 08:34:24 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOOWKGR2EY9729WT@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 22:34:12 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F1E05AB54A; Wed, 25 May 2005 22:33:57 +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 ABA4C4FB03; Wed, 25 May 2005 22:33:57 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4PCXh404910 for dna-list; Wed, 25 May 2005 22:33: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 j4PCXgr04906 for ; Wed, 25 May 2005 22:33:42 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOOWJTDRA494M8F4@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 22:33:27 +1000 Received: by localhost (Postfix, from userid 510) id C4D34AB543; Wed, 25 May 2005 22:33:26 +1000 (EST) Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by curly.its.monash.edu.au (Postfix) with ESMTP id BD05D4FB09; Wed, 25 May 2005 22:33:21 +1000 (EST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j4PCXJh7024168; Wed, 25 May 2005 14:33:19 +0200 (MEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 14:33:19 +0200 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 14:33:18 +0200 Date: Wed, 25 May 2005 14:33:16 +0200 From: "Tero Kauppinen (JO/LMF)" Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland , Bernard Aboba Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Definition of "Link Up" and "Link Down" events? Thread-Index: AcVgyJibG0gav4ETTTmU84EfjQqOdQAXDIxg Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 25 May 2005 12:33:18.0890 (UTC) FILETIME=[EE41C8A0:01C56125] Content-Transfer-Encoding: 7BIT > Works for me. My only concern would be about what would happen if an L2 > technology comes along that can move its attachment point without any > intermediate period of disconnection, perhaps through some out-of-band > pre-establishmment of the new connection (and it would be good if such a > technology did!). > > Perhaps it would just be a matter of using these definitions, but > ensuring that a transition like above causes a matched pair of Link Down > / Link Up events to be generated. Well ... actually, for example, an Orinoco Gold WLAN card doesn't signal "link down" when switching from one AP to another. This means that in some cases the driver sees just a sequence of "link up" events when the node is roaming. > > As an aside: for draft-pentland-dna-solution-00 we only really > considered Link Up, because that is the point at which the network > layer on that interface is able to take some action (sending an RS, in > this case, to find out what the Link Up means). Link Down is probably > useful for coordinating between multiple interfaces, as are some of > the events that might be able to be triggered by the intermediate > connectivity situations that you described, but that is outside the > scope of what we tried to achieve in the proposal. > > Brett. Tero From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 08:58:22 2005 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 IAA08118 for ; Wed, 25 May 2005 08:58:21 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOOXEFFVG69ANS2T@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 22:58:16 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5CC53AB545; Wed, 25 May 2005 22:58:06 +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 0E4784FB08; Wed, 25 May 2005 22:58:06 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4PCw3a05217 for dna-list; Wed, 25 May 2005 22:58: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 j4PCw2r05213 for ; Wed, 25 May 2005 22:58:02 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOOXE6KB5Y9ANS2T@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 22:57:55 +1000 Received: by localhost (Postfix, from userid 510) id A82CBAB543; Wed, 25 May 2005 22:57:55 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 09C2D4FB04; Wed, 25 May 2005 22:57:54 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DavSJ-000POY-PK; Wed, 25 May 2005 08:57:51 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4PCvnM06566; Wed, 25 May 2005 05:57:50 -0700 Date: Wed, 25 May 2005 05:57:49 -0700 (PDT) From: Bernard Aboba Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: <4293D49F.80905@eng.monash.edu.au> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Erik Nordmark , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> <4293D0F9.8070401@sun.com> <4293D49F.80905@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT > How about: > > Link Down > An event provided by the link layer that signifies a state change > associated with the interface no longer being capable of > communicating IP packets. > > Link Up > An event provided by the link layer that signifies a state change > associated with the interface becoming capable of communicating > IP packets. Looks good. From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 08:58:27 2005 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 IAA08136 for ; Wed, 25 May 2005 08:58:26 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOOXCRVW9S975D0F@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 22:57:12 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 73B8880005; Wed, 25 May 2005 22:56:47 +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 2AD373C003; Wed, 25 May 2005 22:56:47 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4PCuca05181 for dna-list; Wed, 25 May 2005 22:56:38 +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 j4PCubr05177 for ; Wed, 25 May 2005 22:56:38 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOOXCK1TLC9ANS2T@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 22:56:37 +1000 Received: by localhost (Postfix, from userid 510) id 08DB1AB542; Wed, 25 May 2005 22:56:37 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 7CAB34FB02; Wed, 25 May 2005 22:56:35 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DavR2-000P8w-Qt; Wed, 25 May 2005 08:56:32 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4PCuVh06484; Wed, 25 May 2005 05:56:31 -0700 Date: Wed, 25 May 2005 05:56:31 -0700 (PDT) From: Bernard Aboba Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: "Tero Kauppinen (JO/LMF)" Cc: Brett Pentland , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: Content-Transfer-Encoding: 7BIT > Well ... actually, for example, an Orinoco Gold WLAN card doesn't signal > "link down" when switching from one AP to another. This means that in > some cases the driver sees just a sequence of "link up" events when the > node is roaming. Right. Note that some TCP implementations (foolishly) tear down connections on receipt of a "Link Down" indication; on such implementations the above behavior will spare the user considerable pain. From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 09:07:38 2005 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 JAA09468 for ; Wed, 25 May 2005 09:07:37 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOOXPIWS6O974VMS@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 May 2005 23:07:30 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 33838AB542; Wed, 25 May 2005 23:07:04 +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 E7E994FB08; Wed, 25 May 2005 23:07:03 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4PD6jY05387 for dna-list; Wed, 25 May 2005 23:06:45 +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 j4PD6ir05383 for ; Wed, 25 May 2005 23:06:44 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOOXOVF8CK9ANTHG@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 May 2005 23:06:32 +1000 Received: by localhost (Postfix, from userid 510) id C08F5AB542; Wed, 25 May 2005 23:06:32 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 06D554FB0B for ; Wed, 25 May 2005 23:06:32 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1Davae-0001a3-Gw for dna@eng.monash.edu.au; Wed, 25 May 2005 09:06:28 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4PD6Ri07177 for ; Wed, 25 May 2005 06:06:27 -0700 Date: Wed, 25 May 2005 06:06:26 -0700 (PDT) From: Bernard Aboba Subject: [DNA] Revised terminology section for DNAv4 In-reply-to: X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> <4293D0F9.8070401@sun.com> <4293D49F.80905@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Here is the revised terminology section for DNAv4 (ARP terms left out for brevity). Comments welcome. DHCP client A DHCP client or "client" is an Internet host using the Dynamic Host Configuration protocol (DHCP) [RFC2131] to obtain configuration parameters such as a network address. DHCP server A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients. Attachment Point The link endpoint on the link to which the host is currently connected. Link A communication facility or medium over which network nodes can communicate. Each link is associated with a minimum of two endpoints. Each link endpoint has a unique link-layer identifier. Link Down An event provided by the link layer that signifies a state change associated with the interface no longer being capable of communicating IP packets. Link Layer Conceptual layer of control or processing logic that is responsible for maintaining control of the data link. The data link layer functions provide an interface between the higher-layer logic and the data link. The link layer is the layer immediately below IP. Link Up An event provided by the link layer that signifies a state change associated with the interface becoming capable of communicating IP packets. Most Likely Attachment Network (MLAN) The attached network heuristically determined by the host to be most likely, based on hints. Routable address In this specification, the term "routable address" refers to any address other than an IPv4 Link-Local address. This includes private addresses as specified in [RFC1918]. Valid address In this specification, the term "valid address" refers to either a static IPv4 address, or an address assigned via DHCPv4 which has not been relinquished, and whose lease has not yet expired. From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 11:38:08 2005 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 LAA22266 for ; Wed, 25 May 2005 11:38:06 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOP2ZANZ1294N46K@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 May 2005 01:37:53 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 72558AB543; Thu, 26 May 2005 01:37:43 +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 2ABB44FB02; Thu, 26 May 2005 01:37:43 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4PFbIW07010 for dna-list; Thu, 26 May 2005 01:37:18 +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 j4PFbHr07006 for ; Thu, 26 May 2005 01:37:17 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOP2YER0XC94N46K@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 May 2005 01:37:00 +1000 Received: by localhost (Postfix, from userid 510) id A0397AB543; Thu, 26 May 2005 01:37:00 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id C151A4FB07 for ; Thu, 26 May 2005 01:36:58 +1000 (EST) Date: Wed, 25 May 2005 08:38:03 -0700 From: James Kempf Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba , dna@eng.monash.edu.au Message-id: <063801c5613f$c13691a0$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> Content-Transfer-Encoding: 7BIT Sounds good to me. jak ----- Original Message ----- From: "Bernard Aboba" To: Sent: Tuesday, May 24, 2005 3:59 PM Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? > Using Alper's definition as a starting point, here a proposed definition > of "Link Down" and "Link Up". What do people think? > > Link Down > An event provided by the link layer that signifies that the link is > no longer capable of communicating IP packets. > > Link Up > An event provided by the link layer that signifies that the link > has become capable of communicating IP packets. > > From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 11:55:21 2005 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 LAA23345 for ; Wed, 25 May 2005 11:55:20 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOP3KXSX249ANSTF@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 May 2005 01:55:14 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3B1E1AB546; Thu, 26 May 2005 01:55:10 +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 CBE274FB06; Thu, 26 May 2005 01:55:09 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4PFt1Z07224 for dna-list; Thu, 26 May 2005 01:55:01 +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 j4PFt1r07220 for ; Thu, 26 May 2005 01:55:01 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOP3KF8YUS99IZCO@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 May 2005 01:54:45 +1000 Received: by localhost (Postfix, from userid 510) id 734ADAB54C; Thu, 26 May 2005 01:54:45 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id 7ECB24FB06; Thu, 26 May 2005 01:54:44 +1000 (EST) Date: Wed, 25 May 2005 08:55:48 -0700 From: James Kempf Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: Brett Pentland , dna@eng.monash.edu.au Message-id: <064e01c56142$3ce7b0c0$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <428E9AF3.7080202@eng.monash.edu.au> <03b001c5607e$893c8dc0$016115ac@dcml.docomolabsusa.com> <05a201c560aa$915523b0$016115ac@dcml.docomolabsusa.com> <060c01c560b5$957f9280$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT > IP packet transmission "possible" is an indication that the link > layer will accept an IP packet for transmission. Whether it actually > arrives depends on the link quality. > I agree that an indication from the link that it is "up" and ready to accept IP traffic is no guarantee that the packet will be transmitted. The IP layer also needs to exercise some control if packet loss becomes unacceptably high, perhaps by switching to another interface, or triggering a handover on the interface where packet loss is high if the driver allows IP level handover triggering. > Where we have perhaps over-simplified is in assuming that links are either > "up" or "down" in terms of their frame loss (e.g. either low loss or high > loss in both directions). In some cases (e.g. outdoor mesh networks) the > data shows that links can be in intermediate states as well as exhibiting > considerable asymmetry. > > However, those over-simplifications won't affect DNA as long as our definition > of "Link Up" is not dependent on frame loss. However, it is not > clear to me that other "link indications" are as robust. For > example, are indications such as "Link Going Down" dependent on frame > loss, are they indicative of a decision to bring the link down? > > > I interpret "Link Going Down" to mean that the mobile node and base station have begun some procedure to initiate handover. In cellular protocols, there is extensive negotiation between the mobile node and base station prior to a handover. 802.16e also has this characteristic. An indication of "Link Going Down" on such a protocol would mean that negotiation has begun for handover and, at some short time in the future (perhaps indeterminate), packets will no longer be accepted for transmission. For 802.11, "Link Going Down" is meaningless because handover is completely controlled by the mobile node, and the link continues to accept packets until the AP scan interrupts packet transmission (and even there, I've seen some NICs that interrupt for AP scan then send a few packets out prior to the reassociation). jak From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 11:59:01 2005 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 LAA23533 for ; Wed, 25 May 2005 11:59:00 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOP3P7O9AS94MYP8@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 May 2005 01:58:47 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 19829AB543; Thu, 26 May 2005 01:58:37 +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 BC1544FB04; Thu, 26 May 2005 01:58:36 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4PFwYt07301 for dna-list; Thu, 26 May 2005 01:58: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 j4PFwYr07297 for ; Thu, 26 May 2005 01:58:34 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOP3OSPY0S94MSDR@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 May 2005 01:58:17 +1000 Received: by localhost (Postfix, from userid 510) id 13F4FAB543; Thu, 26 May 2005 01:58:17 +1000 (EST) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 4AADE4FB02; Thu, 26 May 2005 01:58:15 +1000 (EST) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j4PFkfSp016708; Wed, 25 May 2005 11:46:42 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j4PFkcSp016627; Wed, 25 May 2005 11:46:39 -0400 (EDT) Date: Wed, 25 May 2005 18:58:07 +0300 From: "Romascanu, Dan (Dan)" Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland , Erik Nordmark Cc: Bernard Aboba , dna@eng.monash.edu.au, bwijnen@lucent.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Definition of "Link Up" and "Link Down" events? Thread-Index: AcVgyR5OOc5U+HyfSVCf2JoKcFLsFQAeEkBQ content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT 'communicating IP packets' may be a problem for a lower layer that may have no clue when it becomes capable of passing IP packets, or when it stops being capable of doing it. RFC 2863 avoids this rat hole by using the term 'passing packets' in the definition of the ifOperStatus object and then defines LinkUp and LinkDown traps in terms of transition to and from ifOperStatus = Up Dan > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au > [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of > > Link Down > An event provided by the link layer that signifies a > state change > associated with the interface no longer being capable of > communicating IP packets. > > Link Up > An event provided by the link layer that signifies a > state change > associated with the interface becoming capable of communicating > IP packets. > > Brett. > From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 12:07:45 2005 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 MAA24085 for ; Wed, 25 May 2005 12:07:44 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOP41CNFDI9ANS8E@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 May 2005 02:07:40 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1BF3A80003; Thu, 26 May 2005 02:07: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 C5B7F3C003; Thu, 26 May 2005 02:07:36 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4PG7Q007447 for dna-list; Thu, 26 May 2005 02:07:26 +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 j4PG7Pr07443 for ; Thu, 26 May 2005 02:07:26 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOP40VD6UO9ANS8E@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 May 2005 02:07:14 +1000 Received: by localhost (Postfix, from userid 510) id 41132AB543; Thu, 26 May 2005 02:07:14 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id F28DF4FB07; Thu, 26 May 2005 02:07:11 +1000 (EST) Date: Wed, 25 May 2005 09:08:15 -0700 From: James Kempf Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland , Bernard Aboba Cc: dna@eng.monash.edu.au Message-id: <067c01c56143$fa6a9800$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> <4293D382.6040506@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Brett, > Works for me. My only concern would be about what would happen if an L2 > technology comes along that can move its attachment point without any > intermediate period of disconnection, perhaps through some out-of-band > pre-establishmment of the new connection (and it would be good if such a > technology did!). > > Perhaps it would just be a matter of using these definitions, but > ensuring that a transition like above causes a matched pair of Link Down > / Link Up events to be generated. > It really depends on how the L2 software exposes this capability to the IP stack. In certain sense, this technology already exists with CDMA soft handover, but the problem is that the driver does not expose the outstanding soft handover legs to the IP layer. The soft handover legs look like a single link from the IP layer's perspective, and are handled as such by the network. I think Flarion's OFDM also allows the terminal to have outstanding links to two base stations at a time, but I do not know how these are exposed to the IP stack. I believe they use the forward link (to the new base station) to perform Mobile IPv4 CoA registration while still receiving packets on the backward link (to the old base station). If the L2 software hides the L2 handover latency, then "Link Up" and Link Down" never occur during handover, although they may occur at other times, for example, if the terminal moves out of range of any base stations. jak From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 13:17:03 2005 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 NAA01824 for ; Wed, 25 May 2005 13:17:02 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOP6GB8X4E9ANU90@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 May 2005 03:16:58 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C378AAB54A; Thu, 26 May 2005 03:16: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 6FAB04FB06; Thu, 26 May 2005 03:16:56 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4PHEvL08242 for dna-list; Thu, 26 May 2005 03:14:57 +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 j4PHEur08238 for ; Thu, 26 May 2005 03:14:56 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOP6DSUTV494MTD6@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 May 2005 03:14:56 +1000 Received: by localhost (Postfix, from userid 510) id B2E86AB542; Thu, 26 May 2005 03:14:55 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by curly.its.monash.edu.au (Postfix) with ESMTP id 269AC4FB04 for ; Thu, 26 May 2005 03:14:54 +1000 (EST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IH2009TE2KRIA@mailout2.samsung.com> for dna@eng.monash.edu.au; Thu, 26 May 2005 02:14:51 +0900 (KST) Received: from Alperyegin ([105.253.155.65]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IH200DCE2KM7E@mmp1.samsung.com> for dna@eng.monash.edu.au; Thu, 26 May 2005 02:14:51 +0900 (KST) Date: Wed, 25 May 2005 10:13:52 -0700 From: Alper Yegin Subject: RE: [DNA] Revised terminology section for DNAv4 In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "'Bernard Aboba'" , dna@eng.monash.edu.au Message-id: <042701c5614d$22d41e70$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT > Link Down > An event provided by the link layer that signifies a state change > associated with the interface no longer being capable of > communicating IP packets. > Link Up > An event provided by the link layer that signifies a state change > associated with the interface becoming capable of communicating IP > packets. I think the main document to define these terms is the "L2 event notifications for DNA" (dna-link-info) I-D. We could have the DNAv4 and DNAv6 solution drafts point to it. But since DNAv4 I-D is ahead in the process, we'd have to include them in that document as well. I'd recommend adding a reference to dna-link-info for a more detailed discussions on the link up/down. Alper From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 13:50:47 2005 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 NAA04163 for ; Wed, 25 May 2005 13:50:46 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOP7LNK7PC975D5Q@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 May 2005 03:50:34 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BB4E180003; Thu, 26 May 2005 03:50:16 +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 67A233C006; Thu, 26 May 2005 03:50:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4PHnuM08633 for dna-list; Thu, 26 May 2005 03:49:56 +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 j4PHnur08629 for ; Thu, 26 May 2005 03:49:56 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOP7L3H8D0975D5Q@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 May 2005 03:49:50 +1000 Received: by localhost (Postfix, from userid 510) id 09CDEAB543; Thu, 26 May 2005 03:49:49 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 779734FB02; Thu, 26 May 2005 03:49:48 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1Db00n-000Cfy-ES; Wed, 25 May 2005 13:49:45 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4PHnhm23750; Wed, 25 May 2005 10:49:43 -0700 Date: Wed, 25 May 2005 10:49:43 -0700 (PDT) From: Bernard Aboba Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: <064e01c56142$3ce7b0c0$016115ac@dcml.docomolabsusa.com> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Brett Pentland , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <428E9AF3.7080202@eng.monash.edu.au> <03b001c5607e$893c8dc0$016115ac@dcml.docomolabsusa.com> <05a201c560aa$915523b0$016115ac@dcml.docomolabsusa.com> <060c01c560b5$957f9280$016115ac@dcml.docomolabsusa.com> <064e01c56142$3ce7b0c0$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT > I interpret "Link Going Down" to mean that the mobile node and base station > have begun some procedure to initiate handover. It is one thing to have an "idle timeout" feature that will cause a given interface to be brought down to due to lack of traffic. This signal presumably is sent from upper layers to the lower layer. It is another thing to have the lower layer predict its future link quality. Existing data shows that link quality can be highly variable so that these predictions are not necessarily very accurate. > In cellular protocols, there > is extensive negotiation between the mobile node and base station prior to a > handover. 802.16e also has this characteristic. An indication of "Link Going > Down" on such a protocol would mean that negotiation has begun for handover > and, at some short time in the future (perhaps indeterminate), packets will > no longer be accepted for transmission. > > For 802.11, "Link Going Down" is > meaningless because handover is completely controlled by the mobile node, > and the link continues to accept packets until the AP scan interrupts packet > transmission (and even there, I've seen some NICs that interrupt for AP scan > then send a few packets out prior to the reassociation). Agreed. From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 14:47:48 2005 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 OAA07884 for ; Wed, 25 May 2005 14:47:47 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOP9LTMO1E9ANS69@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 May 2005 04:47:43 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 11FAC80003; Thu, 26 May 2005 04:47:41 +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 A39893C006; Thu, 26 May 2005 04:47:40 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4PIlFI09456 for dna-list; Thu, 26 May 2005 04:47:15 +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 j4PIlDr09452 for ; Thu, 26 May 2005 04:47:13 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOP9KYJIT8975A6M@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 May 2005 04:46:59 +1000 Received: by localhost (Postfix, from userid 510) id 46820AB544; Thu, 26 May 2005 04:46:57 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2FB754FB07; Thu, 26 May 2005 04:46:56 +1000 (EST) Date: Wed, 25 May 2005 11:47:59 -0700 From: James Kempf Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: Brett Pentland , dna@eng.monash.edu.au Message-id: <07d001c5615a$4a6cc380$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <428E9AF3.7080202@eng.monash.edu.au> <03b001c5607e$893c8dc0$016115ac@dcml.docomolabsusa.com> <05a201c560aa$915523b0$016115ac@dcml.docomolabsusa.com> <060c01c560b5$957f9280$016115ac@dcml.docomolabsusa.com> <064e01c56142$3ce7b0c0$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT Bernard, > > I interpret "Link Going Down" to mean that the mobile node and base station > > have begun some procedure to initiate handover. > > It is one thing to have an "idle timeout" feature that will cause a given > interface to be brought down to due to lack of traffic. This signal > presumably is sent from upper layers to the lower layer. It is another > thing to have the lower layer predict its future link quality. Existing > data shows that link quality can be highly variable so that these > predictions are not necessarily very accurate. > In CDMA, the link quality predictions are very accurate. The host and base station do closed loop and open loop power control to keep the signal strength within range so that the signal quality is acceptable. The standards typically have a minimum power level defined at which the base station and mobile node initiate handover. After a handover, the power level for handover is lower to avoid hystersis and ping ponging. In 802.16 (which is a TDMA protocol), the base station and terminal exchange link quality information periodically. Also, the terminal can initiate periodic ranging, in which it starts transmitting at the lowest power and steps up the power level until it reaches a level at which the signal quality is optimal to the base station. I also have heard that 802.11k is supposed to help provide similar functionality to 802.11, though I have not looked into it. That said, I think it makes sense to keep the worst case in mind when designing DNA, and current 802.11 is certainly a candidate for that, as you've indicated. jak From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 15:03:54 2005 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 PAA09559 for ; Wed, 25 May 2005 15:03:52 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOPA6J0WFU94MROO@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 May 2005 05:03:43 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B7167AB543; Thu, 26 May 2005 05:03:35 +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 6B2504FB03; Thu, 26 May 2005 05:03:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4PJ3KC09667 for dna-list; Thu, 26 May 2005 05:03:20 +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 j4PJ3Kr09663 for ; Thu, 26 May 2005 05:03:20 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOPA669I709ANT67@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 May 2005 05:03:18 +1000 Received: by localhost (Postfix, from userid 510) id A849380002; Thu, 26 May 2005 05:03:18 +1000 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by larry.its.monash.edu.au (Postfix) with ESMTP id BFB403C006; Thu, 26 May 2005 05:03:16 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.104.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j4PJ3FGJ021797; Wed, 25 May 2005 12:03:15 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j4PJ34F6333156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 May 2005 12:03:05 -0700 (PDT) Date: Wed, 25 May 2005 12:03:32 -0700 From: Erik Nordmark Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: <4293D49F.80905@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Bernard Aboba , dna@eng.monash.edu.au Message-id: <4294CC04.7020909@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 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> <4293D0F9.8070401@sun.com> <4293D49F.80905@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Brett Pentland wrote: >> I think it would be good if the definitions would clarify that even if >> the link layer on the host sees 100% packet loss for a short while, it >> doesn't necessarily imply that a link down event should be generated. >> (It presumably shouldn't be generated until the link layer abandons >> the L2 association/connection/whatever.) > > > How about: > > Link Down > An event provided by the link layer that signifies a state change > associated with the interface no longer being capable of > communicating IP packets. > > Link Up > An event provided by the link layer that signifies a state change > associated with the interface becoming capable of communicating > IP packets. I feel we need to be more explicit about the 100% packet loss case to avoid misunderstandings. Erik From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 21:19:42 2005 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 VAA19761 for ; Wed, 25 May 2005 21:19:41 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOPNAHK6NO9ANUW6@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 May 2005 11:19:26 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 710B3AB542; Thu, 26 May 2005 11:19:24 +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 28D194FB09; Thu, 26 May 2005 11:19:24 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4Q1IhS13556 for dna-list; Thu, 26 May 2005 11:18:43 +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 j4Q1Igr13552 for ; Thu, 26 May 2005 11:18:42 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOPN9JUTSA9ANV3I@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 May 2005 11:18:39 +1000 Received: by localhost (Postfix, from userid 510) id 42AF080002; Thu, 26 May 2005 11:18:39 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by larry.its.monash.edu.au (Postfix) with ESMTP id 8AE3E3C008 for ; Thu, 26 May 2005 11:18:37 +1000 (EST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IH200LMXOH0A1@mailout3.samsung.com> for dna@eng.monash.edu.au; Thu, 26 May 2005 10:07:48 +0900 (KST) Received: from jinchoe ([75.2.43.239]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IH200DO1OH0IE@mmp1.samsung.com> for dna@eng.monash.edu.au; Thu, 26 May 2005 10:07:48 +0900 (KST) Date: Thu, 26 May 2005 10:07:47 +0900 From: JinHyeock Choi Subject: Re: [DNA] Revised terminology section for DNAv4 Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba , dna@eng.monash.edu.au Message-id: <008a01c5618f$54bff110$ef2b024b@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 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> <4293D0F9.8070401@sun.com> <4293D49F.80905@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Bernard Let me check whether my understanding is correct, especially w.r.t. "link". > Attachment Point > The link endpoint on the link to which the host is currently > connected. > > Link > A communication facility or medium over which network nodes can > communicate. Each link is associated with a minimum of two > endpoints. Each link endpoint has a unique link-layer identifier. I'd like to apply the above to the specific example as below. Assume there are two 802.11 APs, AP1 and AP2 and a router R on an ethernet segment as below. Also assume a host, H, is attached to AP1. (I don't remember how many times I used this one. :-)) +----+ | R | +----+ | +-----+--------+ | | +----+ +----+ |AP 1| |AP 2| +----+ +----+ +----+ | H | +----+ Then 1) There is only one link. 2) AP1 and AP2 are link endpoints of the link. 3) BSSID of each AP is the unique link-layer identifier for link endpoint. 4) AP1 is the Attachment Point of H. Right? If so, my concern is that the above may not be clear to the reader, I am afraid people may think there are two links in the above example. (Either I don't remember how many times this happened. :-() These are the words we use for "link" in CPL draft to prevent that. The term 'link' used in this document is as defined in RFC 2461 [1], which is a layer 3 definition. NOTE that that definition is completely different than the definition of the term 'link' in IEEE 802 standards. "Words" by themselves may not be enough for clear terminology definition. I think that it would help to provide an example like above. One more thing, I think it would better to use "Point of Attachment" instead of "Attachment Point". With "Attachment Point", we could not use an abbreviation because usually AP means 802.11 thing. This we belatedly found out while writing a draft. With "Point of Attachment", we can use "PoA". IEEE 802.21 WG uses the term "Point of Attachment" and its abbreviation "PoA" Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 21:21:32 2005 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 VAA19888 for ; Wed, 25 May 2005 21:21:31 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOPNCE32BK99ITND@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 May 2005 11:20:58 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 939B9AB54B; Thu, 26 May 2005 11:20: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 4F8A34FB08; Thu, 26 May 2005 11:20:56 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4Q1KsU13630 for dna-list; Thu, 26 May 2005 11:20:54 +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 j4Q1Krr13623 for ; Thu, 26 May 2005 11:20:53 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOPNC84H1E94M8Q6@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 May 2005 11:20:48 +1000 Received: by localhost (Postfix, from userid 510) id A43B9AB54D; Thu, 26 May 2005 11:20:48 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id DA8284FB09 for ; Thu, 26 May 2005 11:20:46 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1Db73D-0001op-PI; Wed, 25 May 2005 21:20:43 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4Q1KfC19181; Wed, 25 May 2005 18:20:41 -0700 Date: Wed, 25 May 2005 18:20:40 -0700 (PDT) From: Bernard Aboba Subject: Re: [DNA] Revised terminology section for DNAv4 In-reply-to: <008a01c5618f$54bff110$ef2b024b@jinchoe> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> <4293D0F9.8070401@sun.com> <4293D49F.80905@eng.monash.edu.au> <008a01c5618f$54bff110$ef2b024b@jinchoe> Content-Transfer-Encoding: 7BIT > One more thing, I think it would better to use "Point of Attachment" > instead of "Attachment Point". > > With "Attachment Point", we could not use an abbreviation because > usually AP means 802.11 thing. This we belatedly found out while > writing a draft. With "Point of Attachment", we can use "PoA". > IEEE 802.21 WG uses the term "Point of Attachment" and its > abbreviation "PoA" OK. Ideally we would be consistent between 802.21, DNAv4 and DNAv6. Is this possible? From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 21:30:39 2005 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 VAA20336 for ; Wed, 25 May 2005 21:30:38 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOPNMYV56G975WY4@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 May 2005 11:30:09 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3B0C3AB542; Thu, 26 May 2005 11:29:28 +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 E5A0B4FB04; Thu, 26 May 2005 11:29:27 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4Q1T1513764 for dna-list; Thu, 26 May 2005 11:29:01 +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 j4Q1T0r13760 for ; Thu, 26 May 2005 11:29:00 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOPNMBIQ6I975K9S@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 May 2005 11:28:57 +1000 Received: by localhost (Postfix, from userid 510) id D821380002; Thu, 26 May 2005 11:28:56 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by larry.its.monash.edu.au (Postfix) with ESMTP id E96F03C00D for ; Thu, 26 May 2005 11:28:54 +1000 (EST) Received: by zproxy.gmail.com with SMTP id 13so307515nzn for ; Wed, 25 May 2005 18:28:53 -0700 (PDT) Received: by 10.36.157.10 with SMTP id f10mr413763nze; Wed, 25 May 2005 18:28:53 -0700 (PDT) Received: by 10.36.3.6 with HTTP; Wed, 25 May 2005 18:28:53 -0700 (PDT) Date: Thu, 26 May 2005 10:28:53 +0900 From: JinHyeock Choi Subject: Re: [DNA] Last call: Detection of Network Attachment (DNA) in IPv4 (fwd) In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb0505251828549f821e@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline 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:content-disposition:references; b=HaJjPnNrzg6dJCSDjDyEMEaYZ53O7Eht2Jld4CV22wANum+5nLNxpH4N+3JicocS91QVBxRPpcOOUTqcgrvQlW3mXoUN2kI6MgaZqgclQkwCPsp78vEjqwtyra4M3x1XhDTRlAPOK5Hm2HpDNgrmzLRo4ZSh1OCQ/0DGamjBp5w= X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <011201c560e7$b6462790$ed2f024b@jinchoe> <92e919fb05052500023ebad2dd@mail.gmail.com> Content-Transfer-Encoding: 7BIT > The DNAv4 draft does determine when the host needs to get some > configuration information from a DHCP server. The process for that is > governed by the DHCPv4 specification, though the DNAv4 spec does describe > the state that the DHCPv4 client should be in (INIT-REBOOT, etc.). ok. Then I see no difference between DNAv4 & DNA v6 w.r.t. this. > We will change the text to refer only to "Attachment Point". I come to think that we would better use "Point of Attachment" because we can't use abbreviation for "Attachment Point" and IEEE 802.21 WG is using "PoA" already. > In reviewing the document, I think that the term "Most Likely Point of > Attachment" really means "Most Likely Network", where as when the document > refers to changing the "point of attachment" it really means changing the > "attachment point". I agree. I think the term "Most Likely Point of Attachment" is confusing. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 21:41:19 2005 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 VAA20836 for ; Wed, 25 May 2005 21:41:18 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOPO2CFMWK9ANGAP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 May 2005 11:41:08 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2ACB8AB544; Thu, 26 May 2005 11:41: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 D55314FB0C; Thu, 26 May 2005 11:41:04 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4Q1evW13922 for dna-list; Thu, 26 May 2005 11:40:57 +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 j4Q1evr13918 for ; Thu, 26 May 2005 11:40:57 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOPO1X85UA99J1SN@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 May 2005 11:40:45 +1000 Received: by localhost (Postfix, from userid 510) id F26DF8005A; Thu, 26 May 2005 11:40:21 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by larry.its.monash.edu.au (Postfix) with ESMTP id 51A6F3C016 for ; Thu, 26 May 2005 11:40:20 +1000 (EST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IH2009S4PZ6LD@mailout2.samsung.com> for dna@eng.monash.edu.au; Thu, 26 May 2005 10:40:18 +0900 (KST) Received: from jinchoe ([75.2.43.239]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IH20042VPZ5JE@mmp2.samsung.com> for dna@eng.monash.edu.au; Thu, 26 May 2005 10:40:18 +0900 (KST) Date: Thu, 26 May 2005 10:40:17 +0900 From: JinHyeock Choi Subject: Re: [DNA] Revised terminology section for DNAv4 Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: dna@eng.monash.edu.au Message-id: <00bb01c56193$deef5200$ef2b024b@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 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> <4293D0F9.8070401@sun.com> <4293D49F.80905@eng.monash.edu.au> <008a01c5618f$54bff110$ef2b024b@jinchoe> Content-Transfer-Encoding: 7BIT > > With "Attachment Point", we could not use an abbreviation because > > usually AP means 802.11 thing. This we belatedly found out while > > writing a draft. With "Point of Attachment", we can use "PoA". > > IEEE 802.21 WG uses the term "Point of Attachment" and its > > abbreviation "PoA" > > OK. Ideally we would be consistent between 802.21, DNAv4 and DNAv6. Is > this possible? I think so. For DNAv4 & DNAv6, now there are few discrepancies aside the ones inherent in v4/ v6 differences. Also DNA WG has liaison relationship with IEEE 802.21 WG. We may ask chairs to synchronize the terminology with 802.21. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 21:49:47 2005 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 VAA21369 for ; Wed, 25 May 2005 21:49:46 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOPOBL0TEQ94NABM@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 May 2005 11:49:05 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 181F5AB544; Thu, 26 May 2005 11:48:32 +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 C00A34FB04; Thu, 26 May 2005 11:48:31 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4Q1mQU14059 for dna-list; Thu, 26 May 2005 11:48:26 +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 j4Q1mOr14055 for ; Thu, 26 May 2005 11:48:24 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOPOB3GQSS99J5KM@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 May 2005 11:48:08 +1000 Received: by localhost (Postfix, from userid 510) id 95F9BAB546; Thu, 26 May 2005 11:48:08 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201]) by curly.its.monash.edu.au (Postfix) with ESMTP id D3FF64FB0C for ; Thu, 26 May 2005 11:48:06 +1000 (EST) Received: by zproxy.gmail.com with SMTP id 13so310625nzn for ; Wed, 25 May 2005 18:48:05 -0700 (PDT) Received: by 10.36.157.11 with SMTP id f11mr421164nze; Wed, 25 May 2005 18:48:05 -0700 (PDT) Received: by 10.36.3.6 with HTTP; Wed, 25 May 2005 18:48:05 -0700 (PDT) Date: Thu, 26 May 2005 10:48:05 +0900 From: JinHyeock Choi Subject: Re: [DNA] Revised terminology section for DNAv4 In-reply-to: <042701c5614d$22d41e70$291d9069@sisa.samsung.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Alper Yegin Cc: Bernard Aboba , dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb0505251848a9e9701@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline 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:content-disposition:references; b=PDS1ugwncZH5a1vlq+WX3UbZc/KrS5HPMVsdTmfLPzdjlz9eb+77htQyfyS4tRaduGJocLToIIskT++MZ95VQUumXkrgL5AuZDVKL+DICFbiYSmWqdNDD9A17ZHBSy3ENWSz3Qsy3SKYvTNHdBcbejNkJdlJ6VEWSI5lR0x7vcA= X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <042701c5614d$22d41e70$291d9069@sisa.samsung.com> Content-Transfer-Encoding: 7BIT Dear Alper > > Link Down > > > > Link Up > > I think the main document to define these terms is the "L2 event > notifications for DNA" (dna-link-info) I-D. It will be of much help if dna-link-info I-D also defines other terms such as - Point of Attachment (Attachment Point) - Link - Valid address. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed May 25 23:11:54 2005 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 XAA29442 for ; Wed, 25 May 2005 23:11:52 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOPR7E4D5I971DG6@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 May 2005 13:11:45 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B8520AB542; Thu, 26 May 2005 13:11:26 +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 728AC4FB08; Thu, 26 May 2005 13:11:26 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4Q3B5c14955 for dna-list; Thu, 26 May 2005 13:11:05 +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 j4Q3B4r14951 for ; Thu, 26 May 2005 13:11:05 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOPR6MCDDC9ANRFX@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 May 2005 13:10:49 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6A26F80003; Thu, 26 May 2005 13:10:49 +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 469663C003; Thu, 26 May 2005 13:10:49 +1000 (EST) Date: Thu, 26 May 2005 13:10:48 +1000 From: Brett Pentland Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: <067c01c56143$fa6a9800$016115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: James Kempf Cc: Bernard Aboba , dna@eng.monash.edu.au Message-id: <42953E38.4010906@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) References: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> <4293D382.6040506@eng.monash.edu.au> <067c01c56143$fa6a9800$016115ac@dcml.docomolabsusa.com> Content-Transfer-Encoding: 7BIT > If the L2 software hides the L2 handover latency, then "Link Up" and Link > Down" never occur during handover, although they may occur at other times, > for example, if the terminal moves out of range of any base stations. If such a handover involves changing L3 links, then for DNA it would be really good to have "Link Up" or at least some kind of signal to trigger the DNA process. Brett. From dna-owner@webcamserver.eng.monash.edu.au Thu May 26 01:18:52 2005 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 BAA06735 for ; Thu, 26 May 2005 01:18:51 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOPVMY7HO8975X2R@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 May 2005 15:18:41 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4726980004; Thu, 26 May 2005 15:18:31 +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 EDBEE3C003; Thu, 26 May 2005 15:18:30 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4Q5I1T16330 for dna-list; Thu, 26 May 2005 15:18:01 +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 j4Q5I1r16326 for ; Thu, 26 May 2005 15:18:01 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOPVM5XD80975EXA@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 May 2005 15:17:53 +1000 Received: by localhost (Postfix, from userid 510) id DA43980003; Thu, 26 May 2005 15:17:52 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (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 637663C004 for ; Thu, 26 May 2005 15:17:51 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DbAke-000JSG-SM; Thu, 26 May 2005 01:17:48 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4Q5HkV01092; Wed, 25 May 2005 22:17:47 -0700 Date: Wed, 25 May 2005 22:17:46 -0700 (PDT) From: Bernard Aboba Subject: Re: [DNA] Last call: Detection of Network Attachment (DNA) in IPv4 (fwd) In-reply-to: <92e919fb0505251828549f821e@mail.gmail.com> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <011201c560e7$b6462790$ed2f024b@jinchoe> <92e919fb05052500023ebad2dd@mail.gmail.com> <92e919fb0505251828549f821e@mail.gmail.com> Content-Transfer-Encoding: 7BIT > I come to think that we would better use "Point of Attachment" > because we can't use abbreviation for "Attachment Point" and > IEEE 802.21 WG is using "PoA" already. OK. I will use "Point of Attachment" instead. From dna-owner@webcamserver.eng.monash.edu.au Thu May 26 03:50:03 2005 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 DAA07652 for ; Thu, 26 May 2005 03:50:02 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOQ0WU7X5494NBJS@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 May 2005 17:49:44 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 14E6A80004; Thu, 26 May 2005 17:49:16 +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 BD0CB3C008; Thu, 26 May 2005 17:49:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4Q7mQs17906 for dna-list; Thu, 26 May 2005 17:48:26 +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 j4Q7mPr17902 for ; Thu, 26 May 2005 17:48:25 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOQ0VLCUPC9ANSU1@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 May 2005 17:48:16 +1000 Received: by localhost (Postfix, from userid 510) id ACC1FAB543; Thu, 26 May 2005 17:48:15 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by curly.its.monash.edu.au (Postfix) with ESMTP id F27634FB0A for ; Thu, 26 May 2005 17:48:13 +1000 (EST) 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 <0IH300B3N70CMP@mailout1.samsung.com> for dna@eng.monash.edu.au; Thu, 26 May 2005 16:48:12 +0900 (KST) Received: from Alperyegin ([105.253.155.23]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IH300CP27082M@mmp2.samsung.com> for dna@eng.monash.edu.au; Thu, 26 May 2005 16:48:12 +0900 (KST) Date: Thu, 26 May 2005 00:47:11 -0700 From: Alper Yegin Subject: RE: [DNA] Revised terminology section for DNAv4 In-reply-to: <92e919fb0505251848a9e9701@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: "'JinHyeock Choi'" Cc: "'Bernard Aboba'" , dna@eng.monash.edu.au Message-id: <000201c561c7$225e2ab0$6401a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Hi JinHyeock, I think defining PoA and Link makes sense. But I don't think "valid address" belongs to the L2 event notifications context. Alper > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner- > dna@ecselists.eng.monash.edu.au] On Behalf Of JinHyeock Choi > Sent: Wednesday, May 25, 2005 6:48 PM > To: Alper Yegin > Cc: Bernard Aboba; dna@eng.monash.edu.au > Subject: Re: [DNA] Revised terminology section for DNAv4 > > Dear Alper > > > > Link Down > > > > > > Link Up > > > > I think the main document to define these terms is the "L2 event > > notifications for DNA" (dna-link-info) I-D. > > It will be of much help if dna-link-info I-D also defines other terms > such as > - Point of Attachment (Attachment Point) > - Link > - Valid address. > > Best Regards > > JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu May 26 05:46:01 2005 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 FAA14851 for ; Thu, 26 May 2005 05:46:00 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOQ4ZDG4NK99J3XS@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 May 2005 19:45:52 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A456C80004; Thu, 26 May 2005 19:45:50 +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 4C5933C009; Thu, 26 May 2005 19:45:50 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4Q9hMx19151 for dna-list; Thu, 26 May 2005 19:43:22 +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 j4Q9hMr19147 for ; Thu, 26 May 2005 19:43:22 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOQ4W1KHC2975SXK@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 May 2005 19:43:10 +1000 Received: by localhost (Postfix, from userid 510) id 9A11EAB543; Thu, 26 May 2005 19:43:09 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by curly.its.monash.edu.au (Postfix) with ESMTP id 0B4054FB08 for ; Thu, 26 May 2005 19:43:08 +1000 (EST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IH300MCNCBU7Q@mailout2.samsung.com> for dna@eng.monash.edu.au; Thu, 26 May 2005 18:43:06 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IH300JU9CBP23@mmp2.samsung.com> for dna@eng.monash.edu.au; Thu, 26 May 2005 18:43:06 +0900 (KST) Date: Thu, 26 May 2005 15:11:00 +0530 From: Syam Madanapalli Subject: [DNA] Usage of DNA Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <003701c561d7$09179310$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT I think DNA is useful for reactive handoffs, I am not really sure we can achieve the seamless mobility with the reactive handoffs. I think proactive handoff does better for seamless mobility. When FMIPv6 becomes popular, I doubt if we really need the DNA. My understanding is that DNA and FMIPv6 do not complement each other. Please shed some light on this. Thank you, Syam From dna-owner@webcamserver.eng.monash.edu.au Thu May 26 12:11:31 2005 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 MAA09462 for ; Thu, 26 May 2005 12:11:30 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOQIGANQWE9ANVSJ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 27 May 2005 02:11:24 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A200FAB543; Fri, 27 May 2005 02:11:19 +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 5A97E4FB06; Fri, 27 May 2005 02:11:19 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4QGAdk23199 for dna-list; Fri, 27 May 2005 02:10:39 +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 j4QGAcr23195 for ; Fri, 27 May 2005 02:10:38 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOQIFCSFOY94NEFI@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 27 May 2005 02:10:34 +1000 Received: by localhost (Postfix, from userid 510) id 4001780003; Fri, 27 May 2005 02:10:34 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id 6B8CC3C007; Fri, 27 May 2005 02:10:33 +1000 (EST) Date: Thu, 26 May 2005 09:11:38 -0700 From: James Kempf Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Bernard Aboba , dna@eng.monash.edu.au Message-id: <093b01c5620d$9d3acae0$016115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-Spam-Level: *** References: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> <4293D382.6040506@eng.monash.edu.au> <067c01c56143$fa6a9800$016115ac@dcml.docomolabsusa.com> <42953E38.4010906@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Brett, > > If the L2 software hides the L2 handover latency, then "Link Up" and Link > > Down" never occur during handover, although they may occur at other times, > > for example, if the terminal moves out of range of any base stations. > > If such a handover involves changing L3 links, then for DNA it would be > really good to have "Link Up" or at least some kind of signal to trigger > the DNA process. > Yes, but I think that a radio protocol that supports make-before-break would have to support that independently of DNA. Even if it uses RFC 2461, it still needs some way to trigger the RS. But I'm speculating. Is Hesham or George on this list? They are at Flarion, which has a make-before-break radio protocol, perhaps they could tell us how IP link handover is triggered. jak From dna-owner@webcamserver.eng.monash.edu.au Thu May 26 21:48:27 2005 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 VAA02504 for ; Thu, 26 May 2005 21:48:26 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOR2LIX0JK9ANW2U@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 27 May 2005 11:48:15 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5F4D4AB543; Fri, 27 May 2005 11:48:12 +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 1A55C4FB07; Fri, 27 May 2005 11:48:12 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4R1lI029518 for dna-list; Fri, 27 May 2005 11:47: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 j4R1lHr29514 for ; Fri, 27 May 2005 11:47:17 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOR2K1MSO894NBFB@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 27 May 2005 11:47:01 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B821CAB543; Fri, 27 May 2005 11:47:00 +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 898314FB03; Fri, 27 May 2005 11:47:00 +1000 (EST) Date: Fri, 27 May 2005 11:46:59 +1000 From: Greg Daley Subject: Re: [DNA] Usage of DNA In-reply-to: <003701c561d7$09179310$59476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: dna@eng.monash.edu.au, Rajeev Koodli Reply-to: greg.daley@eng.monash.edu.au Message-id: <42967C13.6070103@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 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <003701c561d7$09179310$59476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Hi Syam, Syam Madanapalli wrote: > > > I think DNA is useful for reactive handoffs, I am not really sure we can > achieve the seamless > > mobility with the reactive handoffs. I think proactive handoff does > better for seamless mobility. DNA is not intended to replace FMIPv6. Nor is it strictly tied to mobility: Othewise it would be called "Movement Detection" rather than "Detecting Network Attachment" (nifty acronym notwithstanding). So there are scenarios which aren't strictly mobility or (even if they are) aren't handover related which may be applicable to DNA. For example: radio base-station failure and reselection, base station movement (such as LEO satellites) data squirting after device sleeping, etc. Also in some types of access networks, there may not be a predictive FMIPv6 for long time yet. DNA may well fill a role supporting "sufficiently fast" (though not seamless) handovers within those networks. > When FMIPv6 becomes popular, I doubt if we really need the DNA. My > understanding is that > > DNA and FMIPv6 do not complement each other. Please shed some light on > this. FMIPv6 is a mechanism which can make use of prediction, but also has a reactive scenario for when prediction fails or is unavailable. Rapid determination that the link is not what was intended (using DNA) should help even hosts with FMIPv6. You are right in saying that a successful FMIPv6 handover may be able to remove the need for DNA on a particular base-station handover. One of the sections of the DNA hosts BCP has been intended to include details of interactions with RFC experimental protocols such as FMIPv6 and CARD. If a clarifying statement about that would be useful, then we can start working on the text. Does this answer your query? Greg From dna-owner@webcamserver.eng.monash.edu.au Fri May 27 04:35:44 2005 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 EAA20846 for ; Fri, 27 May 2005 04:35:42 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LORGT4ULX099J6JJ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 27 May 2005 18:35:16 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 20CA6AB544; Fri, 27 May 2005 18:35:12 +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 C689F4FB06; Fri, 27 May 2005 18:35:11 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4R8YH302256 for dna-list; Fri, 27 May 2005 18:34:17 +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 j4R8YHr02252 for ; Fri, 27 May 2005 18:34:17 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LORGRQ72FA99J3EK@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 27 May 2005 18:34:04 +1000 Received: by localhost (Postfix, from userid 510) id 4B969AB542; Fri, 27 May 2005 18:34:04 +1000 (EST) Received: from rsys001x.roke.co.uk (rsys001x.roke.co.uk [193.118.201.108]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 2ABFC4FB03 for ; Fri, 27 May 2005 18:34:00 +1000 (EST) Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j4R8XqlU029881 for ; Fri, 27 May 2005 09:33:52 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 27 May 2005 09:35:07 +0100 Date: Fri, 27 May 2005 09:34:49 +0100 From: "McCann, Stephen" Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Cc: "Hepworth, Eleanor" Message-id: <3F2E01E1D7B04F4EBEC92D3FA324D880385F1C@rsys004a> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: stephen.mccann@roke.co.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Dear all, Generalising this conversation, it appears to me that some sort of L2 media specific "Link Up" indication is a potential requirement for DNA. Hence is it a potential issue for the current work in the IEEE 802.11u and IEEE 802.16g groups, to name but two? Kind regards Stephen > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, May 26, 2005 5:12 PM > To: Brett Pentland > Cc: Bernard Aboba; dna@eng.monash.edu.au > Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? > > > Brett, > > > > If the L2 software hides the L2 handover latency, then > "Link Up" and > Link > > > Down" never occur during handover, although they may > occur at other > times, > > > for example, if the terminal moves out of range of any base > > > stations. > > > > If such a handover involves changing L3 links, then for DNA > it would > > be really good to have "Link Up" or at least some kind of signal to > > trigger the DNA process. > > > > Yes, but I think that a radio protocol that supports > make-before-break would have to support that independently of > DNA. Even if it uses RFC 2461, it still needs some way to > trigger the RS. > > But I'm speculating. Is Hesham or George on this list? They > are at Flarion, which has a make-before-break radio protocol, > perhaps they could tell us how IP link handover is triggered. > > jak > > -- Visit our website at www.roke.co.uk Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK. The information contained in this e-mail and any attachments is proprietary to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. From dna-owner@webcamserver.eng.monash.edu.au Fri May 27 07:29:26 2005 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 HAA01512 for ; Fri, 27 May 2005 07:29:25 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LORMVL3LOA94NECH@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 27 May 2005 21:29:17 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 830B8AB545; Fri, 27 May 2005 21:28:58 +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 20F9F4FB0D; Fri, 27 May 2005 21:28:58 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4RBSOI04118 for dna-list; Fri, 27 May 2005 21:28:24 +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 j4RBSNr04114 for ; Fri, 27 May 2005 21:28:23 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LORMUIRY6694NECH@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 27 May 2005 21:28:07 +1000 Received: by localhost (Postfix, from userid 510) id 5B151AB543; Fri, 27 May 2005 21:28:07 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by curly.its.monash.edu.au (Postfix) with ESMTP id AC17A4FB02; Fri, 27 May 2005 21:28:05 +1000 (EST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IH5007DNBURD9@mailout2.samsung.com>; Fri, 27 May 2005 20:28:04 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IH5008Y3BUQLA@mmp1.samsung.com>; Fri, 27 May 2005 20:28:03 +0900 (KST) Date: Fri, 27 May 2005 16:55:59 +0530 From: Syam Madanapalli Subject: Re: [DNA] Usage of DNA Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au, Rajeev Koodli Message-id: <007401c562ae$dc5f45b0$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <003701c561d7$09179310$59476c6b@sisodomain.com> <42967C13.6070103@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, I think it is clear now for me about the DNA. I asked this question because the DNAv6 solution looks pretty heavy and complex (this is my current understanding, please do not ask me for the simpler solution) and felt not much useful if it is not complementing/aligned towards FMIPv6 and CARD. I just looked into the DNAv6 BCP for Hosts, Appendix C and D are empty now, I think it is worth filling these sections. Thank you, Syam > Hi Syam, > > Syam Madanapalli wrote: >> >> >> I think DNA is useful for reactive handoffs, I am not really sure we can >> achieve the seamless >> >> mobility with the reactive handoffs. I think proactive handoff does >> better for seamless mobility. > > DNA is not intended to replace FMIPv6. Nor is it strictly tied to > mobility: Othewise it would be called "Movement Detection" rather than > "Detecting Network Attachment" (nifty acronym notwithstanding). > > So there are scenarios which aren't strictly mobility or (even if they > are) aren't handover related which may be applicable to DNA. > > For example: > > radio base-station failure and reselection, > base station movement (such as LEO satellites) > data squirting after device sleeping, etc. > > Also in some types of access networks, there may not be a > predictive FMIPv6 for long time yet. > > DNA may well fill a role supporting "sufficiently fast" > (though not seamless) handovers within those networks. > >> When FMIPv6 becomes popular, I doubt if we really need the DNA. My >> understanding is that >> >> DNA and FMIPv6 do not complement each other. Please shed some light on >> this. > > FMIPv6 is a mechanism which can make use of prediction, but also has > a reactive scenario for when prediction fails or is unavailable. > > Rapid determination that the link is not what was intended (using DNA) > should help even hosts with FMIPv6. > > You are right in saying that a successful FMIPv6 handover may be able > to remove the need for DNA on a particular base-station handover. > One of the sections of the DNA hosts BCP has been intended to include > details of interactions with RFC experimental protocols such as FMIPv6 > and CARD. > > If a clarifying statement about that would be useful, then we can start > working on the text. > > Does this answer your query? > > Greg > > From dna-owner@webcamserver.eng.monash.edu.au Fri May 27 11:24:16 2005 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 LAA20725 for ; Fri, 27 May 2005 11:24:15 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LORV2JW8F09ANVCF@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 28 May 2005 01:23:42 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8C64AAB545; Sat, 28 May 2005 01:23:39 +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 2E3244FB06; Sat, 28 May 2005 01:23:39 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4RFN1w06635 for dna-list; Sat, 28 May 2005 01:23:01 +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 j4RFN1r06631 for ; Sat, 28 May 2005 01:23:01 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LORV1KF78099JBFP@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 28 May 2005 01:22:52 +1000 Received: by localhost (Postfix, from userid 510) id 169CBAB543; Sat, 28 May 2005 01:22:52 +1000 (EST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 51BD94FB06 for ; Sat, 28 May 2005 01:22:50 +1000 (EST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1DbgfZ-0000lQ-TZ; Fri, 27 May 2005 17:22:45 +0200 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtps id 1DbgfY-0005UI-Lf; Fri, 27 May 2005 17:22:40 +0200 Date: Fri, 27 May 2005 17:22:40 +0200 From: Christian Vogt Subject: [DNA] Feedback on draft-ietf-dna-cpl-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: Jinhyeock Choi , Erik Nordmark Cc: DNA , TM-RO2 Message-id: <42973B40.1010009@tm.uka.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-15; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: de-DE, de, en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Hi JinHyeock, hi Erik, I took a look at the Complete Prefix List proposal. First of all, I like the idea of not having to change any entities in the network but only the MN's stack. This is a significant advantage in terms of applicability until more radical DNA techniques establish themselves. On thing concerning reliance on unsolicited RAs. Section 3.1 says: ++++ The host forms the prefix list at any attachment point, that is, this process starts independently of any movement. Though the procedure may take some time, that doesn't matter unless the host moves very fast. A host can generate the complete prefix list with reasonable certainty if it remains attached to a link sufficiently long. It will take approximately 12 seconds, when it actively perform 3 RS/ RA exchanges. If it passively relies on unsolicited RA messages instead, it may take much more time. ++++ I see that one cannot really do much analysis for routers that send unsolicited RAs every 30ms to 70ms as proposed by RFC 3775 (because such RA might not have all of the prefixes included). But since this high frequency would obviously improve the situation for CPL, it might be worthwhile to put a note into the draft. I presume you are planning to do, or have already done, some experimental tests to find out how well CPL works when MNs move really fast. Well, maybe this can be done on a theoretic basis like the Performance Analysis in section 9. I do understand that CPL is 100% reliable, even in high-speed scenarios, when the prefix sets in RAs from the same link are guaranteed to overlap. The draft is on its way to Proposed Standard, right? Kind regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ From dna-owner@webcamserver.eng.monash.edu.au Fri May 27 16:55:00 2005 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 QAA03340 for ; Fri, 27 May 2005 16:54:58 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOS6MS6WJ8975ZI0@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 28 May 2005 06:54:55 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AA06BAB545; Sat, 28 May 2005 06:54:32 +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 5EB5F4FB06; Sat, 28 May 2005 06:54:32 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4RKrpq10305 for dna-list; Sat, 28 May 2005 06:53:51 +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 j4RKror10301 for ; Sat, 28 May 2005 06:53:50 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOS6LVLO88975ZI0@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 28 May 2005 06:53:49 +1000 Received: by localhost (Postfix, from userid 510) id F1CC980002; Sat, 28 May 2005 06:53:48 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by larry.its.monash.edu.au (Postfix) with ESMTP id 63A6F3C009; Sat, 28 May 2005 06:53:47 +1000 (EST) 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 <0IH6003VC21KVF@mailout1.samsung.com>; Sat, 28 May 2005 05:53:44 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IH60082I21HLA@mmp1.samsung.com>; Sat, 28 May 2005 05:53:43 +0900 (KST) Date: Fri, 27 May 2005 13:52:44 -0700 From: Alper Yegin Subject: RE: [DNA] Ideas for ethernet section of draft-ietf-dna-link-information In-reply-to: <421BC12A.70204@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au, dna@eng.monash.edu.au Message-id: <014401c562fe$0949bd90$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) Content-Transfer-Encoding: 7BIT Greg, Going back to your 802.3 text.... Reading your text, my understanding is: - The host MUST learn if the adjacent port is running STP or RSTP. - The additional delay is 0 if STP/RSTP is not detected. Delay is learned from the RSTP/STP signaling when present. - The link up MUST be generated "delay" seconds after PMA_LINK.indicate(OK). - The link down MUST be generated immediately after PMA_LINK.indicate(FAIL). Is that right? You text uses "may"s. If you agree, we shall update it with the "MUST"s as above. Alper From dna-owner@webcamserver.eng.monash.edu.au Fri May 27 20:37:55 2005 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 UAA18030 for ; Fri, 27 May 2005 20:37:54 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOSEFLZ6NK9ANW4Z@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 28 May 2005 10:37:51 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9B1D0AB543; Sat, 28 May 2005 10:37:49 +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 564414FB05; Sat, 28 May 2005 10:37:49 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4S0bD612644 for dna-list; Sat, 28 May 2005 10:37:13 +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 j4S0bDr12640 for ; Sat, 28 May 2005 10:37:13 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOSEELV780976JUU@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 28 May 2005 10:37:01 +1000 Received: by localhost (Postfix, from userid 510) id 2D7F4AB543; Sat, 28 May 2005 10:37:01 +1000 (EST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by curly.its.monash.edu.au (Postfix) with ESMTP id 677E74FB03 for ; Sat, 28 May 2005 10:36:59 +1000 (EST) Received: by zproxy.gmail.com with SMTP id 13so897297nzn for ; Fri, 27 May 2005 17:36:58 -0700 (PDT) Received: by 10.36.72.4 with SMTP id u4mr1306899nza; Fri, 27 May 2005 17:36:58 -0700 (PDT) Received: by 10.36.3.6 with HTTP; Fri, 27 May 2005 17:36:58 -0700 (PDT) Date: Sat, 28 May 2005 09:36:58 +0900 From: JinHyeock Choi Subject: [DNA] [New I-D] DNA Solution: Link Identifier based approach In-reply-to: <421BC12A.70204@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: greg.daley@eng.monash.edu.au Cc: dna@eng.monash.edu.au Reply-to: JinHyeock Choi Message-id: <92e919fb05052717366bb2ce24@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline 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:content-disposition:references; b=oXKMLRUiXdPZ5ymsm2e941FO7ShcvTHNY3t7CO/hBD8oAGM+eqpC/MF2kHf8vC5v3xQc5YYWS3pseA4TMpkJn5qanqG90SylKoNOkzZsGycV9rLuWk3PPBBssRg/UOC+xPemR/whq0DkOGggG/3PA/09pSJDRS3w6amXW3OMmwA= X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <421BC12A.70204@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear DNA Group We submitted the following draft as a solution work. DNA Solution: Link Identifier based approach draft-jinchoi-dna-protocol2-00.txt As Brett mentioned, two approaches were discussed in DT, Landmark based & Link Identifier based. The draft presents the second one and describes how to check for link change with the prefix based linkid. Routers pick the smallest prefix as the linkid prefix and include the linkid prefix in every RA. In short, if a host sees the same linkid prefix, it is at the same link and if it sees a different linkid prefix, it has moved to a new link. This document is available at the URL: http://www.diffeo.com/drafts/draft-jinchoi-dna-protocol2-00.txt We are looking forward to your feedback. Best Regards JinHyeock Choi From dna-owner@webcamserver.eng.monash.edu.au Sat May 28 17:00:04 2005 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 RAA03201 for ; Sat, 28 May 2005 17:00:03 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOTL38QR1897642E@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sun, 29 May 2005 06:59:38 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 26D4BAB54A; Sun, 29 May 2005 06:59:28 +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 BEBDB4FB05; Sun, 29 May 2005 06:59:27 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4SKwI729196 for dna-list; Sun, 29 May 2005 06:58:18 +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 j4SKwHr29192 for ; Sun, 29 May 2005 06:58:17 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOTL1ISP3294NUF0@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sun, 29 May 2005 06:58:05 +1000 Received: by localhost (Postfix, from userid 510) id 189A6AB543; Sun, 29 May 2005 06:58:05 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 783CB4FB04 for ; Sun, 29 May 2005 06:58:03 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1Dc8Nc-000LBe-Ba for dna@eng.monash.edu.au; Sat, 28 May 2005 16:58:00 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4SKvwE08194 for ; Sat, 28 May 2005 13:57:59 -0700 Date: Sat, 28 May 2005 13:57:58 -0700 (PDT) From: Bernard Aboba Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: <4293D0F9.8070401@sun.com> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> <4293D0F9.8070401@sun.com> Content-Transfer-Encoding: 7BIT Erik Nordmark wisely observed: > I think it would be good if the definitions would clarify that even if > the link layer on the host sees 100% packet loss for a short while, it > doesn't necessarily imply that a link down event should be generated. > (It presumably shouldn't be generated until the link layer abandons the > L2 association/connection/whatever.) How about this? Link Down An event provided by the link layer that signifies a state change associated with the interface no longer being capable of communicating IP packets. A Link Down event is only generated once the link layer considers the link unusable; transient periods of high frame loss are not sufficient. Link Up An event provided by the link layer that signifies a state change associated with the interface becoming capable of communicating IP packets. From dna-owner@webcamserver.eng.monash.edu.au Sun May 29 13:31:56 2005 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 NAA28187 for ; Sun, 29 May 2005 13:31:55 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOUS4RGYKG9770E2@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 30 May 2005 03:31:44 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B3FB3AB545; Mon, 30 May 2005 03:31:31 +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 4C8414FB02; Mon, 30 May 2005 03:31:31 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4THUiN09423 for dna-list; Mon, 30 May 2005 03:30: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 j4THUhr09419 for ; Mon, 30 May 2005 03:30:43 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOUS3GO1489ANVYM@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 30 May 2005 03:30:29 +1000 Received: by localhost (Postfix, from userid 510) id EEC80AB543; Mon, 30 May 2005 03:30:28 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 565194FB03 for ; Mon, 30 May 2005 03:30:27 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DcRcG-000E2x-LU for dna@eng.monash.edu.au; Sun, 29 May 2005 13:30:24 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4THUN320511 for ; Sun, 29 May 2005 10:30:23 -0700 Date: Sun, 29 May 2005 10:30:23 -0700 (PDT) From: Bernard Aboba Subject: [DNA] Router implementation survey In-reply-to: <92e919fb05052717366bb2ce24@mail.gmail.com> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <421BC12A.70204@eng.monash.edu.au> <92e919fb05052717366bb2ce24@mail.gmail.com> Content-Transfer-Encoding: 7BIT In IETF last call for the DNAv4 document, a question was raised about the behavior of routers with respect to ARP Probes (ARP Request with sender address = 0.0.0.0) If you have been involved in a router implementation, please answer the following questions and send the answers to me: a. After booting and configuring interface addresses, does your implementation answer ARP Probes for its address? b. When a static IPv4 address is assigned on an interface, what does your implementation do prior to using the address? 1. Does nothing, just uses the address. 2. Sends an ARP Announcement (otherwise known as "Gratuitous ARP") 3. Broadcasts an ARP Reply 4. Sends an ARP Probe (ARP Request for the address, with sender address = 0.0.0.0) 5. Behaves as specified in draft-cheshire-ipv4-acd-03.txt (multiple ARP probes followed by ARP Announcement) c. If your implementation behaves as specified in the acd document, how does it behave if it receives an ARP probe for its address during the period in which it is probing for that same address? 1. Interprets the probe as indication of an address conflict and stops using the address. 2. Logs the conflict but does not stop using the address. 3. Ignores the probe. From dna-owner@webcamserver.eng.monash.edu.au Sun May 29 19:01:17 2005 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 TAA04084 for ; Sun, 29 May 2005 19:01:16 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOV3MIP9TG9ANR29@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 30 May 2005 09:01:15 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F0440AB543; Mon, 30 May 2005 09:01:11 +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 B0A1F4FB03; Mon, 30 May 2005 09:01:11 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4TMxm813054 for dna-list; Mon, 30 May 2005 08:59: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 j4TMxmr13049 for ; Mon, 30 May 2005 08:59:48 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOV3KGA3S49ANR29@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 30 May 2005 08:59:32 +1000 Received: by localhost (Postfix, from userid 510) id 15EEEAB543; Mon, 30 May 2005 08:59:31 +1000 (EST) Received: from tayrelbas03.tay.hp.com (tayrelbas03.tay.hp.com [161.114.80.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 7B5614FB04 for ; Mon, 30 May 2005 08:59:29 +1000 (EST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id EA4F5134 for ; Sun, 29 May 2005 18:59:23 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Sun, 29 May 2005 18:59:23 -0400 Date: Sun, 29 May 2005 18:59:22 -0400 From: "Bound, Jim" Subject: RE: [DNA] Definition of "Link Up" and "Link Down" events? Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: dna@eng.monash.edu.au Message-id: <936A4045C332714F975800409DE092405416E1@tayexc14.americas.cpqcorp.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] Definition of "Link Up" and "Link Down" events? Thread-Index: AcVgxvu7TrenPT+4QryJTv7noVPBdgD2oPsw Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) X-OriginalArrivalTime: 29 May 2005 22:59:23.0793 (UTC) FILETIME=[0E561810:01C564A2] Content-Transfer-Encoding: 7BIT > I think it would be good if the definitions would clarify > that even if > the link layer on the host sees 100% packet loss for a short > while, it > doesn't necessarily imply that a link down event should be generated. > (It presumably shouldn't be generated until the link layer > abandons the > L2 association/connection/whatever.) I agree in theory. In practice I may implement to bring the link-down, if it is not my only link-access, as far as IP stack is concerned. Reason is node/device may have multiple link-access mediums and this one is not performing. I think we all understand where I am going. My reason for stating the obvious is does this context affect what we do within DNA? /jim From dna-owner@webcamserver.eng.monash.edu.au Sun May 29 20:35:35 2005 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 UAA09751 for ; Sun, 29 May 2005 20:35:34 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOV6WPZW8E976WKL@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 30 May 2005 10:35:17 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 043A580006; Mon, 30 May 2005 10:34:56 +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 AA1A03C006; Mon, 30 May 2005 10:34:55 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4U0YZo14074 for dna-list; Mon, 30 May 2005 10:34: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 j4U0YYr14070 for ; Mon, 30 May 2005 10:34:34 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOV6W2ANMU97762F@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 30 May 2005 10:34:25 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3489A80007; Mon, 30 May 2005 10:34:24 +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 06A173C006; Mon, 30 May 2005 10:34:24 +1000 (EST) Date: Mon, 30 May 2005 10:34:23 +1000 From: Greg Daley Subject: Re: [DNA] Usage of DNA In-reply-to: <007401c562ae$dc5f45b0$59476c6b@sisodomain.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: dna@eng.monash.edu.au, Rajeev Koodli Reply-to: greg.daley@eng.monash.edu.au Message-id: <429A5F8F.3080103@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 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <003701c561d7$09179310$59476c6b@sisodomain.com> <42967C13.6070103@eng.monash.edu.au> <007401c562ae$dc5f45b0$59476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Hi Syam, Syam Madanapalli wrote: > Hi Greg, > > I think it is clear now for me about the DNA. I asked this question > because the DNAv6 solution looks pretty heavy and complex (this > is my current understanding, please do not ask me for the simpler solution) > and felt not much useful if it is not complementing/aligned towards FMIPv6 > and CARD. Any specific comments on the solution may help to clarify complexities. > I just looked into the DNAv6 BCP for Hosts, Appendix C and D are > empty now, I think it is worth filling these sections. Thanks for the feedback. We'll look into it. Greg From dna-owner@webcamserver.eng.monash.edu.au Sun May 29 20:54:25 2005 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 UAA10576 for ; Sun, 29 May 2005 20:54:24 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOV7KNWTG29ANYHL@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 30 May 2005 10:54:18 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 29C2280003; Mon, 30 May 2005 10:54:14 +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 BA67B3C004; Mon, 30 May 2005 10:54:13 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4U0s4e14330 for dna-list; Mon, 30 May 2005 10:54:04 +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 j4U0s3r14326 for ; Mon, 30 May 2005 10:54:03 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOV7K2KVS4976Y96@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 30 May 2005 10:53:46 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7EEFD80004; Mon, 30 May 2005 10:53:45 +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 5C41F3C00A; Mon, 30 May 2005 10:53:45 +1000 (EST) Date: Mon, 30 May 2005 10:53:44 +1000 From: Greg Daley Subject: Re: [DNA] Ideas for ethernet section of draft-ietf-dna-link-information In-reply-to: <014401c562fe$0949bd90$291d9069@sisa.samsung.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Alper Yegin Cc: dna@eng.monash.edu.au Reply-to: greg.daley@eng.monash.edu.au Message-id: <429A6418.5050604@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 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <014401c562fe$0949bd90$291d9069@sisa.samsung.com> Content-Transfer-Encoding: 7BIT Hi Alper, Alper Yegin wrote: > Greg, > > Going back to your 802.3 text.... > > Reading your text, my understanding is: > > - The host MUST learn if the adjacent port is running STP or RSTP. > - The additional delay is 0 if STP/RSTP is not detected. Delay is > learned from the RSTP/STP signaling when present. I guess that if the delay is 0 there's still a likelihood that the event is wrong (it degrades the hint). Since a lot of ports may default to a proprietary 'port fast' environment like Cisco's it may be OK in many cases. Since you don't know which port you're connected to, you can't know at zero time whether or not the port is up for data forwarding. If you were to get a subsequent hint: "forwarding available at time+t (by the way, the last hint was broken)", then there may actually be a case for retransmission (for DNA), but damage could have already been done to upper-layer flows which may need retransmission of data (the same issue exists when DNA has not yet completed). I'd guess that this is OK (re-hinting), so long as there's information in the draft illustrating the issue. > - The link up MUST be generated "delay" seconds after > PMA_LINK.indicate(OK). I don't think this is possible, unless there's an immediate signal at zero time (which may constitute a degraded indication), > - The link down MUST be generated immediately after > PMA_LINK.indicate(FAIL). Immediately after fail sounds good. > Is that right? > > You text uses "may"s. If you agree, we shall update it with the "MUST"s > as above. There are some serious issues since there's no beacon for ethernet before you connect to identify the peer. I'll cogitate on this for a little while. Comments welcome. Greg From dna-owner@webcamserver.eng.monash.edu.au Sun May 29 23:11:26 2005 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 XAA18496 for ; Sun, 29 May 2005 23:11:25 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOVCDAB53W9774CA@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 30 May 2005 13:11:16 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A8A8AAB54D; Mon, 30 May 2005 13:11: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 5D6654FB08; Mon, 30 May 2005 13:11:03 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4U3AWl15862 for dna-list; Mon, 30 May 2005 13:10:32 +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 j4U3AVr15858 for ; Mon, 30 May 2005 13:10:31 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOVCCEOTGA94KUSE@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 30 May 2005 13:10:22 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2E3A8AB550; Mon, 30 May 2005 13:10:21 +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 F1D7B4FB07; Mon, 30 May 2005 13:10:20 +1000 (EST) Date: Mon, 30 May 2005 13:10:15 +1000 From: Greg Daley Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: <3F2E01E1D7B04F4EBEC92D3FA324D880385F1C@rsys004a> Sender: owner-dna@ecselists.eng.monash.edu.au To: "McCann, Stephen" Cc: dna@eng.monash.edu.au, "Hepworth, Eleanor" Reply-to: greg.daley@eng.monash.edu.au Message-id: <429A8417.6060607@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 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <3F2E01E1D7B04F4EBEC92D3FA324D880385F1C@rsys004a> Content-Transfer-Encoding: 7BIT Hi Stephen, Thanks for speaking up. I guess that within 802.11u, there's a good chance of being able to distinguish between change within the DS and between DS's. Personally, I think that sort of distinction can be very helpful in DNAv6, since it would be possible to defer some reachability and configuration change tests until after IPv6 Neighbour Discovery timers expire (5-30 seconds or more:- potentially never). There's also potential interactions with 802.21 MIH, for similar reasons. Greg (Speaking personally, rather than as a chair). McCann, Stephen wrote: > Dear all, > Generalising this conversation, it appears to me that some sort of L2 > media specific "Link Up" indication is a potential requirement for DNA. > > Hence is it a potential issue for the current work in the IEEE 802.11u and IEEE 802.16g groups, to name but two? > > Kind regards > > Stephen > > >>-----Original Message----- >>From: James Kempf [mailto:kempf@docomolabs-usa.com] >>Sent: Thursday, May 26, 2005 5:12 PM >>To: Brett Pentland >>Cc: Bernard Aboba; dna@eng.monash.edu.au >>Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? >> >> >>Brett, >> >> >>>>If the L2 software hides the L2 handover latency, then >> >>"Link Up" and >>Link >> >>>>Down" never occur during handover, although they may >> >>occur at other >>times, >> >>>>for example, if the terminal moves out of range of any base >>>>stations. >>> >>>If such a handover involves changing L3 links, then for DNA >> >>it would >> >>>be really good to have "Link Up" or at least some kind of signal to >>>trigger the DNA process. >>> >> >>Yes, but I think that a radio protocol that supports >>make-before-break would have to support that independently of >>DNA. Even if it uses RFC 2461, it still needs some way to >>trigger the RS. >> >>But I'm speculating. Is Hesham or George on this list? They >>are at Flarion, which has a make-before-break radio protocol, >>perhaps they could tell us how IP link handover is triggered. >> >> jak >> >> > > From dna-owner@webcamserver.eng.monash.edu.au Mon May 30 02:15:58 2005 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 CAA12899 for ; Mon, 30 May 2005 02:15:57 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOVIT69DNE99JI0Q@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 30 May 2005 16:15:43 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 35BC1AB545; Mon, 30 May 2005 16:15:40 +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 E48834FB02; Mon, 30 May 2005 16:15:39 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4U6FAL17824 for dna-list; Mon, 30 May 2005 16:15:10 +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 j4U6F8r17820 for ; Mon, 30 May 2005 16:15:08 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOVISCG2BK9770B8@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 30 May 2005 16:15:00 +1000 Received: by localhost (Postfix, from userid 510) id 3F34EAB543; Mon, 30 May 2005 16:15:00 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id A6D114FB10; Mon, 30 May 2005 16:14:58 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DcdY7-0004Md-7m; Mon, 30 May 2005 02:14:55 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4U6EqI01282; Sun, 29 May 2005 23:14:53 -0700 Date: Sun, 29 May 2005 23:14:52 -0700 (PDT) From: Bernard Aboba Subject: Re: [DNA] Ideas for ethernet section of draft-ietf-dna-link-information In-reply-to: <429A6418.5050604@eng.monash.edu.au> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: Alper Yegin , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <014401c562fe$0949bd90$291d9069@sisa.samsung.com> <429A6418.5050604@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT > There are some serious issues since there's no beacon for ethernet > before you connect to identify the peer. Not necessarily. There may be beacons from 802.1AB. From dna-owner@webcamserver.eng.monash.edu.au Mon May 30 07:08:57 2005 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 HAA05885 for ; Mon, 30 May 2005 07:08:56 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOVT0YMEZ694O8QG@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 30 May 2005 21:08:50 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 923BDAB54A; Mon, 30 May 2005 21:08:16 +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 4CE604FB03; Mon, 30 May 2005 21:08:16 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4UB7fu20957 for dna-list; Mon, 30 May 2005 21:07:41 +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 j4UB7er20953 for ; Mon, 30 May 2005 21:07:40 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOVSZV8RJ894O8QG@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 30 May 2005 21:07:24 +1000 Received: by localhost (Postfix, from userid 510) id DA63E80002; Mon, 30 May 2005 21:07:23 +1000 (EST) Received: from sm.sait.samsung.co.kr (unknown [202.20.142.15]) by larry.its.monash.edu.au (Postfix) with ESMTP id AFA913C009 for ; Mon, 30 May 2005 21:07:21 +1000 (EST) Received: from sm.sait.samsung.co.kr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9B471E5AC6; Mon, 30 May 2005 20:04:15 +0900 (KST) Received: from 127.0.0.1 by 127.0.0.1(smtpfilter) with ESMTP; Mon, 30 May 2005 20:04:15 +0900 (KST) Received: from jinchoe (unknown [75.2.47.238]) by sm.sait.samsung.co.kr (Postfix) with SMTP id:0E2F3E5AAE; Mon, 30 May 2005 20:04:15 +0900 (KST) Date: Mon, 30 May 2005 20:07:18 +0900 From: JinHyeock Choi Subject: Re: [DNA] Feedback on draft-ietf-dna-cpl-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: Christian Vogt , Jinhyeock Choi , Erik Nordmark Cc: DNA , TM-RO2 Message-id: <01f601c56507$bec1b730$ee2f024b@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-15 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <42973B40.1010009@tm.uka.de> Content-Transfer-Encoding: 7BIT Dear Christian Thanks for your kind and insightful feedback. > I took a look at the Complete Prefix List proposal. > > First of all, I like the idea of not having to change any entities in > the network but only the MN's stack. This is a significant advantage in > terms of applicability until more radical DNA techniques establish > themselves. ok. glad to hear that. > On thing concerning reliance on unsolicited RAs. Section 3.1 says: > > ++++ > The host forms the prefix list at any attachment point, that is, this > process starts independently of any movement. Though the procedure > may take some time, that doesn't matter unless the host moves very > fast. A host can generate the complete prefix list with reasonable > certainty if it remains attached to a link sufficiently long. It > will take approximately 12 seconds, when it actively perform 3 RS/ RA > exchanges. If it passively relies on unsolicited RA messages > instead, it may take much more time. > ++++ > > I see that one cannot really do much analysis for routers that send > unsolicited RAs every 30ms to 70ms as proposed by RFC 3775 (because such > RA might not have all of the prefixes included). But since this high > frequency would obviously improve the situation for CPL, it might be > worthwhile to put a note into the draft. ok. I think it is ok for a host to send 1 RS and waits for 4 secs to collect (solicited) RAs and declare its prefix list (CCL) complete. Without a packet loss, the host will generate the complete prefix list. Even some packet loss may cause an incomplete prefix list, there is a further chance for the host to get the missing prefixes before it receives link UP notification, i.e. moves to another AP. Even the host moves to another AP with incomplete prefix list, the first RA may contain the prefix in its prefix list. Considering all those above, even if the host performs only one RS/ RA exchange, it will be very rare for the host to falsely assume a link change. Even in case of such a false assumption, there will not be a communication disruption but only unnecessary signaling. So I think such an occasional unnecessary signaling is acceptable and 1 RS/ RA exchange is enough for the complete prefix list generation. How do you think of it? > I presume you are planning to do, or have already done, some > experimental tests to find out how well CPL works when MNs move really > fast. Well, maybe this can be done on a theoretic basis like the > Performance Analysis in section 9. We have an implementation plan but didn't think much about the fast moving MN case yet. > I do understand that CPL is 100% reliable, even in high-speed scenarios, > when the prefix sets in RAs from the same link are guaranteed to overlap. This is a very good point, really an acute observation. Thanks. Yes, there will no mistakenly assuming a link change because of common element (prefix) in (any two) RAs. > The draft is on its way to Proposed Standard, right? We didn't decide it yet. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon May 30 08:20:46 2005 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 IAA09803 for ; Mon, 30 May 2005 08:20:45 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOVVIYQDIK976WE7@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 30 May 2005 22:20:40 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3B18880003; Mon, 30 May 2005 22:20: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 98BF63C00A; Mon, 30 May 2005 22:20:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4UCJed21730 for dna-list; Mon, 30 May 2005 22:19:40 +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 j4UCJdr21724 for ; Mon, 30 May 2005 22:19:39 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOVVI3W1RW99JE9J@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 30 May 2005 22:19:22 +1000 Received: by localhost (Postfix, from userid 510) id 4A77D80003; Mon, 30 May 2005 22:19:22 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by larry.its.monash.edu.au (Postfix) with ESMTP id 71B533C00D; Mon, 30 May 2005 22:19:20 +1000 (EST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IHA00LYPY86VR@mailout3.samsung.com>; Mon, 30 May 2005 21:19:18 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IHA00CWXY803M@mmp1.samsung.com>; Mon, 30 May 2005 21:19:18 +0900 (KST) Date: Mon, 30 May 2005 17:47:03 +0530 From: Syam Madanapalli Subject: [DNA] Comments on DNA Solution: Link Identifier based approach Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: dna@eng.monash.edu.au, greg.daley@eng.monash.edu.au Message-id: <001101c56511$80f55ba0$59476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <421BC12A.70204@eng.monash.edu.au> <92e919fb05052717366bb2ce24@mail.gmail.com> Content-Transfer-Encoding: 7BIT Hi JinHyeock, Here few comments and questions on your draft. 1. The draft does not talk about the scenario where there exists a mix of modified and unmodified routers. 2. Section 3.1. ........ A router, when it boots or is configured to act as a router (Sec 6.2.2 in RFC 2461 [1]), first sends an RS and waits for RAs to gather prefixes. ........ Once that process is complete, the router will send RAs and respond to RSs, but not before that. These two statements are conflicting. Is the RS from routers is different from Hosts? According to one of your statements the routers do not respond to RSs unless the process of LinkID establishment is completed. So how Does initial RS/RA exchange happen between routers? Or am I missing some thing here. 3. Section 3.2 ........ In case the new prefix smaller than the current linkid prefix is advertised in LPIO, the router doesn't change the linkid prefix. Are you saying if a router receives a new smaller prefix in LPIO, then the router will not change the linkid? In other words routers change linkid if and only of they receive a new smaller prefix in PIO. If this is true, then I think there will be some inconsistency in linkids being advertised by different routers on the link for some time and slows down the linked establishment process. Also, is there any reason for not to count LPIOs? 4. What if the life time of all the prefixes that are available falls below 3 hours? May be a rare case, but I am wondering if it is worth mentioning about this scenario. 5. The host receives RA with different linkid prefix than the host is having, the host need to check for the complete prefix list against the host linkidprefix list. This is similar to CPL except that the host is not trying to learn about complete prefix list and now the host does this comparison only when it sees a different linkid. 6. I am wondering what could be the disadvantage if we keep the Linkid prefix even if we see the new prefix that is smaller. I think it is better to keep the same linkid as far as possible. If the current Linkid prefix life time does not allow us to keep it as linkid prefix, then we can switch to next available smaller prefix. In this approach the new router that comes up, does not apply the algorithm to select a new linked, if it sees a linked (PIO/LPIO with 'I' flag set). The new router simply takes the received linked as the linked for the link. I think this way we avoid lot of processing and we will have smaller linkidprefix list on the host side. 7. Section 3.4.3 ........ For example, assume a router R advertise the linkid prefix P1 and the second smallest prefix is P2. When the valid lifetime of P1 is 7 days, R wants to remove P1 from the link. If R immediately advertises an RA with 1) P1 with zero lifetime and 2) P2 with I-bit set, hosts may treat this as a link change, because they would discard P1 entirely when seeing it with zero lifetime. In this example, is the prefix P2 is also being advertised when P1 is the linkid prefix? If yes, then a host receives a P1 with zero life time, it can easily find out that it is still on the same link but the prefix P1 is not valid any more. I can see one problem: If Host receives another RA from another router with P1 as the linkid, then host think that it has moved, as the host discarded the P1 completely because of the earlier RA. 8. And also I am wondering, why we cannot use the longest valid prefix time as the selector for the linkid prefix. I think this is better because, this way linkid will be valid for more time. Thank you, Syam From dna-owner@webcamserver.eng.monash.edu.au Mon May 30 14:04:12 2005 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 OAA01414 for ; Mon, 30 May 2005 14:04:11 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOW7GU7LT494O8N4@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 31 May 2005 04:03:53 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7822CAB556; Tue, 31 May 2005 04:01:56 +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 238804FB05; Tue, 31 May 2005 04:01:56 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4UI1Mr25429 for dna-list; Tue, 31 May 2005 04:01:22 +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 j4UI1Mr25425 for ; Tue, 31 May 2005 04:01:22 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOW7FQU2SM976R61@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 31 May 2005 04:01:04 +1000 Received: by localhost (Postfix, from userid 510) id D9742AB543; Tue, 31 May 2005 04:01:03 +1000 (EST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id 990464FB03 for ; Tue, 31 May 2005 04:00:59 +1000 (EST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1DcoYR-0000Km-HP; Mon, 30 May 2005 20:00:05 +0200 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtpsa id 1DcoYQ-00019H-B4; Mon, 30 May 2005 19:59:58 +0200 Date: Mon, 30 May 2005 19:59:57 +0200 From: Christian Vogt Subject: Re: [DNA] Feedback on draft-ietf-dna-cpl-00.txt In-reply-to: <01f601c56507$bec1b730$ee2f024b@jinchoe> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Jinhyeock Choi , Erik Nordmark , DNA , TM-RO2 Message-id: <429B549D.6010602@tm.uka.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-15; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: de-DE, de, en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <42973B40.1010009@tm.uka.de> <01f601c56507$bec1b730$ee2f024b@jinchoe> Content-Transfer-Encoding: 7BIT Hi JinHyeock. > I think it is ok for a host to send 1 RS and waits for 4 secs to > collect (solicited) RAs and declare its prefix list (CCL) complete. I agree. Besides, has there been a discussion in DNA or elsewhere as to what a reasonable upper bound on the handover frequency could be? If there was, it might be good to put a link into your document. [...] >> I do understand that CPL is 100% reliable, even in high-speed >> scenarios, when the prefix sets in RAs from the same link are >> guaranteed to overlap. > > This is a very good point, really an acute observation. Thanks. Yes, > there will no mistakenly assuming a link change because of common > element (prefix) in (any two) RAs. Right, and it would be easy for network administrators to set IP links up this way. The only issue I see at this moment is IP links which have so many prefixes that all of them do not fit within a single RA. In this situation, the prefix sub-set advertised in one RA might not overlap with the prefix sub-set advertised in another RA, even though the complete prefix lists of any two routers on the same IP link do overlap. Of course, a RA daemon can be configured (or patched) such that any two successive RAs have overlapping prefix sub-sets. A RA damon can also be configured/patched such that the prefix sub-sets of all of its RAs overlap (for instance, by choosing one common prefix). However, while this approach helps, it still cannot prevent the MN from seeing two successive RAs (from the same IP link) with disjunct prefix sub-sets: One reason is RA loss, another is multiple routers on the same IP link. To coordinate multiple routers on the same IP link, one would end up having to choose one common prefix which all of the routers put in all of their RAs. And that would effectively be the Link ID proposal. ;) - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ JinHyeock Choi wrote: > Dear Christian > > Thanks for your kind and insightful feedback. > > >> I took a look at the Complete Prefix List proposal. >> >> First of all, I like the idea of not having to change any entities >> in the network but only the MN's stack. This is a significant >> advantage in terms of applicability until more radical DNA >> techniques establish themselves. > > > ok. glad to hear that. > > >> On thing concerning reliance on unsolicited RAs. Section 3.1 says: >> >> >> ++++ The host forms the prefix list at any attachment point, that >> is, this process starts independently of any movement. Though the >> procedure may take some time, that doesn't matter unless the host >> moves very fast. A host can generate the complete prefix list with >> reasonable certainty if it remains attached to a link sufficiently >> long. It will take approximately 12 seconds, when it actively >> perform 3 RS/ RA exchanges. If it passively relies on unsolicited >> RA messages instead, it may take much more time. ++++ >> >> I see that one cannot really do much analysis for routers that send >> unsolicited RAs every 30ms to 70ms as proposed by RFC 3775 >> (because such RA might not have all of the prefixes included). But >> since this high frequency would obviously improve the situation for >> CPL, it might be worthwhile to put a note into the draft. > > > ok. > > I think it is ok for a host to send 1 RS and waits for 4 secs to > collect (solicited) RAs and declare its prefix list (CCL) complete. > > Without a packet loss, the host will generate the complete prefix > list. > > Even some packet loss may cause an incomplete prefix list, there is a > further chance for the host to get the missing prefixes before it > receives link UP notification, i.e. moves to another AP. > > Even the host moves to another AP with incomplete prefix list, the > first RA may contain the prefix in its prefix list. > > Considering all those above, even if the host performs only one RS/ > RA exchange, it will be very rare for the host to falsely assume a > link change. Even in case of such a false assumption, there will not > be a communication disruption but only unnecessary signaling. > > So I think such an occasional unnecessary signaling is acceptable and > 1 RS/ RA exchange is enough for the complete prefix list generation. > > How do you think of it? > > >> I presume you are planning to do, or have already done, some >> experimental tests to find out how well CPL works when MNs move >> really fast. Well, maybe this can be done on a theoretic basis >> like the Performance Analysis in section 9. > > > We have an implementation plan but didn't think much about the fast > moving MN case yet. > > >> I do understand that CPL is 100% reliable, even in high-speed >> scenarios, when the prefix sets in RAs from the same link are >> guaranteed to overlap. > > > This is a very good point, really an acute observation. Thanks. Yes, > there will no mistakenly assuming a link change because of common > element (prefix) in (any two) RAs. > > >> The draft is on its way to Proposed Standard, right? > > > We didn't decide it yet. > > Thanks for your kind consideration. > > Best Regards > > JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon May 30 20:25:00 2005 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 UAA26671 for ; Mon, 30 May 2005 20:24:58 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOWKU8F2OA94ODC0@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 31 May 2005 10:24:50 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E1BABAB545; Tue, 31 May 2005 10:24:34 +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 9089E4FB0C; Tue, 31 May 2005 10:24:34 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4V0LC929565 for dna-list; Tue, 31 May 2005 10:21: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 j4V0LBr29561 for ; Tue, 31 May 2005 10:21:11 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOWKPY59SQ976QWK@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 31 May 2005 10:21:08 +1000 Received: by localhost (Postfix, from userid 510) id B1787AB545; Tue, 31 May 2005 10:21:07 +1000 (EST) Received: from sm.sait.samsung.co.kr (unknown [202.20.142.15]) by moe.its.monash.edu.au (Postfix) with ESMTP id 6F7D44FB09; Tue, 31 May 2005 10:21:05 +1000 (EST) Received: from sm.sait.samsung.co.kr (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id BF354E5AAB; Tue, 31 May 2005 09:17:58 +0900 (KST) Received: from 127.0.0.1 by 127.0.0.1(smtpfilter) with ESMTP; Tue, 31 May 2005 09:17:58 +0900 (KST) Received: from jinchoe (unknown [75.2.43.232]) by sm.sait.samsung.co.kr (Postfix) with SMTP id:00A85E5AA2; Tue, 31 May 2005 09:17:57 +0900 (KST) Date: Tue, 31 May 2005 09:21:02 +0900 From: JinHyeock Choi Subject: Re: [DNA] Comments on DNA Solution: Link Identifier based approach Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli , JinHyeock Choi Cc: dna@eng.monash.edu.au, greg.daley@eng.monash.edu.au Message-id: <00a001c56576$a0749b70$e82b024b@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 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <421BC12A.70204@eng.monash.edu.au> <92e919fb05052717366bb2ce24@mail.gmail.com> <001101c56511$80f55ba0$59476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Dear Syam Thanks for your kind and detailed feedback. Kindly find my in-line comments. > 1. The draft does not talk about the scenario where there exists a mix of > modified and unmodified routers. This is a very good point. Though that case is not explicitly mentioned, I had that in mind while design the protocol. That's why hosts make no decision when receiving an RA having no linkid prefix. It will work even in such an environment. > 2. Section 3.1. > > ........ > A router, when it boots or is configured to act as a router (Sec > 6.2.2 in RFC 2461 [1]), first sends an RS and waits for RAs to > gather prefixes. > > ........ > > Once that process is complete, the router will send RAs and > respond to RSs, but not before that. > > These two statements are conflicting. Is the RS from routers is > different from Hosts? > > According to one of your statements the routers do not respond to > RSs unless the process of LinkID establishment is completed. So how > Does initial RS/RA exchange happen between routers? Or am I missing > some thing here. My writing may not be clear. When a router is booted, after sending 3 RSs, i.e. waiting 12 secs, the router starts advertising its RAs, even if no RA arrives. > 3. Section 3.2 > ........ > In case the new prefix smaller than the current linkid prefix is > advertised in LPIO, the router doesn't change the linkid prefix. > > Are you saying if a router receives a new smaller prefix in LPIO, then > the router will not change the linkid? In other words routers change > linkid > if and only of they receive a new smaller prefix in PIO. Yes. > If this is true, then I think there will be some inconsistency in linkids > being advertised by different routers on the link for some time Yes. > and slows > down the linked establishment process. Even it slows down the linkid convergence, it will not affect DNA performance. > Also, is there any reason for not to count LPIOs? We thought it's more reliable to rely only on PIO information. > 4. What if the life time of all the prefixes that are available falls > below 3 hours? May be a rare case, but I am wondering if it is worth > mentioning about this scenario. Then this will not work and hosts need to fall back on CPL. But I guess we can safely sweep this under the carpet. :-) > 5. The host receives RA with different linkid prefix than the host > is having, the host need to check for the complete prefix list against > the host linkidprefix list. This is similar to CPL except that the host > is > not trying to learn about complete prefix list and now the host does this > comparison only when it sees a different linkid. Yes. Christian's comment on CPL showed me how similar linkid scheme is to CPL. There is one more difference as below. In CPL, a host compares the set of prefixes in the receiving RA with its Completer Prefix List. In linkid, a host compares the set of prefixes in the receiving RA with its LinkidPrefixList. > 6. I am wondering what could be the disadvantage if we keep the > Linkid prefix even if we see the new prefix that is smaller. > I think it is better to keep the same linkid as far as possible. > If the current Linkid prefix life time does not allow us to keep > it as linkid prefix, then we can switch to next available smaller > prefix. > In this approach the new router that comes up, does not apply the > algorithm to select a new linked, if it sees a linked (PIO/LPIO with > 'I' flag set). The new router simply takes the received linked as > the linked for the link. > > I think this way we avoid lot of processing and we will have smaller > linkidprefix list on the host side. In DT, we had a discussion w.r.t. the linkid convergence. We decided that it would be much reliable if routers select their linkid prefix by themselves without consulting what other routers advertise as a linkid prefix. We were afraid of ping-pong effect. Router 1 advertise a linkid prefix 1 and Router 2 a linkid prefix 2, then they keep changing their prefixes. The above is a kind of "Phantom Menace" (:-)) without showing the definite problem. But a menace anyway and we try to avoid not only tangible problems but also even the possibility of a problem. So in the proposed scheme, routers would not take into consideration the linkid prefix in the RA it receives from the other routers. > 7. Section 3.4.3 > > ........ > > For example, assume a router R advertise the linkid prefix P1 and > the > second smallest prefix is P2. > > When the valid lifetime of P1 is 7 days, R wants to remove P1 from > the link. > If R immediately advertises an RA with 1) P1 with zero lifetime and > 2) P2 with I-bit set, hosts may treat this as a link change, because > they would discard P1 entirely when seeing it with zero lifetime. > > In this example, is the prefix P2 is also being advertised when P1 > is the linkid prefix? If yes, then a host receives a P1 with zero life > time, > it can easily find out that it is still on the same link but the prefix > P1 > is not valid any more. In the linkid scheme, to check for link change hosts use only the prefixes in LinkidPrefixList. > I can see one problem: If Host receives another RA from another router > with P1 as the linkid, then host think that it has moved, as the host > discarded the P1 completely because of the earlier RA. Right. > 8. And also I am wondering, why we cannot use the longest valid prefix time > as > the selector for the linkid prefix. I think this is better because, this > way > linkid will be valid for more time. In fact, we can use any algorithm which will give a definite prefix from the set of prefixes on the link. The problem with 'the longest valid prefix time' is that there may be multiple prefixes having the same valid prefix time. Then we need an additional decision scheme. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon May 30 21:01:16 2005 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 VAA29988 for ; Mon, 30 May 2005 21:01:14 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOWM45MWZ89AO0NN@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 31 May 2005 11:00:52 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 61EDAAB54F; Tue, 31 May 2005 11:00:49 +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 112AE4FB03; Tue, 31 May 2005 11:00:49 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4V10Ym29995 for dna-list; Tue, 31 May 2005 11:00:34 +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 j4V10Yr29991 for ; Tue, 31 May 2005 11:00:34 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOWM3IFESC9AO0NN@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 31 May 2005 11:00:18 +1000 Received: by localhost (Postfix, from userid 510) id 5F93EAB54B; Tue, 31 May 2005 11:00:18 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by moe.its.monash.edu.au (Postfix) with ESMTP id D3B4A4FB05 for ; Tue, 31 May 2005 11:00:15 +1000 (EST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IHB00D9MXGDXT@mailout2.samsung.com> for dna@eng.monash.edu.au; Tue, 31 May 2005 10:00:13 +0900 (KST) Received: from jinchoe ([75.2.43.232]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IHB00GH5XGDFX@mmp2.samsung.com> for dna@eng.monash.edu.au; Tue, 31 May 2005 10:00:13 +0900 (KST) Date: Tue, 31 May 2005 10:00:12 +0900 From: JinHyeock Choi Subject: Re: [DNA] Feedback on draft-ietf-dna-cpl-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: Christian Vogt Cc: Jinhyeock Choi , Erik Nordmark , DNA , TM-RO2 Message-id: <00d601c5657c$19c750d0$e82b024b@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-15 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <42973B40.1010009@tm.uka.de> <01f601c56507$bec1b730$ee2f024b@jinchoe> <429B549D.6010602@tm.uka.de> Content-Transfer-Encoding: 7BIT Dear Christian > Besides, has there been a discussion in DNA or elsewhere as to what a > reasonable upper bound on the handover frequency could be? If there > was, it might be good to put a link into your document. No, AFAIK. > >> I do understand that CPL is 100% reliable, even in high-speed > >> scenarios, when the prefix sets in RAs from the same link are > >> guaranteed to overlap. > > > > This is a very good point, really an acute observation. Thanks. Yes, > > there will no mistakenly assuming a link change because of common > > element (prefix) in (any two) RAs. > > Right, and it would be easy for network administrators to set IP links > up this way. I guess, yes, in the most cases. > The only issue I see at this moment is IP links which have so many > prefixes that all of them do not fit within a single RA. In this > situation, the prefix sub-set advertised in one RA might not overlap > with the prefix sub-set advertised in another RA, even though the > complete prefix lists of any two routers on the same IP link do overlap. I see. > Of course, a RA daemon can be configured (or patched) such that any two > successive RAs have overlapping prefix sub-sets. A RA damon can also be > configured/patched such that the prefix sub-sets of all of its RAs > overlap (for instance, by choosing one common prefix). ok. > However, while this approach helps, it still cannot prevent the MN from > seeing two successive RAs (from the same IP link) with disjunct prefix > sub-sets: One reason is RA loss, another is multiple routers on the > same IP link. ok. > To coordinate multiple routers on the same IP link, one would end up > having to choose one common prefix which all of the routers put in all > of their RAs. I agree. For 100% certain CPL, in theory, it is enough that "Any two RAs in a link have A common prefix." But in practice, it would be better that "All RAs in a link have THE common prefix." Let me underline the above with an example. Assume three RAs, RA[1], RA[2] and RA[3]. The first one means that any two RA[i] and RA[j] have a common prefix. But there may not be a common prefix among all threee RAs. The second one even implies that. > And that would effectively be the Link ID proposal. ;) Now I see much similarity between the above and LinkID draft. Thanks for a new insight. I'll think over their relationship. Also your feedback on LinkID draft will be of much help. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue May 31 00:30:00 2005 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 AAA12713 for ; Tue, 31 May 2005 00:29:59 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOWTDJJJ4E99JCN9@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 31 May 2005 14:29:19 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CF5D5AB54C; Tue, 31 May 2005 14:29:12 +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 8A56D4FB09; Tue, 31 May 2005 14:29:12 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4V4SXa32158 for dna-list; Tue, 31 May 2005 14:28:33 +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 j4V4SWr32154 for ; Tue, 31 May 2005 14:28:32 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOWTCCUNU494NR6L@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 31 May 2005 14:28:15 +1000 Received: by localhost (Postfix, from userid 510) id 9D6AA80009; Tue, 31 May 2005 14:28:15 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by larry.its.monash.edu.au (Postfix) with ESMTP id 2AB543C010; Tue, 31 May 2005 14:28:14 +1000 (EST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IHC0042L730KX@mailout2.samsung.com>; Tue, 31 May 2005 13:28:12 +0900 (KST) Received: from subbareddy ([107.108.71.57]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IHC0046F72WI5@mmp1.samsung.com>; Tue, 31 May 2005 13:28:12 +0900 (KST) Date: Tue, 31 May 2005 09:55:59 +0530 From: Subba Reddy Subject: Re: [DNA] Comments on DNA Solution: Link Identifier based approach Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , Syam Madanapalli , JinHyeock Choi Cc: dna@eng.monash.edu.au, greg.daley@eng.monash.edu.au Message-id: <001f01c56598$dab708f0$39476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <421BC12A.70204@eng.monash.edu.au> <92e919fb05052717366bb2ce24@mail.gmail.com> <001101c56511$80f55ba0$59476c6b@sisodomain.com> <00a001c56576$a0749b70$e82b024b@jinchoe> Content-Transfer-Encoding: 7BIT Hi JinHyeock Choi, Please find my comments in-line. > Dear Syam > > Thanks for your kind and detailed feedback. Kindly find my in-line > comments. > > > 1. The draft does not talk about the scenario where there exists a mix of > > modified and unmodified routers. > > This is a very good point. > > Though that case is not explicitly mentioned, I had that in mind > while design the protocol. That's why hosts make no decision > when receiving an RA having no linkid prefix. It will work even > in such an environment. I think it is useful to look into the RA sent by the unmodified router, to see if it is advertising the linkid prefix (obviously no I bit is available) so that host can make a decision that it is still on the same link. > > > 2. Section 3.1. > > > > ........ > > A router, when it boots or is configured to act as a router (Sec > > 6.2.2 in RFC 2461 [1]), first sends an RS and waits for RAs to > > gather prefixes. > > > > ........ > > > > Once that process is complete, the router will send RAs and > > respond to RSs, but not before that. > > > > These two statements are conflicting. Is the RS from routers is > > different from Hosts? > > > > According to one of your statements the routers do not respond to > > RSs unless the process of LinkID establishment is completed. So how > > Does initial RS/RA exchange happen between routers? Or am I missing > > some thing here. > > My writing may not be clear. When a router is booted, after sending > 3 RSs, i.e. waiting 12 secs, the router starts advertising its RAs, even if > no RA arrives. > Take a case where more than one router boots up, if the routers are not replying for RSs (not sending RAs) during initial 12 seconds, then they will configure different linkids and it may take some more time to converge. If the link is coming up, routers chosing the linkid based on the prefixes it is advertising is same as waiting for 12 seconds other than the delay in the later case (because routers will not come to know each others prefixes) > > 3. Section 3.2 > > ........ > > In case the new prefix smaller than the current linkid prefix is > > advertised in LPIO, the router doesn't change the linkid prefix. > > > > Are you saying if a router receives a new smaller prefix in LPIO, then > > the router will not change the linkid? In other words routers change > > linkid > > if and only of they receive a new smaller prefix in PIO. > > Yes. > > > If this is true, then I think there will be some inconsistency in linkids > > being advertised by different routers on the link for some time > > Yes. > > > and slows > > down the linked establishment process. > > Even it slows down the linkid convergence, it will not affect > DNA performance. > > > Also, is there any reason for not to count LPIOs? > > We thought it's more reliable to rely only on PIO information. > > > 8. And also I am wondering, why we cannot use the longest valid prefix time > > as > > the selector for the linkid prefix. I think this is better because, this > > way > > linkid will be valid for more time. > > In fact, we can use any algorithm which will give a definite prefix from > the set of prefixes on the link. > > The problem with 'the longest valid prefix time' is that there may be > multiple prefixes having the same valid prefix time. Then we need > an additional decision scheme. Even though one more decision is required, if we select linkid based on life time, then linkids may not change frequently because of life time expiry. Thanks & Regards, Subba Reddy From dna-owner@webcamserver.eng.monash.edu.au Tue May 31 07:04:52 2005 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 HAA29475 for ; Tue, 31 May 2005 07:04:51 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOX76SZ5SO99JQCL@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 31 May 2005 21:04:45 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C3A17AB54C; Tue, 31 May 2005 21:04:38 +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 72D334FB06; Tue, 31 May 2005 21:04:38 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4VB42U03860 for dna-list; Tue, 31 May 2005 21:04:02 +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 j4VB41r03856 for ; Tue, 31 May 2005 21:04:01 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOX75Q8KS299JLTF@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 31 May 2005 21:03:47 +1000 Received: by localhost (Postfix, from userid 510) id D8571AB545; Tue, 31 May 2005 21:03:46 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by moe.its.monash.edu.au (Postfix) with ESMTP id 34A6D4FB08; Tue, 31 May 2005 21:03:45 +1000 (EST) 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 <0IHC00H7EPE72Y@mailout1.samsung.com>; Tue, 31 May 2005 20:03:43 +0900 (KST) Received: from jinchoe ([75.2.47.235]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IHC00JG9PE7PL@mmp1.samsung.com>; Tue, 31 May 2005 20:03:43 +0900 (KST) Date: Tue, 31 May 2005 20:03:39 +0900 From: JinHyeock Choi Subject: Re: [DNA] Comments on DNA Solution: Link Identifier based approach Sender: owner-dna@ecselists.eng.monash.edu.au To: Subba Reddy , Syam Madanapalli , JinHyeock Choi Cc: dna@eng.monash.edu.au, Greg Daley Message-id: <005d01c565d0$688692e0$eb2f024b@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 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <421BC12A.70204@eng.monash.edu.au> <92e919fb05052717366bb2ce24@mail.gmail.com> <001101c56511$80f55ba0$59476c6b@sisodomain.com> <00a001c56576$a0749b70$e82b024b@jinchoe> <001f01c56598$dab708f0$39476c6b@sisodomain.com> Content-Transfer-Encoding: 7BIT Dear Subba Reddy Thanks for your kind feedback. > > Though that case is not explicitly mentioned, I had that in mind > > while design the protocol. That's why hosts make no decision > > when receiving an RA having no linkid prefix. It will work even > > in such an environment. > > > I think it is useful to look into the RA sent by the unmodified router, > to see if it is advertising the linkid prefix (obviously no I bit is > available) > so that host can make a decision that it is still on the same link. This will work for the most of cases but may cause problem w.r.t. flash renumbering and early reassignment, which is described in Sub-sec 7.3 Issue 003: > Take a case where more than one router boots up, if the routers are not > replying > for RSs (not sending RAs) during initial 12 seconds, then they will > configure different > linkids and it may take some more time to converge. > > If the link is coming up, routers chosing the linkid based on the prefixes > it is advertising > is same as waiting for 12 seconds other than the delay in the later case > (because routers > will not come to know each others prefixes) Eventually the linkid will converge and I expect there will be no flapping. I put this as an open issue 006. > > The problem with 'the longest valid prefix time' is that there may be > > multiple prefixes having the same valid prefix time. Then we need > > an additional decision scheme. > > Even though one more decision is required, if we select linkid > based on life time, then linkids may not change frequently > because of life time expiry. Usually I guess that the most prefixes are configured the default valid lifetime, 30 days. Prefixes are not changed so often. So I expect it will work fine even if we don't choose the longest lifetime prefix. Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue May 31 12:27:11 2005 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 MAA23161 for ; Tue, 31 May 2005 12:27:10 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOXIG3NJIA94O6CQ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 02:26:53 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id ED46EAB543; Wed, 01 Jun 2005 02:26: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 ACD1F4FB04; Wed, 01 Jun 2005 02:26:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4VGQ9r07297 for dna-list; Wed, 01 Jun 2005 02:26:09 +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 j4VGQ9r07293 for ; Wed, 01 Jun 2005 02:26:09 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOXIF7G7II94O6CQ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 02:25:59 +1000 Received: by localhost (Postfix, from userid 510) id C2C7DAB542; Wed, 01 Jun 2005 02:25:59 +1000 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by curly.its.monash.edu.au (Postfix) with ESMTP id DE33C4FB06 for ; Wed, 01 Jun 2005 02:25:57 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.226.31]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j4VGPtjO021725; Tue, 31 May 2005 10:25:56 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j4VGPmMK529619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 31 May 2005 09:25:55 -0700 (PDT) Date: Tue, 31 May 2005 07:49:24 -0700 From: Erik Nordmark Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: dna@eng.monash.edu.au Message-id: <429C7974.1060703@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 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <03b901c560ac$a20ed690$291d9069@sisa.samsung.com> <4293D0F9.8070401@sun.com> Content-Transfer-Encoding: 7BIT Bernard Aboba wrote: > How about this? > > Link Down > An event provided by the link layer that signifies a state change > associated with the interface no longer being capable of > communicating IP packets. A Link Down event > is only generated once the link layer considers the link > unusable; transient periods of high frame loss are not > sufficient. > > Link Up > An event provided by the link layer that signifies a state change > associated with the interface becoming capable of communicating > IP packets. Works for me. Thanks, Erik From dna-owner@webcamserver.eng.monash.edu.au Tue May 31 13:17:12 2005 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 NAA26435 for ; Tue, 31 May 2005 13:17:11 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOXK7BELOC99JRT7@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 03:16:56 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F060DAB54A; Wed, 01 Jun 2005 03:16:53 +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 A8D7B4FB05; Wed, 01 Jun 2005 03:16:53 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4VHGfD07902 for dna-list; Wed, 01 Jun 2005 03:16:41 +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 j4VHGer07898 for ; Wed, 01 Jun 2005 03:16:40 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOXK6U7OF294OGD5@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 03:16:31 +1000 Received: by localhost (Postfix, from userid 510) id EB87EAB543; Wed, 01 Jun 2005 03:16:30 +1000 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by moe.its.monash.edu.au (Postfix) with ESMTP id 4D06C4FB09 for ; Wed, 01 Jun 2005 03:16:28 +1000 (EST) Received: from jurassic.eng.sun.com ([129.146.106.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j4VHGRGJ008700; Tue, 31 May 2005 10:16:27 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j4VHGQkG544428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 31 May 2005 10:16:27 -0700 (PDT) Date: Tue, 31 May 2005 10:16:45 -0700 From: Erik Nordmark Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: <936A4045C332714F975800409DE092405416E1@tayexc14.americas.cpqcorp.net> Sender: owner-dna@ecselists.eng.monash.edu.au To: "Bound, Jim" Cc: dna@eng.monash.edu.au Message-id: <429C9BFD.2000303@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 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <936A4045C332714F975800409DE092405416E1@tayexc14.americas.cpqcorp.net> Content-Transfer-Encoding: 7BIT Bound, Jim wrote: > I agree in theory. In practice I may implement to bring the link-down, if > it is not my only link-access, as far as IP stack is concerned. Reason is > node/device may have multiple link-access mediums and this one is not > performing. I think we all understand where I am going. My reason for > stating the obvious is does this context affect what we do within DNA? I think what we are doing is coming up with definitions of the concepts of link up/down that are useful for DNA, and does not prevent things like "link quality" to be taken into account, especially for hosts with multiple interfaces. It is probably the case that a host with multiple interfaces will work best if it takes into account a number of factors (from packet loss rates and bandwidth, to monetary cost for using a NIC and application requirements) when choosing which NIC to use (and for what application traffic). I also suspect that such strategies doesn't require that DNA stop considering an interface. For instance, if the stack+applications decide to use the GPRS interface for VoIP traffic, it is probably still useful to have DNA monitor the 802.11 interface to detect when the host gets back in range of the AP. But that clearly shouldn't prevent implementations that just use simpler strategies such as "haven't heard from the AP in 30 seconds" to just abandon the use of the 802.11 interface. I don't see the definitions that Bernard updates as restricting the implementation in any way; could be as simple or as complicated as it wants when handling multiple NICs. If you think they are restricting the implementations then we should clarify the definitions further. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue May 31 14:23:53 2005 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 OAA04297 for ; Tue, 31 May 2005 14:23:52 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOXMJ70M2G9ANN1F@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Jun 2005 04:23:47 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 73AFE80003; Wed, 01 Jun 2005 04:23:44 +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 323653C003; Wed, 01 Jun 2005 04:23:44 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id j4VINKo08840 for dna-list; Wed, 01 Jun 2005 04:23: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 j4VINJr08836 for ; Wed, 01 Jun 2005 04:23:19 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOXMIBK0UM94OIVY@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Jun 2005 04:23:02 +1000 Received: by localhost (Postfix, from userid 510) id 5B92680002; Wed, 01 Jun 2005 04:23:02 +1000 (EST) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) (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 994773C003 for ; Wed, 01 Jun 2005 04:23:00 +1000 (EST) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DdBOD-000A8M-No; Tue, 31 May 2005 14:22:58 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4VIMti04358; Tue, 31 May 2005 11:22:56 -0700 Date: Tue, 31 May 2005 11:22:55 -0700 (PDT) From: Bernard Aboba Subject: Re: [DNA] Definition of "Link Up" and "Link Down" events? In-reply-to: <429C9BFD.2000303@sun.com> X-Originating-IP: 67.182.139.247 Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: "Bound, Jim" , dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mail-Handler: MailHop Outbound by DynDNS.org X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) References: <936A4045C332714F975800409DE092405416E1@tayexc14.americas.cpqcorp.net> <429C9BFD.2000303@sun.com> Content-Transfer-Encoding: 7BIT > > I agree in theory. In practice I may implement to bring the link-down, if > > it is not my only link-access, as far as IP stack is concerned. Reason is > > node/device may have multiple link-access mediums and this one is not > > performing. I think we all understand where I am going. My reason for > > stating the obvious is does this context affect what we do within DNA? > > I think what we are doing is coming up with definitions of the concepts > of link up/down that are useful for DNA, and does not prevent things > like "link quality" to be taken into account, especially for hosts with > multiple interfaces. "Link-aware" routing metrics date back to the original ARPAnet packet radio experiments, and more recent work has established the importance of taking link quality into account. For example, see: http://research.microsoft.com/mesh/papers/metrics.pdf http://pdos.csail.mit.edu/~rtm/papers/etx.pdf http://pdos.csail.mit.edu/papers/grid:losstr02/paper.pdf http://www.ee.ucla.edu/~kulkarni/papers/Routing.pdf > It is probably the case that a host with multiple interfaces will work > best if it takes into account a number of factors (from packet loss > rates and bandwidth, to monetary cost for using a NIC and application > requirements) when choosing which NIC to use (and for what application > traffic). All this can be taken into account by adjusting routing metrics. In particular, routing metrics can automatically make a decision about whether to route packets over another interface once the link quality begins to deteriorate. > I also suspect that such strategies doesn't require that DNA > stop considering an interface. For instance, if the stack+applications > decide to use the GPRS interface for VoIP traffic, it is probably still > useful to have DNA monitor the 802.11 interface to detect when the host > gets back in range of the AP. Routing metrics only become relevant when an interface is "up" and configured for communicating IP packets. DNA helps speed up that process, but it isn't involved in making the decision whether to enable an interface or not. Similarly, bringing an interface down is a separate decision from deciding whether to use it to route a particular packet. However, I do think that decisions on enabling/disabling interfaces do need to take routing metrics into account, or else inconsistencies can result. For example, if you bring an interface up that has a higher routing metric than another interface, it won't be used except perhaps if it can reach prefixes that the other interface can't. If "idle timeout" is in effect, then the unused interface will only be brought down again. Similarly, if "dial on demand" is in effect, then if you bring an interface down that had a lower routing metric than an existing interface, then it will only be brought up again. So my take is that routing metrics are actually fairly fundamental to multi-homing behavior. For example, MIT LCS has an interesting paper on rate negotiation algorithms: http://pdos.csail.mit.edu/~rtm/srcrr-draft.pdf > But that clearly shouldn't prevent implementations that just use simpler > strategies such as "haven't heard from the AP in 30 seconds" to just > abandon the use of the 802.11 interface. That would be a particularly poor algorithm to use since the detection time is larger than RTOmin. In general, a NIC should probably start scanning after only 3 retransmissions (unlikely to occur merely due to congestion) and should consider moving to another AP before RTOmin. For example, even poor rate negotiation implementations typically can move from the highest bit rate to the lowest (typically 1 Mbps) in 200 ms. > I don't see the definitions that Bernard updates as restricting the > implementation in any way; could be as simple or as complicated as it > wants when handling multiple NICs. I don't see them restricting an intelligent implementation either. But I've seen enough bad ones that I'd prefer to rule out the most egregious behavior.