From abdussalambaryun@gmail.com Wed Aug 1 00:21:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5F011E8072; Wed, 1 Aug 2012 00:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKM96DWfRgbz; Wed, 1 Aug 2012 00:21:56 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 02B4411E8087; Wed, 1 Aug 2012 00:21:54 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7236844vbb.31 for ; Wed, 01 Aug 2012 00:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=HpPLODMgoDXgRgEN6hcGVB4JWJtGER83hthe0yQWeRs=; b=CUTpojDmFFP7HdALyLBb0jl5hXOMTzv06Ic0XmfU8hgwJQhlvQdlUAPfhpaLpDxvav MGbJ8ueMADojkPQ6l8V5PasJBbwKqFYLtqas6ZVWUCrB+Psl0Deaf4mCDRqhD3vutTxc 7iOXSd83Ziucv0+w1WhNAasqWww4x0pXVisl8prJ3Cy7BWtnnR2vuXK6/uH4pgrI18aQ eGyynxV2EZ4FCYq6JmsGecQ59vcGuiDtGqi4kkYL93q2fv2qEiDL3MioO9NH6FcFzbvh rMfz+Yq0w29BHmKd9zikWzmBJ0Lf5/7K5kR4u5ySgvUkUsUDpn5aEa2aGm7kcz5qBfgU 0mQg== MIME-Version: 1.0 Received: by 10.52.98.3 with SMTP id ee3mr9079393vdb.127.1343805714459; Wed, 01 Aug 2012 00:21:54 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Wed, 1 Aug 2012 00:21:54 -0700 (PDT) Date: Wed, 1 Aug 2012 09:21:54 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: roll , manet Subject: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 07:21:57 -0000 Hi Henning, I am about to say many LLNs are NOT MANETs but it seems like the market or community will decide the outcome, but surly that some LLNs are NOT MANETs. > Could you state an example what would be considered a LLN but not a > MANET. I normally consider LLNs a subset of what we call MANETs. I not totally agree with that, because we need to be considering both NETs use case and applicability in the vision of the different WGs (MANET and ROLL). There are many examples we can find them in the [RFC2501] for MANETs characteristics and applicability, and for LLNs characteristics in [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs requirements. That is why I suggested before that OLSRv2 and AODVv2 should mention their applicability to LLN if they do. They just refer to RFC2501, but RFC2501 is OLD and does not mention LLN but describes the meaning. The authors of RFC2501 still not responded to my update suggestions. I understood from one discussion in MANET WG that few don't have time to read many pages of documents, so that is why I suggested to have terminology I-D [1] as we have ROLL terminology [ROLL] . I also taken initiative to make new draft of MANET subnet technologies which include only related LLNs [AB2]. Therefore, I will add the definition for MANET and LLN into my manet-terminology draft [AB1] (propose that authors of [ROLL] define LLN more details) to assist discussions as it is proved now in the list that there still is problems in definitions in MANET WG or in some I-D editorial content. [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt Best Wishes Abdussalam Baryun University of Glamorgan, UK ==================================================== On 7/31/12, Henning Rogge wrote: > On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun > subject: Re: [manet] Discussing LOADng suggestions > wrote: >> IMHO this protocol was intended as for ROLL WG not for MANET WG, but >> then changed its direction to MANET [3]. However, please note that >> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >> said, LOADng SHOULD specfy where is its limits. Then we can discuss >> adoption. > > Could you state an example what would be considered a LLN but not a > MANET. I normally consider LLNs a subset of what we call MANETs. > > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > From abdussalambaryun@gmail.com Wed Aug 1 00:27:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBFE11E809C for ; Wed, 1 Aug 2012 00:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVyDsS-gSRAY for ; Wed, 1 Aug 2012 00:27:43 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1882911E8087 for ; Wed, 1 Aug 2012 00:27:43 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7241753vbb.31 for ; Wed, 01 Aug 2012 00:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PtSzqEafDbh95IQkgVKwqZxS+lAYTl+LCY4FQhFdekw=; b=tPH9cnDE2PKgfai170xpnG3DSBl0h8oTKZihr6p0+H9NJt+Iqn04xBp+gWaPtG4Ega EnH/qugi9J3EO4CuomkM+Onz/bqeu6wpZ52tcgijvZyoysRNW+Bz+be0Kol5EbVrQdIT F/mTiuklLh0oZAcwtpQyT98R1PB6GdCiXeu6UVWHB/oDY0eNlIskK/uuRxFqbC/8sYVv T7oF3q6dLJ0U6trglANCVEGM9LGmRpyoS+BftUYY5CmBwetV+EFSSY1OalOWhOZct2Kz p7kUf1EOSBDA6yw6WA4UDoBY4X4ZQtVhQGTDpFtpc4DYSCMexCzfwWiebisZuMT5/lL8 9NZw== MIME-Version: 1.0 Received: by 10.52.97.227 with SMTP id ed3mr14187238vdb.103.1343806062157; Wed, 01 Aug 2012 00:27:42 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Wed, 1 Aug 2012 00:27:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 09:27:42 +0200 Message-ID: From: Abdussalam Baryun To: "jpmacker@gmail.com" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Propose update RFC2501 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 07:27:44 -0000 Hi Joe, This is a reminder to a post I send before you as one author of RFC2501, and the below. I need your respond to my suggestion. I thought you will discuss it in the meeting but you did not mention it, please comment/advise, AB ==== On 7/4/12, Abdussalam Baryun wrote: > Hi All, > > I want to propose draft-ietf work to be done on update the RFC2501, > which I don't mind doing, on the following issues: > > 1- to include all active MANET routing RFCs as describing its network > characteristics and its network context applicability, as mentioned by > section-6. > 2- to include the RFC5444 characteristics, or benefits to MANET > performance. > 3- to include NHDP RFC6130. > 4- IPv6 considerations > 5- Add more information in characteristic section on issue of > reliability and scalability. > > RFC2501> 3. Characteristics of MANETs > MANETs have several salient characteristics: > AB>Add> 5) issue of variable E2E delay and node disconnecting from > MANET. > AB> suggest> to consider LLN > > 2501> 5. IP-Layer Mobile Routing > AB> interfaces as physical layer technology, what about interfaces as > logical? in some other parts we read wireless interface > > 2501> 5>Future interoperability may be achieved using mechanisms other than > mobile IP. > AB> Are we there, could we answer to add some? > > 2501>5>Supporting these features appears only to require identifying > host and router interfaces with IP addresses, identifying a router > with a separate Router ID, and permitting routers to have multiple > wired and wireless interfaces. > AB> replace "host and router" with " router" as it was done in DYMO and > OLSRv2 > > 2501> 4) Proactive operation: The flip-side of demand-based operation. > AB> not clear > > 2501> Section 6.7, Duplex link and bidirectional link > AB> why we use *duplex* with *link*, duplex is related to the > interface system more than the link, so I recommend only using > *bidirectional-link* and replace duplex-link. > > 2501> The following is a list of quantitative metrics that can be used to > assess the performance of any routing protocol. > AB> add examples of new metric used in industry or by active manet > protocols > > 2501> 7. Security Considerations > AB> Needs to be amended to consider new techniques > > The purpose of the proposed update, is first because RFC2501 is a > reference to many new RFCs and that updates directs progress designs. > Please note that I will not do this work until most active participant > agree, thanking you, > > Best Regards > Abdussalam > > +++++++++++++++++++++++++++++++++++++++++++++++++++++ > On 6/21/12, Charles E. Perkins wrote: >> >> Hello Abdussalam, >> >> I didn't see what part of RFC 2501 needed to be revised. >> Do you have a specific proposal? I think that, before you >> could expect any discussion on revising that document, >> you would have to point out what part or parts need >> work. >> >> Regards, >> Charlie P. >> >> On 6/21/2012 9:10 AM, Abdussalam Baryun wrote: >>>> Could we Update RFC2501? >>> I see that RFC2501 some how defines MANET technologies, which will be >>> a good reference in the draft I am writting of L2 subnets, but maybe >>> RFC2501 is enough for the protocols, and no need for a new draft. >>> However, that will depend on the WG discussion and decision :) >>> >>> I got no answer of the question so far, therefore, I will propose it >>> to be discussed in the next meeting IETF 84. >>> >>> AB >>> ===================================================== >>> On 6/6/12, Abdussalam Baryun wrote: >>>> Hi Folks, >>>> >>>> the RFC2501 is the best RFC I read and I like it because it is easy to >>>> read, understandable, and covers solid issues of MANET. I hope the >>>> authors give us a feedback if they want to make new one as Version 2. >>>> >>>> I see that it is old (1999), and it may be interesting to update it >>>> some how, I hope the authors can update its issues and evaluation, now >>>> we got new RFCs and industries have new needs than 90s, it does not >>>> cover different devices constraints as sensors and LLNs, and IPv6, >>>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 are >>>> getting renew versions. >>>> >>>> As I can see OLSRv2 and AODVv2 are going in progress, why we don't try >>>> to update RFC2501 as well, it will only take few days or a month, to >>>> draft and submit so why leave it old-documents with old >>>> considerations? Please advise, >>>> >>>> Abdussalam Baryun >>>> University of Glamorgan, UK. >>>> ========================================================= >>>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> >> -- >> Regards, >> Charlie P. >> >> > From abdussalambaryun@gmail.com Wed Aug 1 00:42:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A7E21F86B3 for ; Wed, 1 Aug 2012 00:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cm7J37GwXZfO for ; Wed, 1 Aug 2012 00:42:02 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCCD21F8686 for ; Wed, 1 Aug 2012 00:42:01 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so7189521vcb.31 for ; Wed, 01 Aug 2012 00:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dXv3PedKcUEGCe/1mx+0SOODzmsjhmoOj8HXaBl73Pk=; b=zG9tSV/YiKd5+ZSzEfrprySv68NN5dU0xfSgXPBu1SE0G/NQbbXzCjsTohHlG/bvt4 hI9S8i9Oj32jGMyR8IgUAnJ9fFDv+OaXjn8qbgBFt5gJ6+akAOKAfRP03J9FlzzUqga8 qDUhmPSHzKxdOPWfpkY4bMdR5hdCMweZ9ejdMV/EMmALvPEfRxKX3GYZyEMyHy172NX8 Pwl1ccq9i9tscXBUm4DIN9Xyqu3GnLFc0+8iFvl0Kl/J0Y2d3yB0Vl39BjtX79l6YZ5+ 4GA0ooGAN0n0RXc+EVyqU765Tx+zaWAKUK0XeEcKhc0RRIa0+lHlTsJJ5yv3XqIEh8Er TuLQ== MIME-Version: 1.0 Received: by 10.58.133.73 with SMTP id pa9mr4893194veb.51.1343806911869; Wed, 01 Aug 2012 00:41:51 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Wed, 1 Aug 2012 00:41:51 -0700 (PDT) In-Reply-To: References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> Date: Wed, 1 Aug 2012 09:41:51 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , "Velt, R. \(Ronald\) in 't" Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 07:42:03 -0000 Hi Ulrich, comments in lines: >> >According to MANET charter, >> > >> >The purpose of the MANET working group is to standardize IP routing >> > protocol functionality suitable for wireless routing application >> > within >> > both static and dynamic topologies with increased dynamics due to node >> > motion or other factors. >> >> Strange wording, in my opinion. It seems to me that if the network >> _topology_ is truly static, you do not need a routing protocol at all. > > I agree. > I like the wording in the charter, but it MAY need to be more clear to distinguish between ROLL and MANET charters I think the AD can help us in this matter. > > >> (Note that just as the absence of movement does not imply a static >> topology, a static topology does not imply stationary nodes). >> >> > >> >So I don't think MANETs are defined by mobility, but by "increased >> >dynamics",which can be due to motion, but also to lossy links. >> >> So why aren't they called ANETs? > > Or DANET ("dynamic"). It just did not sound as nice when the term was > created. > I like that *dynamic* word, I agree with it, but we don't forget that ROLL or LLNs are also DANETs so there SHOULD be differences when we read through their documents and also in MANET documents which I am trying to solve by my drafts [1] and [2]. I agree that Mobility is the Mostly the concern of MANET (use cases and applicability), so the *dynamic* is mostly caused by Mobility in MANET, but in LLNs the *dynamic* is Mostly caused by the Losses or Low power. I will put that in my terminology draft :) [1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt [2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt Best Regards Abdussalam Baryun University of glamorgan, UK =============================== > > > >> >> Ronald >> > >> >2012/7/31 Ulrich Herberg : >> >> MANETs are not defined by mobility. It is rather about very dynamic >> >> topologies. Otherwise, community networks such as FunkFeuer would also >> >> not be qualified as MANETs. >> >> >> >> Ulrich >> >> >> >> >> >> On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal wrote: >> >>> >> >>> The wireless network of "fixed" temperature monitoring sensors and >> >>> HVAC controllers in a building. This network is an LLN. Not sure if >> >>> it qualifies as a MANET (since nothing is mobile). >> >>> >> >>> Thanks >> >>> Mukul >> >>> >> >>> ----- Original Message ----- >> >>> From: "Henning Rogge" >> >>> To: "Abdussalam Baryun" >> >>> Cc: "manet" >> >>> Sent: Tuesday, July 31, 2012 8:49:08 AM >> >>> Subject: Re: [manet] Discussing LOADng suggestions >> >>> >> >>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >> >>> wrote: >> >>> > IMHO this protocol was intended as for ROLL WG not for MANET WG, >> >>> > but then changed its direction to MANET [3]. However, please note >> >>> > that >> >>> > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. >> >That >> >>> > said, LOADng SHOULD specfy where is its limits. Then we can discuss >> >>> > adoption. >> >>> >> >>> Could you state an example what would be considered a LLN but not a >> >>> MANET. I normally consider LLNs a subset of what we call MANETs. >> >>> >> >>> Henning Rogge >> >>> >> >>> -- >> >>> Steven Hawkings about cosmic inflation: "An increase of billions of >> >>> billions of percent in a tiny fraction of a second. Of course, that >> >>> was before the present government." >> >>> _______________________________________________ >> >>> manet mailing list >> >>> manet@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/manet >> >>> _______________________________________________ >> >>> manet mailing list >> >>> manet@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> >> >> >> >> _______________________________________________ >> >> manet mailing list >> >> manet@ietf.org >> >> https://www.ietf.org/mailman/listinfo/manet >> >> >> >_______________________________________________ >> >manet mailing list >> >manet@ietf.org >> >https://www.ietf.org/mailman/listinfo/manet >> This e-mail and its contents are subject to the DISCLAIMER at >> http://www.tno.nl/emaildisclaimer >> >> > From abdussalambaryun@gmail.com Wed Aug 1 01:12:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F15321F866D for ; Wed, 1 Aug 2012 01:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOzTG6gh206O for ; Wed, 1 Aug 2012 01:12:28 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5138621F866B for ; Wed, 1 Aug 2012 01:12:28 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7280863vbb.31 for ; Wed, 01 Aug 2012 01:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=E/oiU8nxGGMxjFGKx64sZToKqz6dWFxn1FPuamJFx1o=; b=cxfloGdP534JMfZmpZ1e58aMrncX2oHKk+qVGGnfjWmtp562Z2kDu9IuO9ZAn10VH3 Oaa+MoHldI3/hQ4OCFntlPEqfe6RkRAYk3T8K4Jfw3FQ39OAox4ebsHM9dUyzm5rCNOd Lnp8Mf8jqsg58ybXP63mOiUwZU4kirrHvLKVdXozQp38ob4oUqhgIUy+dP2P/25vO/p2 SfCsF/rCWyyAO/r9ibdhYpxIaGyiuPuvInDHL6w3r+Y03qhn3vP4NKo41Da4djezOwKQ piU/0GuPV0+q/fmmbgCPF0TZC3sGP8buJkMyIbBkwyEDG2Yoc/AHexs70c2sQnOEhkZq yvUQ== MIME-Version: 1.0 Received: by 10.220.204.212 with SMTP id fn20mr16204296vcb.43.1343808747770; Wed, 01 Aug 2012 01:12:27 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Wed, 1 Aug 2012 01:12:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 10:12:27 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Request to update MANET-WG-Milestones X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 08:12:29 -0000 It is good to know that there will be an update to the Milestones as per AD request in July or this request thread request in June. However, does the WG want to amend the charter as well, not sure, but for me I have no ideas, hoping others to decide if needed. AB ===== On 6/20/12, Abdussalam Baryun wrote: > As copied below from 2012-06-13-Charter, checking the milestones of > MANET WG, please update the NHDP and SMF works are already [Done], but > not amended, > > DLEP work does not appear as milestone, please add, > > AB > ============================ > Goals and Milestones: > > Done - Post as an informational Internet-Drafts a discussion of > mobile ad-hoc > networking and issues. > Done - Agenda bashing, discussion of charter and of mobile ad > hoc networking > draft. > Done - Discuss proposed protocols and issues. Redefine charter. > Done - Publish Informational RFC on manet design considerations > Done - Review the WG Charter and update > Done - Submit AODV specification to IESG for publication as > Experimental RFC > Done - Develop I-D for potential common manet encapsulation > protocol approach > Done - Submit initial I-D(s) of candidate proposed routing > protocols and design > frameworks > Done - Promote implementation, revision, and testing of initial > proposed I-D(s) > Done - Explore basic performance and implementation issues of initial > approaches > Done - Explore proposed proactive protocol design commonalities > Done - Submit DSR specification to IESG for publication as > Experimental RFC > Done - Submit OLSR specification to IESG for publication as > Experimental RFC > Done - Submit TBRPF specification to IESG for publication as > Experimental > RFC > Done - Develop a further focused problem statement and address an > approach > for a common engineering work effort > Done - Reevaluate the WG's potential based on the problem statement > consensus > Done - Submit initial ID of RMP for WG review > Done - Submit initial ID of PMP for WG review > Done - Submit inital ID of generalized MANET flooding approach > Done - Revise WG documents and review > Done - Document initial implementation progress and experience Revise > documents based upon implementation experience > Done - Submit initial WG ID on Neighborhood Discovery (NHDP) > Done - Submit PacketBB to IESG > Done - Submit initial WG ID on MIB for NHDP, DYMO, OLSRv2 > Apr 2007 - Submit NHDP to IESG > Apr 2007 - Submit DYMO to IESG > Apr 2007 - Submit OLSRv2 to IESG > Apr 2007 - Submit SMF to IESG > ======================================= > From abdussalambaryun@gmail.com Wed Aug 1 01:19:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83DB21F8673 for ; Wed, 1 Aug 2012 01:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2deJk-+s4-Q0 for ; Wed, 1 Aug 2012 01:19:29 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB2BA21F8674 for ; Wed, 1 Aug 2012 01:19:28 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7286857vbb.31 for ; Wed, 01 Aug 2012 01:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=UO2QUAwjBBPOmdI7OEZLzbqCp8LKKMHePvKsy3+2u2Q=; b=w6Zp3z6drSbplHEdOfMZ2aBeZabukD/RDsTQEXAj4wFfC/gqNRQN1dk30bxAdeODI/ GMJE/FF3OFFuvJjVqQNkllFfymNcHi4XZBFiCBryi2IXoFHFYqrxZK2+HO7qSr76I/S1 j5pdeqIhi6xiZIGTvv1cQizPKU8rETlA1Ksmj5Sggwbxc6bio79W7UluQHCHmaL0GC/o R7d7L1hxlBkvxQxHPlPXZ+ukPJXoZYyPe/byvmmA4zHzN5m+SCCepQe3FwkcCNfmufpl o780icfJWXZ9PTEL8cuSkKBoocJsAcV2q8UHwdRyjqg/2Pu6Lovp/DqhF5m/bIRPq47E FbxQ== MIME-Version: 1.0 Received: by 10.58.128.3 with SMTP id nk3mr5051369veb.9.1343809168307; Wed, 01 Aug 2012 01:19:28 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Wed, 1 Aug 2012 01:19:28 -0700 (PDT) In-Reply-To: <20120730101213.25158.63301.idtracker@ietfa.amsl.com> References: <20120730101213.25158.63301.idtracker@ietfa.amsl.com> Date: Wed, 1 Aug 2012 10:19:28 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Fwd: New Version Notification for draft-baryun-manet-technology-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 08:19:29 -0000 Please give me your comments because I looking forward to write a new version, Regard AB ---------- Forwarded message ---------- From: internet-drafts@ietf.org Subject: New Version Notification for draft-baryun-manet-technology-00.txt A new version of I-D, draft-baryun-manet-technology-00.txt has been successfully submitted by Abdussalam Nuri Baryun and posted to the IETF repository. Filename: draft-baryun-manet-technology Revision: 00 Title: MANET Subnet Technologies Considerations Creation date: 2012-07-30 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-baryun-manet-technology-00.txt Status: http://datatracker.ietf.org/doc/draft-baryun-manet-technology Htmlized: http://tools.ietf.org/html/draft-baryun-manet-technology-00 Abstract: This documents describes three subnet technologies requirements, and considerations. These subnets are at layer 2 of the Mobile Ad hoc Network (MANET) protocols, which have some implications on router protocols and interfaces considerations. For example Packet Radio subnets (PRNETs), Low power and Lossy subnets (LLNs), and Satellite subnets (SNETs), have different service requirements which needs considerations when designing MANET routing protocols. This document also outlines use-case of these MANET subnets, and requirements that may be considered in MANET routing, for the users and designers information. The IETF Secretariat From abdussalambaryun@gmail.com Wed Aug 1 01:21:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B14E21F8613 for ; Wed, 1 Aug 2012 01:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su+JpbCcWMDu for ; Wed, 1 Aug 2012 01:21:35 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9D821F8611 for ; Wed, 1 Aug 2012 01:21:35 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7288654vbb.31 for ; Wed, 01 Aug 2012 01:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=y8hQgyIFaQ1BP7Re2DJQSSKtxqAkoQcjE13mtVLYFNs=; b=dtLkqg+m+ghqFB8EaIWjCN8ldH3h2c4CHyvfBrJzwOFs6uVjneKxS9DHJddFWqUKfn g9KNMn4R6lQ8dn8MDUk2XQAY7GnAXhIC9vZxRtT9uCuKuc1oAaap36+7IRmE9+oVK2Uv V4/3lcg5t59oeriiticltKB2n3RxwpLIRR3C2I5oUXtA/fzj8Ad5/3YJK0h1s3w4ayzr ZRMC4Ep2dXgMr/ajSAfH3wc//GmGc6SNLKWjZK1zG4Q9oEEaHKjNClnxSmMn2rhOuI8m lddECXcSJ+qLK589Tu5fAO1lmicnIoaHg70M7J9rfs0RGf8OKJImhTmpRXhD9kXiAXru Xx8Q== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr822326vds.117.1343809294971; Wed, 01 Aug 2012 01:21:34 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Wed, 1 Aug 2012 01:21:34 -0700 (PDT) In-Reply-To: <20120704141850.4730.42584.idtracker@ietfa.amsl.com> References: <20120704141850.4730.42584.idtracker@ietfa.amsl.com> Date: Wed, 1 Aug 2012 10:21:34 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Fwd: New Version Notification for draft-baryun-manet-terminology-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 08:21:36 -0000 Please give me your comments because I looking forward to write a new version, Regard AB ---------- Forwarded message ---------- From: internet-drafts@ietf.org Subject: New Version Notification for draft-baryun-manet-terminology-00.txt IETF repository. Filename: draft-baryun-manet-terminology Revision: 00 Title: Terminology in Mobile Ad hoc Networks draft-baryun-manet-terminology-00.txt Abstract Creation date: 2012-07-02 WG ID: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-baryun-manet-terminology-00.txt Status: http://datatracker.ietf.org/doc/draft-baryun-manet-terminology Htmlized: http://tools.ietf.org/html/draft-baryun-manet-terminology-00 Abstract: This document defines Mobile Ad hoc NETwork (MANET) terminology for discussing routing requirements, solutions, and protocols of networking referred to as mobile, multihop, wireless networking. The IETF Secretariat From Chris.Dearlove@baesystems.com Wed Aug 1 01:59:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB09821F86FF for ; Wed, 1 Aug 2012 01:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.236 X-Spam-Level: X-Spam-Status: No, score=-10.236 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np5TLFSg86RT for ; Wed, 1 Aug 2012 01:59:03 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBBE21F86EA for ; Wed, 1 Aug 2012 01:59:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,691,1336345200"; d="scan'208";a="260449434" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 01 Aug 2012 09:58:59 +0100 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q718wwqm029856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 09:58:58 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.170]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Wed, 1 Aug 2012 09:58:59 +0100 From: "Dearlove, Christopher (UK)" To: "Velt, R. (Ronald) in 't" , Antonin Bas , Ulrich Herberg Thread-Topic: [manet] Discussing LOADng suggestions Thread-Index: AQHNWdphm+u1REK/lkKRZGyT6FVJyZdDgSgAgAAA4wCAAD5HAIAAAY2AgAAB3gCAAArtgIABA/iQ Date: Wed, 1 Aug 2012 08:58:58 +0000 Message-ID: References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> In-Reply-To: <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , Abdussalam Baryun Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 08:59:03 -0000 Probably not called ANETs because there wasn't a French Impressionist paint= er of that name. There is a tendency towards overloaded names in at least p= arts of the IETF. The first ad hoc network I ever worked on that got out of a laboratory had = non-moving nodes but variable routing as radio waves do not propagate well = through large metal vehicles, and those moved. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of V= elt, R. (Ronald) in 't Sent: 31 July 2012 19:23 To: Antonin Bas; Ulrich Herberg Cc: manet; Abdussalam Baryun Subject: Re: [manet] Discussing LOADng suggestions ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- >-----Original Message----- >From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >Of Antonin Bas >Sent: dinsdag 31 juli 2012 19:44 >To: Ulrich Herberg >Cc: manet; Abdussalam Baryun >Subject: Re: [manet] Discussing LOADng suggestions > >According to MANET charter, > >The purpose of the MANET working group is to standardize IP routing > protocol functionality suitable for wireless routing application within > both static and dynamic topologies with increased dynamics due to node > motion or other factors. Strange wording, in my opinion. It seems to me that if the network _topolog= y_ is truly static, you do not need a routing protocol at all. (Note that j= ust as the absence of movement does not imply a static topology, a static t= opology does not imply stationary nodes). > >So I don't think MANETs are defined by mobility, but by "increased >dynamics",which can be due to motion, but also to lossy links. So why aren't they called ANETs? Ronald > >2012/7/31 Ulrich Herberg : >> MANETs are not defined by mobility. It is rather about very dynamic >> topologies. Otherwise, community networks such as FunkFeuer would also >> not be qualified as MANETs. >> >> Ulrich >> >> >> On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal wrote: >>> >>> The wireless network of "fixed" temperature monitoring sensors and >>> HVAC controllers in a building. This network is an LLN. Not sure if >>> it qualifies as a MANET (since nothing is mobile). >>> >>> Thanks >>> Mukul >>> >>> ----- Original Message ----- >>> From: "Henning Rogge" >>> To: "Abdussalam Baryun" >>> Cc: "manet" >>> Sent: Tuesday, July 31, 2012 8:49:08 AM >>> Subject: Re: [manet] Discussing LOADng suggestions >>> >>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>> wrote: >>> > IMHO this protocol was intended as for ROLL WG not for MANET WG, >>> > but then changed its direction to MANET [3]. However, please note >>> > that >>> > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. >That >>> > said, LOADng SHOULD specfy where is its limits. Then we can discuss >>> > adoption. >>> >>> Could you state an example what would be considered a LLN but not a >>> MANET. I normally consider LLNs a subset of what we call MANETs. >>> >>> Henning Rogge >>> >>> -- >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>> billions of percent in a tiny fraction of a second. Of course, that >>> was before the present government." >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Wed Aug 1 02:04:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C84221F86BD for ; Wed, 1 Aug 2012 02:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.253 X-Spam-Level: X-Spam-Status: No, score=-10.253 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s13d8PbiE3su for ; Wed, 1 Aug 2012 02:04:08 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 2D25521F869C for ; Wed, 1 Aug 2012 02:04:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,691,1336345200"; d="scan'208,217";a="260452330" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 01 Aug 2012 10:04:06 +0100 Received: from GLKXH0004V.GREENLNK.net ([10.109.2.35]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q71945uC001561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 10:04:06 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.170]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0309.002; Wed, 1 Aug 2012 10:04:05 +0100 From: "Dearlove, Christopher (UK)" To: Ulrich Herberg , "Velt, R. (Ronald) in 't" Thread-Topic: [manet] Discussing LOADng suggestions Thread-Index: AQHNWdphm+u1REK/lkKRZGyT6FVJyZdDgSgAgAAA4wCAAD5HAIAAAY2AgAAB3gCAAArtgIAAAMAAgAEEyIA= Date: Wed, 1 Aug 2012 09:04:04 +0000 Message-ID: References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24EB48C3GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: manet , Abdussalam Baryun Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 09:04:09 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24EB48C3GLKXM0002VGREEN_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If a network is static, but not preconfigured, then you may still want to run a proactive routing protocol up to the point where you have established the topology, then turn it off. Or if there's a reason not to want to do that, you could run a reactive routing protocol, with anything up to infinite expiry time on discovered routes. And one more scenario. Your nodes are all stationary, your propagation is stationary. You have no moving obstacles. But things are still (sporadically) dynamic when your nodes fail (battery exhaustion, accident, enemy action). -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg Sent: 31 July 2012 19:26 To: Velt, R. (Ronald) in 't Cc: manet; Abdussalam Baryun Subject: Re: [manet] Discussing LOADng suggestions *** WARNING *** This message originates from outside our organisation, either from an external partner or the internet. Keep this in mind if you answer this message. Please see this process on how to deal with suspicious emails. Ronald, On Tue, Jul 31, 2012 at 11:23 AM, Velt, R. (Ronald) in 't > wrote: >-----Original Message----- >From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >Of Antonin Bas >Sent: dinsdag 31 juli 2012 19:44 >To: Ulrich Herberg >Cc: manet; Abdussalam Baryun >Subject: Re: [manet] Discussing LOADng suggestions > >According to MANET charter, > >The purpose of the MANET working group is to standardize IP routing > protocol functionality suitable for wireless routing application within > both static and dynamic topologies with increased dynamics due to node > motion or other factors. Strange wording, in my opinion. It seems to me that if the network _topology_ is truly static, you do not need a routing protocol at all. I agree. (Note that just as the absence of movement does not imply a static topology, a static topology does not imply stationary nodes). > >So I don't think MANETs are defined by mobility, but by "increased >dynamics",which can be due to motion, but also to lossy links. So why aren't they called ANETs? Or DANET ("dynamic"). It just did not sound as nice when the term was created. Best Ulrich Ronald > >2012/7/31 Ulrich Herberg >: >> MANETs are not defined by mobility. It is rather about very dynamic >> topologies. Otherwise, community networks such as FunkFeuer would also >> not be qualified as MANETs. >> >> Ulrich >> >> >> On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal > wrote: >>> >>> The wireless network of "fixed" temperature monitoring sensors and >>> HVAC controllers in a building. This network is an LLN. Not sure if >>> it qualifies as a MANET (since nothing is mobile). >>> >>> Thanks >>> Mukul >>> >>> ----- Original Message ----- >>> From: "Henning Rogge" > >>> To: "Abdussalam Baryun" > >>> Cc: "manet" > >>> Sent: Tuesday, July 31, 2012 8:49:08 AM >>> Subject: Re: [manet] Discussing LOADng suggestions >>> >>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>> > wrote: >>> > IMHO this protocol was intended as for ROLL WG not for MANET WG, >>> > but then changed its direction to MANET [3]. However, please note >>> > that >>> > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. >That >>> > said, LOADng SHOULD specfy where is its limits. Then we can discuss >>> > adoption. >>> >>> Could you state an example what would be considered a LLN but not a >>> MANET. I normally consider LLNs a subset of what we call MANETs. >>> >>> Henning Rogge >>> >>> -- >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>> billions of percent in a tiny fraction of a second. Of course, that >>> was before the present government." >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24EB48C3GLKXM0002VGREEN_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

If a network is static, but not preconfigured, then you may still want to run a proactive routing protocol up to the point where you have established the topology, then turn it off. Or if there's a reason not to want to do that, you could run a reactive routing protocol, with anything up to infinite expiry time on discovered routes.

 

And one more scenario. Your nodes are all stationary, your propagation is stationary. You have no moving obstacles. But things are still (sporadically) dynamic when your nodes fail (battery exhaustion, accident, enemy action).

 

--

Christopher Dearlove

Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg
Sent: 31 July 2012 19:26
To: Velt, R. (Ronald) in 't
Cc: manet; Abdussalam Baryun
Subject: Re: [manet] Discussing LOADng suggestions

 

 

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

Ronald,

On Tue, Jul 31, 2012 at 11:23 AM, Velt, R. (Ronald) in 't <Ronald.intVelt@tno.nl> wrote:


>-----Original Message-----
>From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf
>Of Antonin Bas
>Sent: dinsdag 31 juli 2012 19:44
>To: Ulrich Herberg
>Cc: manet; Abdussalam Baryun
>Subject: Re: [manet] Discussing LOADng suggestions
>

>According to MANET charter,
>
>The purpose of the MANET working group is to standardize IP routing
>  protocol functionality suitable for wireless routing application within
>  both static and dynamic topologies with increased dynamics due to node
>  motion or other factors.

Strange wording, in my opinion. It seems to me that if the network _topology_ is truly static, you do not need a routing protocol at all.



I agree.

 

(Note that just as the absence of movement does not imply a static topology, a static topology does not imply stationary nodes).


>
>So I don't think MANETs are defined by mobility, but by "increased
>dynamics",which can be due to motion, but also to lossy links.

So why aren't they called ANETs?



Or DANET ("dynamic"). It just did not sound as nice when the term was created.

Best
Ulrich


 


Ronald

>
>2012/7/31 Ulrich Herberg <ulrich@herberg.name>:
>> MANETs are not defined by mobility. It is rather about very dynamic
>> topologies. Otherwise, community networks such as FunkFeuer would also
>> not be qualified as MANETs.
>>
>> Ulrich
>>
>>
>> On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal <mukul@uwm.edu> wrote:
>>>
>>> The wireless network of "fixed" temperature monitoring sensors and
>>> HVAC controllers in a building. This network is an LLN. Not sure if
>>> it qualifies as a MANET (since nothing is mobile).
>>>
>>> Thanks
>>> Mukul
>>>
>>> ----- Original Message -----
>>> From: "Henning Rogge" <hrogge@googlemail.com>
>>> To: "Abdussalam Baryun" <abdussalambaryun@gmail.com>
>>> Cc: "manet" <manet@ietf.org>
>>> Sent: Tuesday, July 31, 2012 8:49:08 AM
>>> Subject: Re: [manet] Discussing LOADng suggestions
>>>
>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun
>>> <abdussalambaryun@gmail.com> wrote:
>>> > IMHO this protocol was intended as for ROLL WG not for MANET WG,
>>> > but then changed its direction to MANET [3]. However, please note
>>> > that
>>> > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs.
>That
>>> > said, LOADng SHOULD specfy where is its limits. Then we can discuss
>>> > adoption.
>>>
>>> Could you state an example what would be considered a LLN but not a
>>> MANET. I normally consider LLNs a subset of what we call MANETs.
>>>
>>> Henning Rogge
>>>
>>> --
>>> Steven Hawkings about cosmic inflation: "An increase of billions of
>>> billions of percent in a tiny fraction of a second. Of course, that
>>> was before the present government."
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>
>>
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www.ietf.org/mailman/listinfo/manet

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

 


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24EB48C3GLKXM0002VGREEN_-- From c.chauvenet@watteco.com Wed Aug 1 02:15:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7AD621F84B9; Wed, 1 Aug 2012 02:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPIDhkFaQXlj; Wed, 1 Aug 2012 02:15:03 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id F011921F84B3; Wed, 1 Aug 2012 02:15:02 -0700 (PDT) Received: from mail189-co1-R.bigfish.com (10.243.78.230) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.23; Wed, 1 Aug 2012 09:15:01 +0000 Received: from mail189-co1 (localhost [127.0.0.1]) by mail189-co1-R.bigfish.com (Postfix) with ESMTP id C51A94012E; Wed, 1 Aug 2012 09:15:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -74 X-BigFish: VPS-74(zzbb2dI98dI9371Ic89bh1432I15caKJzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah107ah) Received: from mail189-co1 (localhost.localdomain [127.0.0.1]) by mail189-co1 (MessageSwitch) id 1343812499377748_2740; Wed, 1 Aug 2012 09:14:59 +0000 (UTC) Received: from CO1EHSMHS003.bigfish.com (unknown [10.243.78.233]) by mail189-co1.bigfish.com (Postfix) with ESMTP id 5A0389C0044; Wed, 1 Aug 2012 09:14:59 +0000 (UTC) Received: from DBXPRD0510HT001.eurprd05.prod.outlook.com (157.56.252.165) by CO1EHSMHS003.bigfish.com (10.243.66.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 1 Aug 2012 09:14:59 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.6.25]) by DBXPRD0510HT001.eurprd05.prod.outlook.com ([10.255.67.164]) with mapi id 14.16.0175.005; Wed, 1 Aug 2012 09:14:25 +0000 From: C Chauvenet To: 'Abdussalam Baryun' , Henning Rogge Thread-Topic: [Roll] Some LLNs are NOT MANETs Thread-Index: AQHNb7ZZsizvtTQHlkWOqJIDXndu4ZdEqB8w Date: Wed, 1 Aug 2012 09:14:25 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.241.54.131] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll , manet Subject: Re: [manet] [Roll] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 09:15:04 -0000 Hi,=20 This is an interesting discussion. My understanding is that both MANET and ROLL considers lossy/dynamic links = in the way described in the MANET charter : "static and dynamic topologies= with increased dynamics due to node motion or other factors." I also agree= that dynamicity of links is not hard wired to node mobility. So, in the LLN Vs MANET debate, I think they share the "N" for Networks, an= d the 2nd "L" for Lossy. So the remaining point is the first L, meaning Low Power. Low Power requirements is explicit in the ROLL charter and not mentioned at= all in the MANET charter. Is the power efficiency consideration the big difference between ROLL and M= ANET ? C=E9dric. -----Message d'origine----- De=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de A= bdussalam Baryun Envoy=E9=A0: mercredi 1 ao=FBt 2012 09:22 =C0=A0: Henning Rogge Cc=A0: roll; manet Objet=A0: [Roll] Some LLNs are NOT MANETs Hi Henning, I am about to say many LLNs are NOT MANETs but it seems like the market or = community will decide the outcome, but surly that some LLNs are NOT MANETs. > Could you state an example what would be considered a LLN but not a=20 > MANET. I normally consider LLNs a subset of what we call MANETs. I not totally agree with that, because we need to be considering both NETs = use case and applicability in the vision of the different WGs (MANET and RO= LL). There are many examples we can find them in the [RFC2501] for MANETs c= haracteristics and applicability, and for LLNs characteristics in [RFC5548]= , [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs requirements. That = is why I suggested before that OLSRv2 and AODVv2 should mention their applicability to LLN if they do. The= y just refer to RFC2501, but RFC2501 is OLD and does not mention LLN but de= scribes the meaning. The authors of RFC2501 still not responded to my updat= e suggestions. I understood from one discussion in MANET WG that few don't have time to re= ad many pages of documents, so that is why I suggested to have terminology = I-D [1] as we have ROLL terminology [ROLL] . I also taken initiative to mak= e new draft of MANET subnet technologies which include only related LLNs [= AB2]. Therefore, I will add the definition for MANET and LLN into my manet-termin= ology draft [AB1] (propose that authors of [ROLL] define LLN more details) = to assist discussions as it is proved now in the list that there still is p= roblems in definitions in MANET WG or in some I-D editorial content. [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt Best Wishes Abdussalam Baryun University of Glamorgan, UK =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D On 7/31/12, Henning Rogge wrote: > On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun > subject: Re: [manet] Discussing LOADng suggestions=20 > wrote: >> IMHO this protocol was intended as for ROLL WG not for MANET WG, but=20 >> then changed its direction to MANET [3]. However, please note that >> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That=20 >> said, LOADng SHOULD specfy where is its limits. Then we can discuss=20 >> adoption. > > Could you state an example what would be considered a LLN but not a=20 > MANET. I normally consider LLNs a subset of what we call MANETs. > > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of=20 > billions of percent in a tiny fraction of a second. Of course, that=20 > was before the present government." > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From abdussalambaryun@gmail.com Wed Aug 1 04:41:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE7B21F85D5; Wed, 1 Aug 2012 04:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dOjBQdYCK7I; Wed, 1 Aug 2012 04:41:42 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F2D9721F85D0; Wed, 1 Aug 2012 04:41:41 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so7409412vcb.31 for ; Wed, 01 Aug 2012 04:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Xl9N0mbI4DATIcSgkleaYgtQUI4ZldqxgOG7Of4Ob+w=; b=L7crugNN1o4M0W9SqwFxoJAEXNLkP0IGbvB7YFX77hhoW1U6xeR1oIOh7elX6H5v/+ sEroAmhGsWiFIjw5CDE9LZdXzfMp9YHQzjhngFm5ZoD/DNs3Lp97+TISpGvJU5WYz7so MyN6Zsq2thGDz5ePPjqXhvKI8uWN3BXdmRSbtiW5JzJXy1g6Qnk2TDsmTS+3WGqZ3ARk g++muzXybGGuvlFf4XhYi7hjq4lorW00CVjdLLL4n/3jSlyVQbGanN/jxpgNd5IlEh7Q cMpBxoIYfzMEhizmau7LqMzfdKjrFbFt+E0RGNzeYOv9l3VWPMxR1RzKzwBJgPprTaeJ hbYQ== MIME-Version: 1.0 Received: by 10.52.90.144 with SMTP id bw16mr14556192vdb.129.1343821300985; Wed, 01 Aug 2012 04:41:40 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Wed, 1 Aug 2012 04:41:39 -0700 (PDT) In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> Date: Wed, 1 Aug 2012 13:41:39 +0200 Message-ID: From: Abdussalam Baryun To: C Chauvenet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll , manet Subject: Re: [manet] [Roll] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 11:41:43 -0000 Hi C=E9dric, I think the RFC2501 is more important than the WG charter, because the charter MAY change but RFCs never changes (only can be updated, obsoleted or replaced). So far now all MANET-protocols are refering to RFC2501 which is good and SHOULD continue, and I like this referencing to documents (even if they are old or expired) not referencing to charters, because for example, if in a journal paper we reference to the charter of MANET WG or ROLL WG the information is not solid like if you reference a published document (publisher date), but still we can reference the charter as web reference sited date. I read some paper that reference sited web documents but they may be not valid and cannot be read for some reason. Therefore, IMHO, we need to stick to the following document to make a right decision in definitions: 1) [RFC2501] for MANETs. (published in 1999) 2) [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] for LLNs. (published in 2009) Low power was indicated in RFC2501 in section 5.1 as and also the word *sink*, in page 7 you read . IMHO, as long we have a ROLL WG in IETF we need to forward work to it which has no mobility behavior. Delegation will help make work flowing and more focused. Regards AB =3D=3D=3D=3D=3D=3D=3D On 8/1/12, C Chauvenet wrote: > Hi, > > This is an interesting discussion. > > My understanding is that both MANET and ROLL considers lossy/dynamic link= s > in the way described in the MANET charter : "static and dynamic topologi= es > with increased dynamics due to node motion or other factors." I also agre= e > that dynamicity of links is not hard wired to node mobility. > > So, in the LLN Vs MANET debate, I think they share the "N" for Networks, = and > the 2nd "L" for Lossy. > So the remaining point is the first L, meaning Low Power. > > Low Power requirements is explicit in the ROLL charter and not mentioned = at > all in the MANET charter. > Is the power efficiency consideration the big difference between ROLL and > MANET ? > > C=E9dric. > > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de > Abdussalam Baryun > Envoy=E9 : mercredi 1 ao=FBt 2012 09:22 > =C0 : Henning Rogge > Cc : roll; manet > Objet : [Roll] Some LLNs are NOT MANETs > > Hi Henning, > > I am about to say many LLNs are NOT MANETs but it seems like the market o= r > community will decide the outcome, but surly that some LLNs are NOT MANET= s. > >> Could you state an example what would be considered a LLN but not a >> MANET. I normally consider LLNs a subset of what we call MANETs. > > I not totally agree with that, because we need to be considering both NET= s > use case and applicability in the vision of the different WGs (MANET and > ROLL). There are many examples we can find them in the [RFC2501] for MANE= Ts > characteristics and applicability, and for LLNs characteristics in > [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs > requirements. That is why I suggested before that > OLSRv2 and AODVv2 should mention their applicability to LLN if they do. T= hey > just refer to RFC2501, but RFC2501 is OLD and does not mention LLN but > describes the meaning. The authors of RFC2501 still not responded to my > update suggestions. > > I understood from one discussion in MANET WG that few don't have time to > read many pages of documents, so that is why I suggested to have terminol= ogy > I-D [1] as we have ROLL terminology [ROLL] . I also taken initiative to m= ake > new draft of MANET subnet technologies which include only related LLNs > [AB2]. > > Therefore, I will add the definition for MANET and LLN into my > manet-terminology draft [AB1] (propose that authors of [ROLL] define LLN > more details) to assist discussions as it is proved now in the list that > there still is problems in definitions in MANET WG or in some I-D editori= al > content. > > [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt > [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt > [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt > > Best Wishes > > Abdussalam Baryun > University of Glamorgan, UK > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > On 7/31/12, Henning Rogge wrote: >> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >> subject: Re: [manet] Discussing LOADng suggestions >> wrote: >>> IMHO this protocol was intended as for ROLL WG not for MANET WG, but >>> then changed its direction to MANET [3]. However, please note that >>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >>> said, LOADng SHOULD specfy where is its limits. Then we can discuss >>> adoption. >> >> Could you state an example what would be considered a LLN but not a >> MANET. I normally consider LLNs a subset of what we call MANETs. >> >> Henning Rogge >> >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > From c.chauvenet@watteco.com Wed Aug 1 05:46:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4287611E8392; Wed, 1 Aug 2012 05:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TskQc8ZLeas; Wed, 1 Aug 2012 05:46:41 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 10DAC11E839D; Wed, 1 Aug 2012 05:46:40 -0700 (PDT) Received: from mail71-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 1 Aug 2012 12:46:39 +0000 Received: from mail71-va3 (localhost [127.0.0.1]) by mail71-va3-R.bigfish.com (Postfix) with ESMTP id 89D9040339; Wed, 1 Aug 2012 12:46:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT005.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -74 X-BigFish: VPS-74(zzbb2dI98dI9371Ic89bh1432I15caKJzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839hd25he5bhf0ah107ah) Received: from mail71-va3 (localhost.localdomain [127.0.0.1]) by mail71-va3 (MessageSwitch) id 1343825197351605_8358; Wed, 1 Aug 2012 12:46:37 +0000 (UTC) Received: from VA3EHSMHS039.bigfish.com (unknown [10.7.14.235]) by mail71-va3.bigfish.com (Postfix) with ESMTP id 529CDC00B0; Wed, 1 Aug 2012 12:46:37 +0000 (UTC) Received: from DBXPRD0510HT005.eurprd05.prod.outlook.com (157.56.252.165) by VA3EHSMHS039.bigfish.com (10.7.99.49) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 1 Aug 2012 12:46:37 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.6.25]) by DBXPRD0510HT005.eurprd05.prod.outlook.com ([10.255.67.168]) with mapi id 14.16.0175.005; Wed, 1 Aug 2012 12:46:26 +0000 From: C Chauvenet To: Abdussalam Baryun Thread-Topic: [Roll] Some LLNs are NOT MANETs Thread-Index: AQHNb7ZZsizvtTQHlkWOqJIDXndu4ZdEqB8wgAAtroCAABIYgA== Date: Wed, 1 Aug 2012 12:46:25 +0000 Message-ID: <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.57.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <29E2DAFBDF1F614F932378B14EB8EE9D@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll , manet Subject: Re: [manet] [Roll] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 12:46:42 -0000 Hi,=20 Thank you for your answer,=20 See inline. Le 1 ao=FBt 2012 =E0 13:41, Abdussalam Baryun a =E9crit : > Hi C=E9dric, >=20 > I think the RFC2501 is more important than the WG charter, because the > charter MAY change but RFCs never changes (only can be updated, > obsoleted or replaced). Good Point, 100% agree. > So far now all MANET-protocols are refering to > RFC2501 which is good and SHOULD continue, and I like this referencing > to documents (even if they are old or expired) not referencing to > charters, because for example, if in a journal paper we reference to > the charter of MANET WG or ROLL WG the information is not solid like > if you reference a published document (publisher date), but still we > can reference the charter as web reference sited date. >=20 > I read some paper that reference sited web documents but they may be > not valid and cannot be read for some reason. Therefore, IMHO, we need > to stick to the following document to make a right decision in > definitions: >=20 > 1) [RFC2501] for MANETs. (published in 1999) > 2) [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] for LLNs. > (published in 2009) I think they are good references to build some arguments into this discussi= on. >=20 > Low power was indicated in RFC2501 in section 5.1 as constraints> and also the word *sink*, in page 7 you read for energy conservation>. IMHO, as long we have a ROLL WG in IETF we > need to forward work to it which has no mobility behavior. Delegation > will help make work flowing and more focused. When you say "IMHO, as long we have a ROLL WG in IETF we need to forward wo= rk to it which has no mobility behavior", do you mean that the difference b= etween ROLL and MANET is limited to mobility considerations ? Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC5867 a= ll include the usual IoT constraints : Memory, Processing, Power, Battery, = Cost and Size of device. RFC5673 does not mention explicitly processing and size constraints, but me= ntion all the others. RFC 2501 speak about energy and power, as you previously mentioned, but doe= s not say something on the following constraints : Memory, Processing, Cos= t and Size. Do you think that these constraints are in the MANET scope ? I guess that they may be (obviously for Cost), but not in the same order of= magnitude as the type of devices described in the requirements RFC of ROLL= . Regards, C=E9dric. >=20 > Regards > AB > =3D=3D=3D=3D=3D=3D=3D >=20 > On 8/1/12, C Chauvenet wrote: >> Hi, >>=20 >> This is an interesting discussion. >>=20 >> My understanding is that both MANET and ROLL considers lossy/dynamic lin= ks >> in the way described in the MANET charter : "static and dynamic topolog= ies >> with increased dynamics due to node motion or other factors." I also agr= ee >> that dynamicity of links is not hard wired to node mobility. >>=20 >> So, in the LLN Vs MANET debate, I think they share the "N" for Networks,= and >> the 2nd "L" for Lossy. >> So the remaining point is the first L, meaning Low Power. >>=20 >> Low Power requirements is explicit in the ROLL charter and not mentioned= at >> all in the MANET charter. >> Is the power efficiency consideration the big difference between ROLL an= d >> MANET ? >>=20 >> C=E9dric. >>=20 >> -----Message d'origine----- >> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de >> Abdussalam Baryun >> Envoy=E9 : mercredi 1 ao=FBt 2012 09:22 >> =C0 : Henning Rogge >> Cc : roll; manet >> Objet : [Roll] Some LLNs are NOT MANETs >>=20 >> Hi Henning, >>=20 >> I am about to say many LLNs are NOT MANETs but it seems like the market = or >> community will decide the outcome, but surly that some LLNs are NOT MANE= Ts. >>=20 >>> Could you state an example what would be considered a LLN but not a >>> MANET. I normally consider LLNs a subset of what we call MANETs. >>=20 >> I not totally agree with that, because we need to be considering both NE= Ts >> use case and applicability in the vision of the different WGs (MANET and >> ROLL). There are many examples we can find them in the [RFC2501] for MAN= ETs >> characteristics and applicability, and for LLNs characteristics in >> [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs >> requirements. That is why I suggested before that >> OLSRv2 and AODVv2 should mention their applicability to LLN if they do. = They >> just refer to RFC2501, but RFC2501 is OLD and does not mention LLN but >> describes the meaning. The authors of RFC2501 still not responded to my >> update suggestions. >>=20 >> I understood from one discussion in MANET WG that few don't have time to >> read many pages of documents, so that is why I suggested to have termino= logy >> I-D [1] as we have ROLL terminology [ROLL] . I also taken initiative to = make >> new draft of MANET subnet technologies which include only related LLNs >> [AB2]. >>=20 >> Therefore, I will add the definition for MANET and LLN into my >> manet-terminology draft [AB1] (propose that authors of [ROLL] define LLN >> more details) to assist discussions as it is proved now in the list that >> there still is problems in definitions in MANET WG or in some I-D editor= ial >> content. >>=20 >> [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >> [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >> [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt >>=20 >> Best Wishes >>=20 >> Abdussalam Baryun >> University of Glamorgan, UK >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> On 7/31/12, Henning Rogge wrote: >>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>> subject: Re: [manet] Discussing LOADng suggestions >>> wrote: >>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, but >>>> then changed its direction to MANET [3]. However, please note that >>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >>>> said, LOADng SHOULD specfy where is its limits. Then we can discuss >>>> adoption. >>>=20 >>> Could you state an example what would be considered a LLN but not a >>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>=20 >>> Henning Rogge >>>=20 >>> -- >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>> billions of percent in a tiny fraction of a second. Of course, that >>> was before the present government." >>>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 >>=20 >=20 From abdussalambaryun@gmail.com Wed Aug 1 06:21:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1902B11E81C0 for ; Wed, 1 Aug 2012 06:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.171 X-Spam-Level: X-Spam-Status: No, score=-3.171 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXHmZh4VdqqS for ; Wed, 1 Aug 2012 06:21:22 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC8EB11E8533 for ; Wed, 1 Aug 2012 06:21:21 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so7525023vcb.31 for ; Wed, 01 Aug 2012 06:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oxvTvotuOti7yVgtKt/FhosRO6hgtu6PappTwgnbN5U=; b=QRULCzJFZOELApjfbzarGWraVtamBkVSsT+CxPB8my0wEgn2ecGnrw55j6Gg6zfUCc vw/piEra7fMKYR4/MG0xk0ObE9/qMOtSmlW6DD4ls2PkR1mCnfmkHY0JsbyKCFOZx/Sv OCBnnTB+YgqEyjb29OCj8lwLY12AXRWeD+y1HBbj5NjLQyPugMW9VPjPlOAXtk9shIae 42HjHVBusi2R0OcRjA+AXgqRUDPAJPIL85XLMbRZcSlpn3A/MTka4Rg2k3Ork+GoGlOt RKbezK12TVVYz9yr2trd3bXO0gKYugB1Fib+R5EBhVmJ07eVOyoOqG7LaoiSIN1DOREz MiZA== MIME-Version: 1.0 Received: by 10.220.150.138 with SMTP id y10mr16838334vcv.73.1343827281236; Wed, 01 Aug 2012 06:21:21 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Wed, 1 Aug 2012 06:21:21 -0700 (PDT) In-Reply-To: <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> Date: Wed, 1 Aug 2012 15:21:21 +0200 Message-ID: From: Abdussalam Baryun To: C Chauvenet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 13:21:23 -0000 Hi C=E9dric, Ok we can discuss efficiently when we read the documents (production of such WG)as you agreed. > When you say "IMHO, as long we have a ROLL WG in IETF we need to forward > work to it which has no mobility behavior", do you mean that the differen= ce > between ROLL and MANET is limited to mobility considerations ? *Mobility* It is the mostly difference clearly spoted between the documents produced by the both WGs, also the name MANET starts with Mobile, the word mobile is not equal to change/dynamic. So MANET refers to mobile node or mobile network, which means location change *NOT* topology change/dynamic. In the old days there was no ROLL WG so MANET WG was doing the job. > > Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC5867 > all include the usual IoT constraints : Memory, Processing, Power, Batter= y, > Cost and Size of device. > RFC5673 does not mention explicitly processing and size constraints, but > mention all the others. > Ok, > RFC 2501 speak about energy and power, as you previously mentioned, but d= oes > not say something on the following constraints : Memory, Processing, Cos= t > and Size. Yes your right, but be careful RFC2501 does not exclude thoes constraints either. However, if the MANET network has some nodes with constraints but clearly mobility is the main constraint. > > Do you think that these constraints are in the MANET scope ? > I guess that they may be (obviously for Cost), but not in the same order = of > magnitude as the type of devices described in the requirements RFC of ROL= L. Really don't mind either way for MANET WG, and will think that the WG community wants it in between In-Scope and Out-Scope, that may be strange but seems that is what is happening as I read documents. Out of IETF, MANET is mostly understood as mobile nodes connecting, not LLNs. Overall, IMHO, in the end it is the decision of the IETF community to decide of any new idea or any I-D acceptance/adoption, but for the WG it MAY take over a WORK as an IETF I-D, but it may not be successful to convince the IETF community to continue the work or make it become a RFC, we always have to see through to make the work efforts flow successfully. We do not forget that many participants work in both WGs. Regards Abdussalam =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D On 8/1/12, C Chauvenet wrote: > Hi, > > Thank you for your answer, > > See inline. > > Le 1 ao=FBt 2012 =E0 13:41, Abdussalam Baryun a =E9crit : > >> Hi C=E9dric, >> >> I think the RFC2501 is more important than the WG charter, because the >> charter MAY change but RFCs never changes (only can be updated, >> obsoleted or replaced). > > Good Point, 100% agree. > >> So far now all MANET-protocols are refering to >> RFC2501 which is good and SHOULD continue, and I like this referencing >> to documents (even if they are old or expired) not referencing to >> charters, because for example, if in a journal paper we reference to >> the charter of MANET WG or ROLL WG the information is not solid like >> if you reference a published document (publisher date), but still we >> can reference the charter as web reference sited date. >> >> I read some paper that reference sited web documents but they may be >> not valid and cannot be read for some reason. Therefore, IMHO, we need >> to stick to the following document to make a right decision in >> definitions: >> >> 1) [RFC2501] for MANETs. (published in 1999) >> 2) [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] for LLNs. >> (published in 2009) > > I think they are good references to build some arguments into this > discussion. > >> >> Low power was indicated in RFC2501 in section 5.1 as > constraints> and also the word *sink*, in page 7 you read > for energy conservation>. IMHO, as long we have a ROLL WG in IETF we >> need to forward work to it which has no mobility behavior. Delegation >> will help make work flowing and more focused. > > When you say "IMHO, as long we have a ROLL WG in IETF we need to forward > work to it which has no mobility behavior", do you mean that the differen= ce > between ROLL and MANET is limited to mobility considerations ? > > Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC5867 > all include the usual IoT constraints : Memory, Processing, Power, Batter= y, > Cost and Size of device. > RFC5673 does not mention explicitly processing and size constraints, but > mention all the others. > > RFC 2501 speak about energy and power, as you previously mentioned, but d= oes > not say something on the following constraints : Memory, Processing, Cos= t > and Size. > > Do you think that these constraints are in the MANET scope ? > I guess that they may be (obviously for Cost), but not in the same order = of > magnitude as the type of devices described in the requirements RFC of ROL= L. > > Regards, > > C=E9dric. > >> >> Regards >> AB >> =3D=3D=3D=3D=3D=3D=3D >> >> On 8/1/12, C Chauvenet wrote: >>> Hi, >>> >>> This is an interesting discussion. >>> >>> My understanding is that both MANET and ROLL considers lossy/dynamic >>> links >>> in the way described in the MANET charter : "static and dynamic >>> topologies >>> with increased dynamics due to node motion or other factors." I also >>> agree >>> that dynamicity of links is not hard wired to node mobility. >>> >>> So, in the LLN Vs MANET debate, I think they share the "N" for Networks= , >>> and >>> the 2nd "L" for Lossy. >>> So the remaining point is the first L, meaning Low Power. >>> >>> Low Power requirements is explicit in the ROLL charter and not mentione= d >>> at >>> all in the MANET charter. >>> Is the power efficiency consideration the big difference between ROLL >>> and >>> MANET ? >>> >>> C=E9dric. >>> >>> -----Message d'origine----- >>> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de >>> Abdussalam Baryun >>> Envoy=E9 : mercredi 1 ao=FBt 2012 09:22 >>> =C0 : Henning Rogge >>> Cc : roll; manet >>> Objet : [Roll] Some LLNs are NOT MANETs >>> >>> Hi Henning, >>> >>> I am about to say many LLNs are NOT MANETs but it seems like the market >>> or >>> community will decide the outcome, but surly that some LLNs are NOT >>> MANETs. >>> >>>> Could you state an example what would be considered a LLN but not a >>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>> >>> I not totally agree with that, because we need to be considering both >>> NETs >>> use case and applicability in the vision of the different WGs (MANET an= d >>> ROLL). There are many examples we can find them in the [RFC2501] for >>> MANETs >>> characteristics and applicability, and for LLNs characteristics in >>> [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs >>> requirements. That is why I suggested before that >>> OLSRv2 and AODVv2 should mention their applicability to LLN if they do. >>> They >>> just refer to RFC2501, but RFC2501 is OLD and does not mention LLN but >>> describes the meaning. The authors of RFC2501 still not responded to my >>> update suggestions. >>> >>> I understood from one discussion in MANET WG that few don't have time t= o >>> read many pages of documents, so that is why I suggested to have >>> terminology >>> I-D [1] as we have ROLL terminology [ROLL] . I also taken initiative to >>> make >>> new draft of MANET subnet technologies which include only related LLNs >>> [AB2]. >>> >>> Therefore, I will add the definition for MANET and LLN into my >>> manet-terminology draft [AB1] (propose that authors of [ROLL] define LL= N >>> more details) to assist discussions as it is proved now in the list tha= t >>> there still is problems in definitions in MANET WG or in some I-D >>> editorial >>> content. >>> >>> [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >>> [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >>> [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt >>> >>> Best Wishes >>> >>> Abdussalam Baryun >>> University of Glamorgan, UK >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>> On 7/31/12, Henning Rogge wrote: >>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>>> subject: Re: [manet] Discussing LOADng suggestions >>>> wrote: >>>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, but >>>>> then changed its direction to MANET [3]. However, please note that >>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >>>>> said, LOADng SHOULD specfy where is its limits. Then we can discuss >>>>> adoption. >>>> >>>> Could you state an example what would be considered a LLN but not a >>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>> >>>> Henning Rogge >>>> >>>> -- >>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>> billions of percent in a tiny fraction of a second. Of course, that >>>> was before the present government." >>>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >>> >>> >> > > > From Chris.Dearlove@baesystems.com Wed Aug 1 08:26:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD3E21F8999 for ; Wed, 1 Aug 2012 08:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.97 X-Spam-Level: X-Spam-Status: No, score=-9.97 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poj5bgJvltDR for ; Wed, 1 Aug 2012 08:26:30 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8306821F8998 for ; Wed, 1 Aug 2012 08:26:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,694,1336345200"; d="scan'208";a="260606946" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 01 Aug 2012 16:26:28 +0100 Received: from GLKXH0004V.GREENLNK.net ([10.109.2.35]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q71FQRSL011570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 16:26:27 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.170]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0309.002; Wed, 1 Aug 2012 16:26:27 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , C Chauvenet Thread-Topic: [manet] Some LLNs are NOT MANETs Thread-Index: AQHNb+izbH1tyYFgl06MELNnv/B9tZdFE3cg Date: Wed, 1 Aug 2012 15:26:27 +0000 Message-ID: References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 15:26:32 -0000 The statement that MANETs refers only to networks with physical mobility is= simply false. While the expansion of the acronym might suggest that, in fa= ct MANET has become a term of art, and that art includes many networks with= some or all nodes that are not physically moving. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= bdussalam Baryun Sent: 01 August 2012 14:21 To: C Chauvenet Cc: manet Subject: Re: [manet] Some LLNs are NOT MANETs ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi C=E9dric, Ok we can discuss efficiently when we read the documents (production of such WG)as you agreed. > When you say "IMHO, as long we have a ROLL WG in IETF we need to forward > work to it which has no mobility behavior", do you mean that the differen= ce > between ROLL and MANET is limited to mobility considerations ? *Mobility* It is the mostly difference clearly spoted between the documents produced by the both WGs, also the name MANET starts with Mobile, the word mobile is not equal to change/dynamic. So MANET refers to mobile node or mobile network, which means location change *NOT* topology change/dynamic. In the old days there was no ROLL WG so MANET WG was doing the job. > > Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC5867 > all include the usual IoT constraints : Memory, Processing, Power, Batter= y, > Cost and Size of device. > RFC5673 does not mention explicitly processing and size constraints, but > mention all the others. > Ok, > RFC 2501 speak about energy and power, as you previously mentioned, but d= oes > not say something on the following constraints : Memory, Processing, Cos= t > and Size. Yes your right, but be careful RFC2501 does not exclude thoes constraints either. However, if the MANET network has some nodes with constraints but clearly mobility is the main constraint. > > Do you think that these constraints are in the MANET scope ? > I guess that they may be (obviously for Cost), but not in the same order = of > magnitude as the type of devices described in the requirements RFC of ROL= L. Really don't mind either way for MANET WG, and will think that the WG community wants it in between In-Scope and Out-Scope, that may be strange but seems that is what is happening as I read documents. Out of IETF, MANET is mostly understood as mobile nodes connecting, not LLNs. Overall, IMHO, in the end it is the decision of the IETF community to decide of any new idea or any I-D acceptance/adoption, but for the WG it MAY take over a WORK as an IETF I-D, but it may not be successful to convince the IETF community to continue the work or make it become a RFC, we always have to see through to make the work efforts flow successfully. We do not forget that many participants work in both WGs. Regards Abdussalam =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D On 8/1/12, C Chauvenet wrote: > Hi, > > Thank you for your answer, > > See inline. > > Le 1 ao=FBt 2012 =E0 13:41, Abdussalam Baryun a =E9crit : > >> Hi C=E9dric, >> >> I think the RFC2501 is more important than the WG charter, because the >> charter MAY change but RFCs never changes (only can be updated, >> obsoleted or replaced). > > Good Point, 100% agree. > >> So far now all MANET-protocols are refering to >> RFC2501 which is good and SHOULD continue, and I like this referencing >> to documents (even if they are old or expired) not referencing to >> charters, because for example, if in a journal paper we reference to >> the charter of MANET WG or ROLL WG the information is not solid like >> if you reference a published document (publisher date), but still we >> can reference the charter as web reference sited date. >> >> I read some paper that reference sited web documents but they may be >> not valid and cannot be read for some reason. Therefore, IMHO, we need >> to stick to the following document to make a right decision in >> definitions: >> >> 1) [RFC2501] for MANETs. (published in 1999) >> 2) [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] for LLNs. >> (published in 2009) > > I think they are good references to build some arguments into this > discussion. > >> >> Low power was indicated in RFC2501 in section 5.1 as > constraints> and also the word *sink*, in page 7 you read > for energy conservation>. IMHO, as long we have a ROLL WG in IETF we >> need to forward work to it which has no mobility behavior. Delegation >> will help make work flowing and more focused. > > When you say "IMHO, as long we have a ROLL WG in IETF we need to forward > work to it which has no mobility behavior", do you mean that the differen= ce > between ROLL and MANET is limited to mobility considerations ? > > Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC5867 > all include the usual IoT constraints : Memory, Processing, Power, Batter= y, > Cost and Size of device. > RFC5673 does not mention explicitly processing and size constraints, but > mention all the others. > > RFC 2501 speak about energy and power, as you previously mentioned, but d= oes > not say something on the following constraints : Memory, Processing, Cos= t > and Size. > > Do you think that these constraints are in the MANET scope ? > I guess that they may be (obviously for Cost), but not in the same order = of > magnitude as the type of devices described in the requirements RFC of ROL= L. > > Regards, > > C=E9dric. > >> >> Regards >> AB >> =3D=3D=3D=3D=3D=3D=3D >> >> On 8/1/12, C Chauvenet wrote: >>> Hi, >>> >>> This is an interesting discussion. >>> >>> My understanding is that both MANET and ROLL considers lossy/dynamic >>> links >>> in the way described in the MANET charter : "static and dynamic >>> topologies >>> with increased dynamics due to node motion or other factors." I also >>> agree >>> that dynamicity of links is not hard wired to node mobility. >>> >>> So, in the LLN Vs MANET debate, I think they share the "N" for Networks= , >>> and >>> the 2nd "L" for Lossy. >>> So the remaining point is the first L, meaning Low Power. >>> >>> Low Power requirements is explicit in the ROLL charter and not mentione= d >>> at >>> all in the MANET charter. >>> Is the power efficiency consideration the big difference between ROLL >>> and >>> MANET ? >>> >>> C=E9dric. >>> >>> -----Message d'origine----- >>> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de >>> Abdussalam Baryun >>> Envoy=E9 : mercredi 1 ao=FBt 2012 09:22 >>> =C0 : Henning Rogge >>> Cc : roll; manet >>> Objet : [Roll] Some LLNs are NOT MANETs >>> >>> Hi Henning, >>> >>> I am about to say many LLNs are NOT MANETs but it seems like the market >>> or >>> community will decide the outcome, but surly that some LLNs are NOT >>> MANETs. >>> >>>> Could you state an example what would be considered a LLN but not a >>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>> >>> I not totally agree with that, because we need to be considering both >>> NETs >>> use case and applicability in the vision of the different WGs (MANET an= d >>> ROLL). There are many examples we can find them in the [RFC2501] for >>> MANETs >>> characteristics and applicability, and for LLNs characteristics in >>> [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs >>> requirements. That is why I suggested before that >>> OLSRv2 and AODVv2 should mention their applicability to LLN if they do. >>> They >>> just refer to RFC2501, but RFC2501 is OLD and does not mention LLN but >>> describes the meaning. The authors of RFC2501 still not responded to my >>> update suggestions. >>> >>> I understood from one discussion in MANET WG that few don't have time t= o >>> read many pages of documents, so that is why I suggested to have >>> terminology >>> I-D [1] as we have ROLL terminology [ROLL] . I also taken initiative to >>> make >>> new draft of MANET subnet technologies which include only related LLNs >>> [AB2]. >>> >>> Therefore, I will add the definition for MANET and LLN into my >>> manet-terminology draft [AB1] (propose that authors of [ROLL] define LL= N >>> more details) to assist discussions as it is proved now in the list tha= t >>> there still is problems in definitions in MANET WG or in some I-D >>> editorial >>> content. >>> >>> [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >>> [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >>> [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt >>> >>> Best Wishes >>> >>> Abdussalam Baryun >>> University of Glamorgan, UK >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>> On 7/31/12, Henning Rogge wrote: >>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>>> subject: Re: [manet] Discussing LOADng suggestions >>>> wrote: >>>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, but >>>>> then changed its direction to MANET [3]. However, please note that >>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >>>>> said, LOADng SHOULD specfy where is its limits. Then we can discuss >>>>> adoption. >>>> >>>> Could you state an example what would be considered a LLN but not a >>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>> >>>> Henning Rogge >>>> >>>> -- >>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>> billions of percent in a tiny fraction of a second. Of course, that >>>> was before the present government." >>>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >>> >>> >> > > > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Wed Aug 1 09:10:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E9211E8113 for ; Wed, 1 Aug 2012 09:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.271 X-Spam-Level: X-Spam-Status: No, score=-10.271 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMoIVUCIip46 for ; Wed, 1 Aug 2012 09:10:10 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id EDE8F21F8848 for ; Wed, 1 Aug 2012 09:10:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,694,1336345200"; d="scan'208,217";a="260618085" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 01 Aug 2012 17:10:06 +0100 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q71GA5aK007549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 17:10:05 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.170]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Wed, 1 Aug 2012 17:10:05 +0100 From: "Dearlove, Christopher (UK)" To: Rick Taylor , Teco Boot , Ulrich Herberg Thread-Topic: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt Thread-Index: Ac1u4dXpMWs8L8nJvUmskMYRmizNvgAH5zWQAD7gfjA= Date: Wed, 1 Aug 2012 16:10:01 +0000 Message-ID: References: <84F14E53-CA1A-4ED7-B2BF-810516A78069@thomasclausen.org> <7B31B0093014224A843C10C0CCE92AC1047A1177@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1047A1177@SUKNPT8106.cogent-dsn.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24EB4D88GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: manet , Thomas Heide Clausen Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 16:10:15 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24EB4D88GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think this is probably the right thing to do, there are sufficient overla= ps in how the security model suggested in 5444 and detailed in 6622 might b= e applied to different MANET protocols (NHDP, OLSRv2, SMF, potentially DYMO= /AODVv2) that some common advice is I think appropriate. In particular note= that 6622 is a functional document, not a rationale for use. In particular this could consider the different characteristics of packet/m= essage signatures/encryption and that there may be a place for either, or e= ven both. There may be issues as to what extent to keep it abstract, and to= what extent to give specific examples, but that's what the usual discussio= n process is for. To do a good job, this would need to consider some broade= r issues. For example with a single shared secret key, is there any gain in= message over packet signatures? With separate keying (but what are the sca= lability issues? - some approaches are better than others) message signatur= es are probably better, but still not without possible flaws. While 6622 r= etains the option to use quite differently key managed signature methods (i= n particular) neither packet nor message signature are the definitively rig= ht answer. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Rick Taylor [mailto:Rick.Taylor@Cassidian.com] Sent: 31 July 2012 10:49 To: Teco Boot; Ulrich Herberg Cc: Dearlove, Christopher (UK); manet; Thomas Heide Clausen Subject: RE: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. For those of us who missed the relevant parts of the mailing discussion, wh= at was the consensus on general ICV verification for RFC5444 packets? I am with Teco, a separate manet-rfc5444-sec document would be very useful. Rick Taylor ________________________________ From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of T= eco Boot Sent: 31 July 2012 07:00 To: Ulrich Herberg Cc: Dearlove, Christopher (UK); manet; Thomas Heide Clausen Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt I provided feedback to authors before: I strongly prefer having a document = on MANET packet security before we go into further details, such as manet-n= hdp-sec. Another concern is that NHDP messages are extended by other protoc= ols. Teco Op 13 jul. 2012, om 18:55 heeft Ulrich Herberg het volgende geschreven: Chris, On Fri, Jul 13, 2012 at 5:52 AM, Dearlove, Christopher (UK) > wrote: This partly depends on what your planned document structure is, Ulrich just= mentioned the possibility of a generic 5444 document. I'm actually not sur= e that wouldn't be more relevant, as it is hard to actually separate these = things. My concern is, if you want to specify packet signing in the NHDP-sec docume= nt, that NHDP itself would never see the packet. The RFC5444 multiplexing w= ould see a HELLO message in the packet and send it to NHDP (which can use t= he mechanisms specified in NHDP-sec to reject or accept the message). I thi= nk that a packet signer/verifier is tied to the RFC5444 parser itself, whic= h would accept or reject the whole packet. So in my view, it would actually= be much easier to separate it into an additional draft, rather than combin= ing it with NHDP. Moreover, protocols that do not use NHDP but use RFC5444 would probably lik= e to use packet ICV verification as well, but they don't need all the NHDP = part. But I think this is jumping in with solutions before considering a threat m= odel. Let's suppose that we have hardware that (a) stores key materials in = secure tamperproof storage, (b) doesn't make mistakes, and (c) we use a si= gnature method that's cryptographically infeasible to break. Then in this c= ase (not uniquely) packet signatures actually provide as much security as m= essage signatures. If you assume a transitive trust model. If a router receives a TC message (= unsigned) in a correctly signed packet, the receiving router can be sure th= at the TC has not been modified after transmission by the previous hop. It = has no information what happened before that. But I agree that for certain = deployments that may be enough. Of course I can also think of threat models that do favour message signatur= es. But this is exactly like the choice of signature methods, which is not = mandated because different threats require different solutions. Right. I am absolutely in favor of specifying packet ICV handling. The only= question for me is where to do that. The same is true of packet and message signatures. Each (and indeed the thi= rd option of both) should be allowed, we should not have a document that pr= efers one above the other Correct. except following a security analysis - which is not on offer. Yes. There was some emails about the nhdp-sec-threats document by Jiazi sev= eral months ago, but there was not much activity on the mailing list.. Do y= ou think that that document should contain such an analysis? Best regards Ulrich -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] Sent: 13 July 2012 13:36 To: Dearlove, Christopher (UK) Cc: Ulrich Herberg; manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Chris, I figured that you wouldn't agree. I agree, of course, with your observation that none of the signature models= yields end-to-end security, but I don't think that that's the issue here. Personally, I do not see packet ICVs as being appropriate for neither NHDP = nor OLSRv2 - at least, not for the uses that I see/have, but I am not sayin= g that they do not exist. I could make an argument that a packet ICV would = have to be validated before knowing that a HELLO message was delivered to a= n NHDP instance, and that the validation might be based on different princi= ples (or, even layers) for packet/messages. I see what you say about protecting packet sequence numbers by way of a pac= ket-level ICV, but I would argue that: o As packet sequence numbers are generated "outside" N= HDP, and are incremented for all packets (not just those with HELLOs), specifying th= e validation of a packet-level ICV in NHDP would be inappropriate (as in: potentially conflicting wi= th another mechanism) o Whatever mechanism would provide "packet sequence nu= mber statistics" to NHDP (such as the demultiplexer) would want to be the entity doing th= at packet-level ICV validation, in part as I would _suspect_ that inability to validate a pack= et-level ICV should cause the whole packet with all contained messages to be dropped. That said, with reference to the I-D, I think I speak for the authors when = saying that we're welcoming a suggestion that would address the issue that = you raise? Best, Thomas On Jul 13, 2012, at 14:18 , Dearlove, Christopher (UK) wrote: I don't agree. Note that if all you are running is NHDP, then signing packe= ts is more secure than signing messages, as you get to cover the packet seq= uence number as well. What I think is wrong is to suggest that the only correct way to protect NH= DP is to sign HELLO messages. Whether by inclusion or external reference, s= igning packets should be also an option. I'll take that further to OLSrv2 as well. Now there signing messages vs sig= ning packets has advantages to the former. But signing packets also has adv= antages of simplicity and covering packet header. It is incidentally not co= rrect to say that signing TC messages provides end to end security. It's ac= tually last-bit-one-from-end to end, and still relies on a form of transiti= ve trust. Packet based signatures rely on a greater degree of transitive tr= ust. There is a difference in threat models and vulnerabilities, and that m= ay matter, but it's not (unfortunately) as simple as one being end to end a= nd thus avoiding transitivity issues. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] Sent: 12 July 2012 23:09 To: Ulrich Herberg Cc: Dearlove, Christopher (UK); manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. I agree with Ulrich. Note that this is all about "messages" in as much as NHDP is concerned. 1) NHDP specifies something akin to "an implementation may recognize additi= onal reasons for considering a HELLO message invalid for processing"; this = I-D specifies such an additional reason, by way of a TLV in HELLO messages. 2) NHDP "owns" HELLO messages, and therefore gets first dip on an incoming = HELLO message post-demultiplication. Including the ICV Message TLV in HELLO= messages therefore makes sense. Ad 1), I note that this I-D is intended to exactly plug in at that place in= 6130. Thomas -- Thomas Heide Clausen http://www.thomasclausen.org/ "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees On 12 Jul 2012, at 22:54, Ulrich Herberg > wrote: The document specifies signing/verifying NHDP messages. RFC5444 packets are= not specific to NHDP, and therefore should IMO not be discussed in a docum= ent entitled "Using Integrity Check Values and Timestamps For Router Admitt= ance in NHDP". That's why I suggested to handle this in an additional docum= ent for RFC5444 packets. Regards Ulrich On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun > wrote: Hi Ulrich, I am not expert in security issues, but IMHO, I agree with Chris to recommend to include in draft-02 both securing messages and packets (in general for packets), so the document should specify NHDP messages and MANET packets [AB]. The reasons are first, because NHDP is a MANET Interface protocol between neighbor routers. secondly it uses RFC5444 format that the future MANET routers will use. Third, NHDP uses RFC5444 which was specified for information exchange between MANET routers. [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt Regards Abdussalam =3D=3D=3D=3D=3D=3D=3D On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg > wrote: > Dear Chris, > > I agree that we need to provide similar mechanisms as in NHDP-sec for TC > messages as well. I don't think that signing the packet is enough, since > that does not provide end-to-end security. Instead, I suggest to submit a > draft OLSRv2-sec that specifies how to calculate ICVs for TC messages, an= d > how to handle these messages in OLSRv2. > > However, I believe that it would be beneficial for certain applications t= o > also be able to sign/verify packets. But I don't think that the NHDP-sec > document is the right place for this, since other applications (e.g. DYMO= ) > may not use HELLO messages at all, but would still like to sign/verify > packets. > Maybe it would be better to have an extra document "packet-sec" which > specifies how to sign/verify packets? > > Best > Ulrich > > > On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK) > > wrote: >> >> (Sending again, to sort out the formatting problem with the last attempt= .) >> >> As I read it, this draft is proposing using the RFC 6622 mechanism to si= gn >> HELLO messages. RFC 6622 actually allows for signing packets as well as >> signing messages (both, either, or neither to be used as required). Ther= e >> isn't a major difference when considering HELLO messages, as few if any >> packets will contain more than one HELLO message, and the packet and the >> message will be signed by the same party. >> >> However NHDP doesn't exist in a vacuum, in particular it is used by >> OLSRv2. Any security mechanism that is described in what will be an RFC = for >> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 also h= as >> TC messages to consider, and they don't satisfy the points noted above (= on >> number or on who signs them). And one option for OLSRv2 is to sign all >> packets, not messages. This can be a sensible decision there, for severa= l >> reasons, in some real circumstances. >> >> Consequently, I don't believe that this draft should describe only signi= ng >> HELLO messages as the correct thing to do, that it should also allow sig= ning >> packets as an equal status option. If someone wants to raise the possibi= lity >> of signing (possibly by methods with different properties) both at the >> message and packet level, that may have its use cases too. >> >> Incidentally, even within the limited framework of just NHDP, it is >> possible that packets need protection. If an NHDP implementation chooses= to >> use packet sequence number as part of its link quality mechanism, as it = may, >> then an unprotected packet header is a vulnerability. >> >> (For the sake of completeness, RFC 6622 also allows address block >> signatures. I don't have a reason to suggest using this within NHDP or >> OLSRv2.) >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124<= tel:%2B44%201245%20242124> >> chris.dearlove at baesystems.com | http://www.ba= esystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, >> Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Mobile Ad-hoc Networks Wor= king >> Group of the IETF. >> >> Title : Using Integrity Check Values and Timestamps Fo= r >> Router Admittance in NHDP >> Author(s) : Ulrich Herberg >> Thomas Heide Clausen >> Filename : draft-ietf-manet-nhdp-sec-02.txt >> Pages : 12 >> Date : 2012-05-29 >> >> This document specifies a security extension to the MANET >> Neighborhood Discovery Protocol (NHDP). The extension introduces the >> use of Integrity Check Values (ICVs) and Timestamps in HELLO messages >> in order to provide a router admittance mechanism, and therefore to >> counter a selection of security threats to NHDP. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-02.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-02.txt >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/ >> >> _______________________________________________ >> manet mailing list >> manet at ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24EB4D88GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think this is probably = the right thing to do, there are sufficient overlaps in how the security mo= del suggested in 5444 and detailed in 6622 might be applied to different MANET protocols (NHDP, OLSRv2, SMF, potentially DYMO/AODVv2) = that some common advice is I think appropriate. In particular note that 662= 2 is a functional document, not a rationale for use.

 <= /p>

In particular this could = consider the different characteristics of packet/message signatures/encrypt= ion and that there may be a place for either, or even both. There may be issues as to what extent to keep it abstract, and to what ext= ent to give specific examples, but that's what the usual discussion process= is for. To do a good job, this would need to consider some broader issues.= For example with a single shared secret key, is there any gain in message over packet signatures? With sepa= rate keying (but what are the scalability issues? - some approaches are bet= ter than others) message signatures are probably  better, but still no= t without possible flaws. While 6622 retains the option to use quite differently key managed signature methods = (in particular) neither packet nor message signature are the definitively r= ight answer.

 <= /p>

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (O= perations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 <= /p>

From: Rick Taylor [mailto:Rick.Taylor@Cassidian.com]
Sent: 31 July 2012 10:49
To: Teco Boot; Ulrich Herberg
Cc: Dearlove, Christopher (UK); manet; Thomas Heide Clausen
Subject: RE: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

For those of us who missed the= relevant parts of the mailing discussion, what was the consensus on genera= l ICV verification for RFC5444 packets?

 

I am with Teco, a separate man= et-rfc5444-sec document would be very useful.

 

Rick Taylor

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org= ] On Behalf Of Teco Boot
Sent: 31 July 2012 07:00
To: Ulrich Herberg
Cc: Dearlove, Christopher (UK); manet; Thomas Heide Clausen
Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt

 

I provided feedback to authors before: I strongly pr= efer having a document on MANET packet security before we go into further d= etails, such as manet-nhdp-sec. Another concern is that NHDP messages = are extended by other protocols.

 

Teco

 

 

Op 13 jul. 2012, om 18:55 heeft Ulrich Herberg het v= olgende geschreven:

 

Chris,

On Fri, Jul 13, 2012 at 5:52 AM, Dearlove, Christoph= er (UK) <Chris.Dearlove@baesystems.com> wrote:

This partly depends on what your planne= d document structure is, Ulrich just mentioned the possibility of a generic 5444 document. I'm actually not sure that wouldn't be more re= levant, as it is hard to actually separate these things.<= /p>


My concern is, if you want to specify packet signing in the NHDP-sec docume= nt, that NHDP itself would never see the packet. The RFC5444 multiplexing w= ould see a HELLO message in the packet and send it to NHDP (which can use t= he mechanisms specified in NHDP-sec to reject or accept the message). I think that a packet signer/verifier is= tied to the RFC5444 parser itself, which would accept or reject the whole = packet. So in my view, it would actually be much easier to separate it into= an additional draft, rather than combining it with NHDP.
Moreover, protocols that do not use NHDP but use RFC5444 would probably lik= e to use packet ICV verification as well, but they don't need all the NHDP = part.

 

 

But I think this is jumping in with sol= utions before considering a threat model. Let's suppose that we have hardware that (a) stores key materials in secure tamperproof stora= ge,  (b) doesn't make mistakes, and (c) we use a signature method that= 's cryptographically infeasible to break. Then in this case (not uniquely) = packet signatures actually provide as much security as message signatures.


If you assume a transitive trust model. If a router receives a TC message (= unsigned) in a correctly signed packet, the receiving router can be sure th= at the TC has not been modified after transmission by the previous hop. It = has no information what happened before that. But I agree that for certain deployments that may be enough.<= br>  

Of course I can also think of threat mo= dels that do favour message signatures. But this is exactly like the choice of signature methods, which is not mandated because differ= ent threats require different solutions.


Right. I am absolutely in favor of specifying packet ICV handling. The only= question for me is where to do that.
 

The same is true of packet and message = signatures. Each (and indeed the third option of both) should be allowed, we should not have a document that prefers one above the other=


Correct.
 

except following a security analysis - = which is not on offer.


Yes. There was some emails about the nhdp-sec-threats document by Jiazi sev= eral months ago, but there was not much activity on the mailing list.. Do y= ou think that that document should contain such an analysis?

Best regards
Ulrich
 

 

--

Christopher Dearlove<= /p>

Senior Principal Engineer, Communicatio= ns Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 2= 42194 |  Fax: +44 1245 242124=

chris.dearlove@baesystems.com | http://www.baes= ystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]
Sent: 13 July 2012 13:36
To: Dearlove, Christopher (UK)
Cc: Ulrich Herberg; manet


Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt

 

 

 =

*** WARNING ***

This message originates from outside our organi= sation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

Chris,

 

I figured that you wouldn't agree.

 

I agree, of course, with your observation that none of the signatu= re models yields end-to-end security, but I don't think that that's the iss= ue here. 

 

Personally, I do not see packet ICVs as being appropriate for neit= her NHDP nor OLSRv2 - at least, not for the uses that I see/have, but I am = not saying that they do not exist. I could make an argument that a packet ICV would have to be validated before= knowing that a HELLO message was delivered to an NHDP instance, and that t= he validation might be based on different principles (or, even layers) for = packet/messages. 

 

I see what you say about protecting packet sequence numbers by way= of a packet-level ICV, but I would argue that:

 

           = o          As packet sequence= numbers are generated "outside" NHDP, and are incremented for al= l 

           =              pa= ckets (not just those with HELLOs), specifying the validation of a packet-l= evel ICV in NHDP would

           =              be= inappropriate (as in: potentially conflicting with another mechanism)=

 

           = o          Whatever mechanism= would provide "packet sequence number statistics" to NHDP (such = as the

           =              de= multiplexer) would want to be the entity doing that packet-level ICV valida= tion, in part as

           =              I = would _suspect_ that inability to validate a packet-level ICV should cause = the whole packet

           =              wi= th all contained messages to be dropped.

 

That said, with reference to the I-D, I think I speak for the auth= ors when saying that we're welcoming a suggestion that would address the is= sue that you raise?

 

Best,

 

Thomas

 

On Jul 13, 2012, at 14:18 , Dearlove, Christopher (UK) wrote:=

 

I don't agree. Note that if all you are= running is NHDP, then signing packets is more secure than signing messages, as you get to cover the packet sequence number as well.<= /span>

What I think is wrong is to suggest tha= t the only correct way to protect NHDP is to sign HELLO messages. Whether by inclusion or external reference, signing packets should be also= an option.

 

I'll take that further to OLSrv2 as wel= l. Now there signing messages vs signing packets has advantages to the former. But signing packets also has advantages of simplicity and c= overing packet header. It is incidentally not correct to say that signing T= C messages provides end to end security. It's actually last-bit-one-from-en= d to end, and still relies on a form of transitive trust. Packet based signatures rely on a greater degree= of transitive trust. There is a difference in threat models and vulnerabil= ities, and that may matter, but it's not (unfortunately) as simple as one b= eing end to end and thus avoiding transitivity issues.

 

--

Christopher Dearlove<= /p>

Senior Principal Engineer, Communicatio= ns Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 2= 42194 |  Fax: +44 1245 242124=

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] 
Sent: 12 July 2012 23:09
To: Ulrich Herberg
Cc: Dearlove, Christopher (UK); manet
Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.t= xt

 

 =

*** WARNING ***

This message originates from outside our organi= sation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

I agree with Ulrich. 

 

Note that this is all about "messages" in as much as NHD= P is concerned.

 

1) NHDP specifies something akin to "an implementation may re= cognize additional reasons for considering a HELLO message invalid for proc= essing"; this I-D specifies such an additional reason, by way of a TLV in HELLO messages.

 

2) NHDP "owns" HELLO messages, and therefore gets first = dip on an incoming HELLO message post-demultiplication. Including the ICV M= essage TLV in HELLO messages therefore makes sense.

 

Ad 1), I note that this I-D is intended to exactly plug in at that= place in 6130.

 

Thomas

 

-- 

Thomas Heide Clausen

 

"Any simple problem can be made insoluble if enough meetings = are held to

 discuss it."

   -- Mitchell's Law of Committees

 


On 12 Jul 2012, at 22:54, Ulrich Herberg <ulrich@herberg.name> wrote:

The document specifies signing/verifying NHDP messages. RFC5444 packets = are not specific to NHDP, and therefore should IMO not be discussed in a do= cument entitled "Using Integrity Check Values and Timestamps For Router Admittance in NHDP". That's why I su= ggested to handle this in an additional document for RFC5444 packets.

Regards
Ulrich

On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun <abdussalambaryun@gmail= .com> wrote:

Hi Ulrich,

I am not expert in security issues, but IMHO, I agree with Chris to
recommend to include in draft-02 both securing messages and packets
(in general for packets), so the document should specify NHDP messages
and MANET packets [AB]. The reasons are first, because NHDP is a MANET
Interface protocol between neighbor routers. secondly it uses RFC5444
format that the future MANET routers will use. Third, NHDP uses
RFC5444 which was specified for information exchange between MANET
routers.

[AB] http://tools.ietf.org/id/draft-baryun-manet-ter= minology-00.txt

Regards
Abdussalam
=3D=3D=3D=3D=3D=3D=3D


On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg <ulrich at herberg.name> wrote:
> Dear Chris,
>
> I agree that we need to provide similar mechanisms as in NHDP-sec for = TC
> messages as well. I don't think that signing the packet is enough, sin= ce
> that does not provide end-to-end security. Instead, I suggest to submi= t a
> draft OLSRv2-sec that specifies how to calculate ICVs for TC messages,= and
> how to handle these messages in OLSRv2.
>
> However, I believe that it would be beneficial for certain application= s to
> also be able to sign/verify packets. But I don't think that the NHDP-s= ec
> document is the right place for this, since other applications (e.g. D= YMO)
> may not use HELLO messages at all, but would still like to sign/verify=
> packets.
> Maybe it would be better to have an extra document "packet-sec&qu= ot; which
> specifies how to sign/verify packets?
>
> Best
> Ulrich
>
>
> On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK)=

> <Chris.Dearlove at baesystems.com> wrote:
>>
>> (Sending again, to sort out the formatting problem with the last a= ttempt.)
>>
>> As I read it, this draft is proposing using the RFC 6622 mechanism= to sign
>> HELLO messages. RFC 6622 actually allows for signing packets as we= ll as
>> signing messages (both, either, or neither to be used as required)= . There
>> isn't a major difference when considering HELLO messages, as few i= f any
>> packets will contain more than one HELLO message, and the packet a= nd the
>> message will be signed by the same party.
>>
>> However NHDP doesn't exist in a vacuum, in particular it is used b= y
>> OLSRv2. Any security mechanism that is described in what will be a= n RFC for
>> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 = also has
>> TC messages to consider, and they don't satisfy the points noted a= bove (on
>> number or on who signs them). And one option for OLSRv2 is to sign= all
>> packets, not messages. This can be a sensible decision there, for = several
>> reasons, in some real circumstances.
>>
>> Consequently, I don't believe that this draft should describe only= signing
>> HELLO messages as the correct thing to do, that it should also all= ow signing
>> packets as an equal status option. If someone wants to raise the p= ossibility
>> of signing (possibly by methods with different properties) both at= the
>> message and packet level, that may have its use cases too.
>>
>> Incidentally, even within the limited framework of just NHDP, it i= s
>> possible that packets need protection. If an NHDP implementation c= hooses to
>> use packet sequence number as part of its link quality mechanism, = as it may,
>> then an unprotected packet header is a vulnerability.
>>
>> (For the sake of completeness, RFC 6622 also allows address block<= br> >> signatures. I don't have a reason to suggest using this within NHD= P or
>> OLSRv2.)
>>
>> --
>> Christopher Dearlove
>> Senior Principal Engineer, Communications Group
>> Communications, Networks and Image Analysis Capability
>> BAE Systems Advanced Technology Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>> Tel: += 44 1245 242194 |  Fax: +44 1245 242124=

>> chris.dearlove at baesystems.com | http://www.baesystems.com

>>
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace= Centre,
>> Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts=
>> directories. This draft is a work item of the Mobile Ad-hoc Networ= ks Working
>> Group of the IETF.
>>
>>         Title         &nbs= p; : Using Integrity Check Values and Timestamps For
>> Router Admittance in NHDP
>>         Author(s)       : Ulric= h Herberg
>>                   &nb= sp;       Thomas Heide Clausen
>>         Filename        : = draft-ietf-manet-nhdp-sec-02.txt
>>         Pages         &nbs= p; : 12
>>         Date          = ;  : 2012-05-29
>>
>>    This document specifies a security extension to the M= ANET
>>    Neighborhood Discovery Protocol (NHDP).  The ext= ension introduces the
>>    use of Integrity Check Values (ICVs) and Timestamps i= n HELLO messages
>>    in order to provide a router admittance mechanism, an= d therefore to
>>    counter a selection of security threats to NHDP.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/d= raft-ietf-manet-nhdp-sec-02.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/dra= ft-ietf-manet-nhdp-sec-02.txt
>>
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-ma= net-nhdp-sec/
>>
>> _______________________________________________
>> manet mailing list

>> manet at ietf.org

>> https://www.ietf.org/mailman/listinfo/manet
>>
>>
>> ******************************************************************= **
>> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended<= br> >> recipient please delete it from your system and notify the sender.=
>> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person.
>> ******************************************************************= **
>>
>

 

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

 


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24EB4D88GLKXM0002VGREEN_-- From sratliff@cisco.com Wed Aug 1 09:22:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FBD11E8168 for ; Wed, 1 Aug 2012 09:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qW9DK16Tqci for ; Wed, 1 Aug 2012 09:22:34 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A533311E8165 for ; Wed, 1 Aug 2012 09:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=13384; q=dns/txt; s=iport; t=1343838154; x=1345047754; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zwrHkhGXamDYfhdbyECZLlKebS0WZqNsM/yarcsIVkg=; b=A4EKXAr7o/gfuCsh+NOQTH+B/XcqkBg355HZSfmmdrWHHnad4rK3CXcX NxixZlRqB1QYDnHUaMXHWR/2IpBGFBTYuzxuetTp1NTT3AtzbyNf9eBzL U+fHsDRohyAAVs6Uju3sfmEK37hFyG3f9edaz9a2Z8B1/tmiXAfzaFBgX Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHZXGVCtJV2Y/2dsb2JhbABFuRCBB4IgAQEBAwEBAQEPAUIWAwMIBQcEAgEIEQQBAQEnByEGCxQJCAIEDgUJCw6HXAMGBgucYpZxDYlOimJnBQUKBweGB2ADiBiLXIFTgRSJdoMdgWaCX4FWCQ X-IronPort-AV: E=Sophos;i="4.77,695,1336348800"; d="scan'208";a="107483478" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 01 Aug 2012 16:22:34 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q71GMXNA027390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 16:22:33 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.180]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 11:22:33 -0500 From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] Some LLNs are NOT MANETs Thread-Index: AQHNb+i2NIMVZDkBeEWaaQkwSTqYtJdFaAmAgAAPqoA= Date: Wed, 1 Aug 2012 16:22:33 +0000 Message-ID: References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.245.140] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.006 x-tm-as-result: No--57.162200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3223A2C4549B6F4DA834C4218A7B1AF7@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , Abdussalam Baryun Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 16:22:41 -0000 Precisely, Chris.=20 I've come to view MANETs more and more in the terms of an "opportunistic ne= twork". By that, I mean a network with a fairly large amount of dynamism, a= nd also a network that contains heterogeneity of links (e.g., different rad= io types, and/or some wired portions). The challenge of these networks is t= o opportunistically (and maximally) use the resources available to it at an= y point in time.=20 And at least for me (and I know this will draw some fire in return), anothe= r distinction in MANET as opposed to LLN is a greater requirement for peer-= to-peer (node-to-node) communication, From what I've seen of LLN deployment= s (and I'm no expert), they tend to have more of a "multiple source/single = sink" model for the data flow. Again, just one opinion.=20 Regards, Stan On Aug 1, 2012, at 11:26 AM, Dearlove, Christopher (UK) wrote: > The statement that MANETs refers only to networks with physical mobility = is simply false. While the expansion of the acronym might suggest that, in = fact MANET has become a term of art, and that art includes many networks wi= th some or all nodes that are not physically moving. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Abdussalam Baryun > Sent: 01 August 2012 14:21 > To: C Chauvenet > Cc: manet > Subject: Re: [manet] Some LLNs are NOT MANETs >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Hi C=E9dric, >=20 > Ok we can discuss efficiently when we read the documents (production > of such WG)as you agreed. >=20 >> When you say "IMHO, as long we have a ROLL WG in IETF we need to forward >> work to it which has no mobility behavior", do you mean that the differe= nce >> between ROLL and MANET is limited to mobility considerations ? >=20 > *Mobility* It is the mostly difference clearly spoted between the > documents produced by the both WGs, also the name MANET starts with > Mobile, the word mobile is not equal to change/dynamic. So MANET > refers to mobile node or mobile network, which means location change > *NOT* topology change/dynamic. In the old days there was no ROLL WG so > MANET WG was doing the job. >=20 >>=20 >> Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC586= 7 >> all include the usual IoT constraints : Memory, Processing, Power, Batte= ry, >> Cost and Size of device. >> RFC5673 does not mention explicitly processing and size constraints, but >> mention all the others. >>=20 >=20 > Ok, >=20 >> RFC 2501 speak about energy and power, as you previously mentioned, but = does >> not say something on the following constraints : Memory, Processing, Co= st >> and Size. >=20 > Yes your right, but be careful RFC2501 does not exclude thoes > constraints either. However, if the MANET network has some nodes with > constraints but clearly mobility is the main constraint. >=20 >>=20 >> Do you think that these constraints are in the MANET scope ? >> I guess that they may be (obviously for Cost), but not in the same order= of >> magnitude as the type of devices described in the requirements RFC of RO= LL. >=20 > Really don't mind either way for MANET WG, and will think that the WG > community wants it in between In-Scope and Out-Scope, that may be > strange but seems that is what is happening as I read documents. Out > of IETF, MANET is mostly understood as mobile nodes connecting, not > LLNs. >=20 > Overall, IMHO, in the end it is the decision of the IETF community to > decide of any new idea or any I-D acceptance/adoption, but for the WG > it MAY take over a WORK as an IETF I-D, but it may not be successful > to convince the IETF community to continue the work or make it become > a RFC, we always have to see through to make the work efforts flow > successfully. We do not forget that many participants work in both > WGs. >=20 > Regards > Abdussalam > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > On 8/1/12, C Chauvenet wrote: >> Hi, >>=20 >> Thank you for your answer, >>=20 >> See inline. >>=20 >> Le 1 ao=FBt 2012 =E0 13:41, Abdussalam Baryun a =E9crit : >>=20 >>> Hi C=E9dric, >>>=20 >>> I think the RFC2501 is more important than the WG charter, because the >>> charter MAY change but RFCs never changes (only can be updated, >>> obsoleted or replaced). >>=20 >> Good Point, 100% agree. >>=20 >>> So far now all MANET-protocols are refering to >>> RFC2501 which is good and SHOULD continue, and I like this referencing >>> to documents (even if they are old or expired) not referencing to >>> charters, because for example, if in a journal paper we reference to >>> the charter of MANET WG or ROLL WG the information is not solid like >>> if you reference a published document (publisher date), but still we >>> can reference the charter as web reference sited date. >>>=20 >>> I read some paper that reference sited web documents but they may be >>> not valid and cannot be read for some reason. Therefore, IMHO, we need >>> to stick to the following document to make a right decision in >>> definitions: >>>=20 >>> 1) [RFC2501] for MANETs. (published in 1999) >>> 2) [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] for LLNs. >>> (published in 2009) >>=20 >> I think they are good references to build some arguments into this >> discussion. >>=20 >>>=20 >>> Low power was indicated in RFC2501 in section 5.1 as >> constraints> and also the word *sink*, in page 7 you read >> for energy conservation>. IMHO, as long we have a ROLL WG in IETF we >>> need to forward work to it which has no mobility behavior. Delegation >>> will help make work flowing and more focused. >>=20 >> When you say "IMHO, as long we have a ROLL WG in IETF we need to forward >> work to it which has no mobility behavior", do you mean that the differe= nce >> between ROLL and MANET is limited to mobility considerations ? >>=20 >> Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC586= 7 >> all include the usual IoT constraints : Memory, Processing, Power, Batte= ry, >> Cost and Size of device. >> RFC5673 does not mention explicitly processing and size constraints, but >> mention all the others. >>=20 >> RFC 2501 speak about energy and power, as you previously mentioned, but = does >> not say something on the following constraints : Memory, Processing, Co= st >> and Size. >>=20 >> Do you think that these constraints are in the MANET scope ? >> I guess that they may be (obviously for Cost), but not in the same order= of >> magnitude as the type of devices described in the requirements RFC of RO= LL. >>=20 >> Regards, >>=20 >> C=E9dric. >>=20 >>>=20 >>> Regards >>> AB >>> =3D=3D=3D=3D=3D=3D=3D >>>=20 >>> On 8/1/12, C Chauvenet wrote: >>>> Hi, >>>>=20 >>>> This is an interesting discussion. >>>>=20 >>>> My understanding is that both MANET and ROLL considers lossy/dynamic >>>> links >>>> in the way described in the MANET charter : "static and dynamic >>>> topologies >>>> with increased dynamics due to node motion or other factors." I also >>>> agree >>>> that dynamicity of links is not hard wired to node mobility. >>>>=20 >>>> So, in the LLN Vs MANET debate, I think they share the "N" for Network= s, >>>> and >>>> the 2nd "L" for Lossy. >>>> So the remaining point is the first L, meaning Low Power. >>>>=20 >>>> Low Power requirements is explicit in the ROLL charter and not mention= ed >>>> at >>>> all in the MANET charter. >>>> Is the power efficiency consideration the big difference between ROLL >>>> and >>>> MANET ? >>>>=20 >>>> C=E9dric. >>>>=20 >>>> -----Message d'origine----- >>>> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part d= e >>>> Abdussalam Baryun >>>> Envoy=E9 : mercredi 1 ao=FBt 2012 09:22 >>>> =C0 : Henning Rogge >>>> Cc : roll; manet >>>> Objet : [Roll] Some LLNs are NOT MANETs >>>>=20 >>>> Hi Henning, >>>>=20 >>>> I am about to say many LLNs are NOT MANETs but it seems like the marke= t >>>> or >>>> community will decide the outcome, but surly that some LLNs are NOT >>>> MANETs. >>>>=20 >>>>> Could you state an example what would be considered a LLN but not a >>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>=20 >>>> I not totally agree with that, because we need to be considering both >>>> NETs >>>> use case and applicability in the vision of the different WGs (MANET a= nd >>>> ROLL). There are many examples we can find them in the [RFC2501] for >>>> MANETs >>>> characteristics and applicability, and for LLNs characteristics in >>>> [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs >>>> requirements. That is why I suggested before that >>>> OLSRv2 and AODVv2 should mention their applicability to LLN if they do= . >>>> They >>>> just refer to RFC2501, but RFC2501 is OLD and does not mention LLN but >>>> describes the meaning. The authors of RFC2501 still not responded to m= y >>>> update suggestions. >>>>=20 >>>> I understood from one discussion in MANET WG that few don't have time = to >>>> read many pages of documents, so that is why I suggested to have >>>> terminology >>>> I-D [1] as we have ROLL terminology [ROLL] . I also taken initiative t= o >>>> make >>>> new draft of MANET subnet technologies which include only related LLN= s >>>> [AB2]. >>>>=20 >>>> Therefore, I will add the definition for MANET and LLN into my >>>> manet-terminology draft [AB1] (propose that authors of [ROLL] define L= LN >>>> more details) to assist discussions as it is proved now in the list th= at >>>> there still is problems in definitions in MANET WG or in some I-D >>>> editorial >>>> content. >>>>=20 >>>> [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >>>> [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >>>> [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt >>>>=20 >>>> Best Wishes >>>>=20 >>>> Abdussalam Baryun >>>> University of Glamorgan, UK >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>> On 7/31/12, Henning Rogge wrote: >>>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>>>> subject: Re: [manet] Discussing LOADng suggestions >>>>> wrote: >>>>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, but >>>>>> then changed its direction to MANET [3]. However, please note that >>>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >>>>>> said, LOADng SHOULD specfy where is its limits. Then we can discuss >>>>>> adoption. >>>>>=20 >>>>> Could you state an example what would be considered a LLN but not a >>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>=20 >>>>> Henning Rogge >>>>>=20 >>>>> -- >>>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>>> billions of percent in a tiny fraction of a second. Of course, that >>>>> was before the present government." >>>>>=20 >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Wed Aug 1 09:51:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D656811E8091 for ; Wed, 1 Aug 2012 09:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.18 X-Spam-Level: X-Spam-Status: No, score=-3.18 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZfq4xKpnjtL for ; Wed, 1 Aug 2012 09:51:31 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB24611E8185 for ; Wed, 1 Aug 2012 09:51:30 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7856000vbb.31 for ; Wed, 01 Aug 2012 09:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qw9CM3HN6jaMGdCTcioYkhFbmqnjaYBvQNeD+oDR3vA=; b=vEguGIFN92HC9F1Jcsu9YmaTm0MjTMXoTLZ8XhRSw+HKIGf+jy1Z8/hIITvJnNeM6B VMufoSN+ySyarn2pepwjCI5RmYwkpRurC47jBS7Wc/km0FGjmmbYUl1HLdccl5DMlULF qIW/qhewPta1psm6FoL8fVJhNHT+bqMt7c/IANC9LOvo0IGbsotvzHakLHnZ070g8aEU we8lcN6d49tyNyz6n3ERPLsyJDfu6sMav6jFTZJhygLJlUQVLtLynT3ta2QE91iR5QC3 a+yEdbfxDUvRVupEbBrHWHmP52VwHU+phTY2EjIZNVNMpb9yQAW2wRllJBaHyfZhDxD4 UzBg== MIME-Version: 1.0 Received: by 10.220.149.148 with SMTP id t20mr17517185vcv.12.1343839890309; Wed, 01 Aug 2012 09:51:30 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Wed, 1 Aug 2012 09:51:30 -0700 (PDT) In-Reply-To: References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> Date: Wed, 1 Aug 2012 18:51:30 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 16:51:33 -0000 Hi Chris, I will refer to your definition/understanding as "MANET-art". I may agree with you only because it seams from the documents similar what you mentioned (MANET becoming which I name it "vague" in concept), but do you think that any MANET-art routing protocol can manage to solve all MANET-art scenarios? IMHO, it never will, I think that because of this general art of dynamic many people in the IETF community are working on some MANET-art scenarios (i.e ROLL, ITS, DTN). I prefer that these participants all come together to work under the MANET-art, but this is not happening, why is that? or even better that IETF creates a sub-area for MANET-art and all these WGs work under same sub-area, I am getting lost here :) My concept is that MANET is a network of mostly mobile nodes connecting, as the word specifies and as the IETF documents created other words for such LLN, ROLL, which in old days in IETF we were calling them MANET. However, reality will dominate visions, and the community/new-generation may change alot of old concepts and old arts to bring new arts (future new arts as LLN-art). AB =3D=3D=3D=3D On 8/1/12, Dearlove, Christopher (UK) wrote= : > The statement that MANETs refers only to networks with physical mobility = is > simply false. While the expansion of the acronym might suggest that, in f= act > MANET has become a term of art, and that art includes many networks with > some or all nodes that are not physically moving. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: 01 August 2012 14:21 > To: C Chauvenet > Cc: manet > Subject: Re: [manet] Some LLNs are NOT MANETs > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Hi C=E9dric, > > Ok we can discuss efficiently when we read the documents (production > of such WG)as you agreed. > >> When you say "IMHO, as long we have a ROLL WG in IETF we need to forward >> work to it which has no mobility behavior", do you mean that the >> difference >> between ROLL and MANET is limited to mobility considerations ? > > *Mobility* It is the mostly difference clearly spoted between the > documents produced by the both WGs, also the name MANET starts with > Mobile, the word mobile is not equal to change/dynamic. So MANET > refers to mobile node or mobile network, which means location change > *NOT* topology change/dynamic. In the old days there was no ROLL WG so > MANET WG was doing the job. > >> >> Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC586= 7 >> all include the usual IoT constraints : Memory, Processing, Power, >> Battery, >> Cost and Size of device. >> RFC5673 does not mention explicitly processing and size constraints, but >> mention all the others. >> > > Ok, > >> RFC 2501 speak about energy and power, as you previously mentioned, but >> does >> not say something on the following constraints : Memory, Processing, >> Cost >> and Size. > > Yes your right, but be careful RFC2501 does not exclude thoes > constraints either. However, if the MANET network has some nodes with > constraints but clearly mobility is the main constraint. > >> >> Do you think that these constraints are in the MANET scope ? >> I guess that they may be (obviously for Cost), but not in the same order >> of >> magnitude as the type of devices described in the requirements RFC of >> ROLL. > > Really don't mind either way for MANET WG, and will think that the WG > community wants it in between In-Scope and Out-Scope, that may be > strange but seems that is what is happening as I read documents. Out > of IETF, MANET is mostly understood as mobile nodes connecting, not > LLNs. > > Overall, IMHO, in the end it is the decision of the IETF community to > decide of any new idea or any I-D acceptance/adoption, but for the WG > it MAY take over a WORK as an IETF I-D, but it may not be successful > to convince the IETF community to continue the work or make it become > a RFC, we always have to see through to make the work efforts flow > successfully. We do not forget that many participants work in both > WGs. > > Regards > Abdussalam > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > On 8/1/12, C Chauvenet wrote: >> Hi, >> >> Thank you for your answer, >> >> See inline. >> >> Le 1 ao=FBt 2012 =E0 13:41, Abdussalam Baryun a =E9crit : >> >>> Hi C=E9dric, >>> >>> I think the RFC2501 is more important than the WG charter, because the >>> charter MAY change but RFCs never changes (only can be updated, >>> obsoleted or replaced). >> >> Good Point, 100% agree. >> >>> So far now all MANET-protocols are refering to >>> RFC2501 which is good and SHOULD continue, and I like this referencing >>> to documents (even if they are old or expired) not referencing to >>> charters, because for example, if in a journal paper we reference to >>> the charter of MANET WG or ROLL WG the information is not solid like >>> if you reference a published document (publisher date), but still we >>> can reference the charter as web reference sited date. >>> >>> I read some paper that reference sited web documents but they may be >>> not valid and cannot be read for some reason. Therefore, IMHO, we need >>> to stick to the following document to make a right decision in >>> definitions: >>> >>> 1) [RFC2501] for MANETs. (published in 1999) >>> 2) [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] for LLNs. >>> (published in 2009) >> >> I think they are good references to build some arguments into this >> discussion. >> >>> >>> Low power was indicated in RFC2501 in section 5.1 as >> constraints> and also the word *sink*, in page 7 you read >> for energy conservation>. IMHO, as long we have a ROLL WG in IETF we >>> need to forward work to it which has no mobility behavior. Delegation >>> will help make work flowing and more focused. >> >> When you say "IMHO, as long we have a ROLL WG in IETF we need to forward >> work to it which has no mobility behavior", do you mean that the >> difference >> between ROLL and MANET is limited to mobility considerations ? >> >> Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC586= 7 >> all include the usual IoT constraints : Memory, Processing, Power, >> Battery, >> Cost and Size of device. >> RFC5673 does not mention explicitly processing and size constraints, but >> mention all the others. >> >> RFC 2501 speak about energy and power, as you previously mentioned, but >> does >> not say something on the following constraints : Memory, Processing, >> Cost >> and Size. >> >> Do you think that these constraints are in the MANET scope ? >> I guess that they may be (obviously for Cost), but not in the same order >> of >> magnitude as the type of devices described in the requirements RFC of >> ROLL. >> >> Regards, >> >> C=E9dric. >> >>> >>> Regards >>> AB >>> =3D=3D=3D=3D=3D=3D=3D >>> >>> On 8/1/12, C Chauvenet wrote: >>>> Hi, >>>> >>>> This is an interesting discussion. >>>> >>>> My understanding is that both MANET and ROLL considers lossy/dynamic >>>> links >>>> in the way described in the MANET charter : "static and dynamic >>>> topologies >>>> with increased dynamics due to node motion or other factors." I also >>>> agree >>>> that dynamicity of links is not hard wired to node mobility. >>>> >>>> So, in the LLN Vs MANET debate, I think they share the "N" for >>>> Networks, >>>> and >>>> the 2nd "L" for Lossy. >>>> So the remaining point is the first L, meaning Low Power. >>>> >>>> Low Power requirements is explicit in the ROLL charter and not >>>> mentioned >>>> at >>>> all in the MANET charter. >>>> Is the power efficiency consideration the big difference between ROLL >>>> and >>>> MANET ? >>>> >>>> C=E9dric. >>>> >>>> -----Message d'origine----- >>>> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part d= e >>>> Abdussalam Baryun >>>> Envoy=E9 : mercredi 1 ao=FBt 2012 09:22 >>>> =C0 : Henning Rogge >>>> Cc : roll; manet >>>> Objet : [Roll] Some LLNs are NOT MANETs >>>> >>>> Hi Henning, >>>> >>>> I am about to say many LLNs are NOT MANETs but it seems like the marke= t >>>> or >>>> community will decide the outcome, but surly that some LLNs are NOT >>>> MANETs. >>>> >>>>> Could you state an example what would be considered a LLN but not a >>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>> >>>> I not totally agree with that, because we need to be considering both >>>> NETs >>>> use case and applicability in the vision of the different WGs (MANET >>>> and >>>> ROLL). There are many examples we can find them in the [RFC2501] for >>>> MANETs >>>> characteristics and applicability, and for LLNs characteristics in >>>> [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs >>>> requirements. That is why I suggested before that >>>> OLSRv2 and AODVv2 should mention their applicability to LLN if they do= . >>>> They >>>> just refer to RFC2501, but RFC2501 is OLD and does not mention LLN but >>>> describes the meaning. The authors of RFC2501 still not responded to m= y >>>> update suggestions. >>>> >>>> I understood from one discussion in MANET WG that few don't have time >>>> to >>>> read many pages of documents, so that is why I suggested to have >>>> terminology >>>> I-D [1] as we have ROLL terminology [ROLL] . I also taken initiative t= o >>>> make >>>> new draft of MANET subnet technologies which include only related LLN= s >>>> [AB2]. >>>> >>>> Therefore, I will add the definition for MANET and LLN into my >>>> manet-terminology draft [AB1] (propose that authors of [ROLL] define >>>> LLN >>>> more details) to assist discussions as it is proved now in the list >>>> that >>>> there still is problems in definitions in MANET WG or in some I-D >>>> editorial >>>> content. >>>> >>>> [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >>>> [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >>>> [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt >>>> >>>> Best Wishes >>>> >>>> Abdussalam Baryun >>>> University of Glamorgan, UK >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>> On 7/31/12, Henning Rogge wrote: >>>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>>>> subject: Re: [manet] Discussing LOADng suggestions >>>>> wrote: >>>>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, but >>>>>> then changed its direction to MANET [3]. However, please note that >>>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >>>>>> said, LOADng SHOULD specfy where is its limits. Then we can discuss >>>>>> adoption. >>>>> >>>>> Could you state an example what would be considered a LLN but not a >>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>> >>>>> Henning Rogge >>>>> >>>>> -- >>>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>>> billions of percent in a tiny fraction of a second. Of course, that >>>>> was before the present government." >>>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>>> >>>> >>> >> >> >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > From budden@nps.edu Wed Aug 1 10:02:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6867E11E8087 for ; Wed, 1 Aug 2012 10:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsCJzAiazQj5 for ; Wed, 1 Aug 2012 10:02:56 -0700 (PDT) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 1E00511E8191 for ; Wed, 1 Aug 2012 10:02:56 -0700 (PDT) X-ASG-Debug-ID: 1343840575-036c920496430ea0001-Rp4q3q Received: from gulfstream.ern.nps.edu (gulfstream.ern.nps.edu [172.20.24.113]) by mule.nps.edu with ESMTP id zKMDG6MCcrPWa8uX; Wed, 01 Aug 2012 10:02:55 -0700 (PDT) X-Barracuda-Envelope-From: budden@nps.edu Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.113) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 1 Aug 2012 10:02:53 -0700 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [manet] Some LLNs are NOT MANETs To: "Stan Ratliff (sratliff)" In-Reply-To: References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 1 Aug 2012 10:02:00 -0700 Message-ID: <1343840520.981.874.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 8bit X-Barracuda-Connect: gulfstream.ern.nps.edu[172.20.24.113] X-Barracuda-Start-Time: 1343840575 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.104388 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: "Dearlove, Christopher \(UK\)" , manet , Abdussalam Baryun Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:02:57 -0000 I think a topology differentiation is worthwhile ... hasn't appeared in this thread. Most of the 'mobility' discussion in the commercial world has had the radio network at the fringe -- in a LAN role. But the problems (my instrumented ambulance example is good for this) that we need to grow into are ones where the radio network is in a WAN position in the internetwork -- it's a router-router problem, not a last-router-to-end system one. On Wed, 2012-08-01 at 16:22 +0000, Stan Ratliff (sratliff) wrote: > Precisely, Chris. > > I've come to view MANETs more and more in the terms of an "opportunistic network". By that, I mean a network with a fairly large amount of dynamism, and also a network that contains heterogeneity of links (e.g., different radio types, and/or some wired portions). The challenge of these networks is to opportunistically (and maximally) use the resources available to it at any point in time. > > And at least for me (and I know this will draw some fire in return), another distinction in MANET as opposed to LLN is a greater requirement for peer-to-peer (node-to-node) communication, From what I've seen of LLN deployments (and I'm no expert), they tend to have more of a "multiple source/single sink" model for the data flow. > > Again, just one opinion. > > Regards, > Stan > > On Aug 1, 2012, at 11:26 AM, Dearlove, Christopher (UK) wrote: > > > The statement that MANETs refers only to networks with physical mobility is simply false. While the expansion of the acronym might suggest that, in fact MANET has become a term of art, and that art includes many networks with some or all nodes that are not physically moving. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > -----Original Message----- > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun > > Sent: 01 August 2012 14:21 > > To: C Chauvenet > > Cc: manet > > Subject: Re: [manet] Some LLNs are NOT MANETs > > > > ----------------------! WARNING ! ---------------------- > > This message originates from outside our organisation, > > either from an external partner or from the internet. > > Keep this in mind if you answer this message. > > Follow the 'Report Suspicious Emails' link on IT matters > > for instructions on reporting suspicious email messages. > > -------------------------------------------------------- > > > > Hi Cédric, > > > > Ok we can discuss efficiently when we read the documents (production > > of such WG)as you agreed. > > > >> When you say "IMHO, as long we have a ROLL WG in IETF we need to forward > >> work to it which has no mobility behavior", do you mean that the difference > >> between ROLL and MANET is limited to mobility considerations ? > > > > *Mobility* It is the mostly difference clearly spoted between the > > documents produced by the both WGs, also the name MANET starts with > > Mobile, the word mobile is not equal to change/dynamic. So MANET > > refers to mobile node or mobile network, which means location change > > *NOT* topology change/dynamic. In the old days there was no ROLL WG so > > MANET WG was doing the job. > > > >> > >> Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC5867 > >> all include the usual IoT constraints : Memory, Processing, Power, Battery, > >> Cost and Size of device. > >> RFC5673 does not mention explicitly processing and size constraints, but > >> mention all the others. > >> > > > > Ok, > > > >> RFC 2501 speak about energy and power, as you previously mentioned, but does > >> not say something on the following constraints : Memory, Processing, Cost > >> and Size. > > > > Yes your right, but be careful RFC2501 does not exclude thoes > > constraints either. However, if the MANET network has some nodes with > > constraints but clearly mobility is the main constraint. > > > >> > >> Do you think that these constraints are in the MANET scope ? > >> I guess that they may be (obviously for Cost), but not in the same order of > >> magnitude as the type of devices described in the requirements RFC of ROLL. > > > > Really don't mind either way for MANET WG, and will think that the WG > > community wants it in between In-Scope and Out-Scope, that may be > > strange but seems that is what is happening as I read documents. Out > > of IETF, MANET is mostly understood as mobile nodes connecting, not > > LLNs. > > > > Overall, IMHO, in the end it is the decision of the IETF community to > > decide of any new idea or any I-D acceptance/adoption, but for the WG > > it MAY take over a WORK as an IETF I-D, but it may not be successful > > to convince the IETF community to continue the work or make it become > > a RFC, we always have to see through to make the work efforts flow > > successfully. We do not forget that many participants work in both > > WGs. > > > > Regards > > Abdussalam > > ========================================================== > > On 8/1/12, C Chauvenet wrote: > >> Hi, > >> > >> Thank you for your answer, > >> > >> See inline. > >> > >> Le 1 août 2012 à 13:41, Abdussalam Baryun a écrit : > >> > >>> Hi Cédric, > >>> > >>> I think the RFC2501 is more important than the WG charter, because the > >>> charter MAY change but RFCs never changes (only can be updated, > >>> obsoleted or replaced). > >> > >> Good Point, 100% agree. > >> > >>> So far now all MANET-protocols are refering to > >>> RFC2501 which is good and SHOULD continue, and I like this referencing > >>> to documents (even if they are old or expired) not referencing to > >>> charters, because for example, if in a journal paper we reference to > >>> the charter of MANET WG or ROLL WG the information is not solid like > >>> if you reference a published document (publisher date), but still we > >>> can reference the charter as web reference sited date. > >>> > >>> I read some paper that reference sited web documents but they may be > >>> not valid and cannot be read for some reason. Therefore, IMHO, we need > >>> to stick to the following document to make a right decision in > >>> definitions: > >>> > >>> 1) [RFC2501] for MANETs. (published in 1999) > >>> 2) [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] for LLNs. > >>> (published in 2009) > >> > >> I think they are good references to build some arguments into this > >> discussion. > >> > >>> > >>> Low power was indicated in RFC2501 in section 5.1 as >>> constraints> and also the word *sink*, in page 7 you read >>> for energy conservation>. IMHO, as long we have a ROLL WG in IETF we > >>> need to forward work to it which has no mobility behavior. Delegation > >>> will help make work flowing and more focused. > >> > >> When you say "IMHO, as long we have a ROLL WG in IETF we need to forward > >> work to it which has no mobility behavior", do you mean that the difference > >> between ROLL and MANET is limited to mobility considerations ? > >> > >> Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC5867 > >> all include the usual IoT constraints : Memory, Processing, Power, Battery, > >> Cost and Size of device. > >> RFC5673 does not mention explicitly processing and size constraints, but > >> mention all the others. > >> > >> RFC 2501 speak about energy and power, as you previously mentioned, but does > >> not say something on the following constraints : Memory, Processing, Cost > >> and Size. > >> > >> Do you think that these constraints are in the MANET scope ? > >> I guess that they may be (obviously for Cost), but not in the same order of > >> magnitude as the type of devices described in the requirements RFC of ROLL. > >> > >> Regards, > >> > >> Cédric. > >> > >>> > >>> Regards > >>> AB > >>> ======= > >>> > >>> On 8/1/12, C Chauvenet wrote: > >>>> Hi, > >>>> > >>>> This is an interesting discussion. > >>>> > >>>> My understanding is that both MANET and ROLL considers lossy/dynamic > >>>> links > >>>> in the way described in the MANET charter : "static and dynamic > >>>> topologies > >>>> with increased dynamics due to node motion or other factors." I also > >>>> agree > >>>> that dynamicity of links is not hard wired to node mobility. > >>>> > >>>> So, in the LLN Vs MANET debate, I think they share the "N" for Networks, > >>>> and > >>>> the 2nd "L" for Lossy. > >>>> So the remaining point is the first L, meaning Low Power. > >>>> > >>>> Low Power requirements is explicit in the ROLL charter and not mentioned > >>>> at > >>>> all in the MANET charter. > >>>> Is the power efficiency consideration the big difference between ROLL > >>>> and > >>>> MANET ? > >>>> > >>>> Cédric. > >>>> > >>>> -----Message d'origine----- > >>>> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de > >>>> Abdussalam Baryun > >>>> Envoyé : mercredi 1 août 2012 09:22 > >>>> À : Henning Rogge > >>>> Cc : roll; manet > >>>> Objet : [Roll] Some LLNs are NOT MANETs > >>>> > >>>> Hi Henning, > >>>> > >>>> I am about to say many LLNs are NOT MANETs but it seems like the market > >>>> or > >>>> community will decide the outcome, but surly that some LLNs are NOT > >>>> MANETs. > >>>> > >>>>> Could you state an example what would be considered a LLN but not a > >>>>> MANET. I normally consider LLNs a subset of what we call MANETs. > >>>> > >>>> I not totally agree with that, because we need to be considering both > >>>> NETs > >>>> use case and applicability in the vision of the different WGs (MANET and > >>>> ROLL). There are many examples we can find them in the [RFC2501] for > >>>> MANETs > >>>> characteristics and applicability, and for LLNs characteristics in > >>>> [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs > >>>> requirements. That is why I suggested before that > >>>> OLSRv2 and AODVv2 should mention their applicability to LLN if they do. > >>>> They > >>>> just refer to RFC2501, but RFC2501 is OLD and does not mention LLN but > >>>> describes the meaning. The authors of RFC2501 still not responded to my > >>>> update suggestions. > >>>> > >>>> I understood from one discussion in MANET WG that few don't have time to > >>>> read many pages of documents, so that is why I suggested to have > >>>> terminology > >>>> I-D [1] as we have ROLL terminology [ROLL] . I also taken initiative to > >>>> make > >>>> new draft of MANET subnet technologies which include only related LLNs > >>>> [AB2]. > >>>> > >>>> Therefore, I will add the definition for MANET and LLN into my > >>>> manet-terminology draft [AB1] (propose that authors of [ROLL] define LLN > >>>> more details) to assist discussions as it is proved now in the list that > >>>> there still is problems in definitions in MANET WG or in some I-D > >>>> editorial > >>>> content. > >>>> > >>>> [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt > >>>> [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt > >>>> [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt > >>>> > >>>> Best Wishes > >>>> > >>>> Abdussalam Baryun > >>>> University of Glamorgan, UK > >>>> > >>>> ==================================================== > >>>> On 7/31/12, Henning Rogge wrote: > >>>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun > >>>>> subject: Re: [manet] Discussing LOADng suggestions > >>>>> wrote: > >>>>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, but > >>>>>> then changed its direction to MANET [3]. However, please note that > >>>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That > >>>>>> said, LOADng SHOULD specfy where is its limits. Then we can discuss > >>>>>> adoption. > >>>>> > >>>>> Could you state an example what would be considered a LLN but not a > >>>>> MANET. I normally consider LLNs a subset of what we call MANETs. > >>>>> > >>>>> Henning Rogge > >>>>> > >>>>> -- > >>>>> Steven Hawkings about cosmic inflation: "An increase of billions of > >>>>> billions of percent in a tiny fraction of a second. Of course, that > >>>>> was before the present government." > >>>>> > >>>> _______________________________________________ > >>>> Roll mailing list > >>>> Roll@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/roll > >>>> > >>>> > >>>> > >>> > >> > >> > >> > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > > > ******************************************************************** > > This email and any attachments are confidential to the intended > > recipient and may also be privileged. If you are not the intended > > recipient please delete it from your system and notify the sender. > > You should not copy it or use it for any purpose nor disclose or > > distribute its contents to any other person. > > ******************************************************************** > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jomullen@ad.nmsu.edu Wed Aug 1 10:29:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D141611E83E0 for ; Wed, 1 Aug 2012 10:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAfiABrEhriF for ; Wed, 1 Aug 2012 10:29:26 -0700 (PDT) Received: from exchange.nmsu.edu (exchange-ht-02.nmsu.edu [128.123.34.236]) by ietfa.amsl.com (Postfix) with ESMTP id E860311E83D8 for ; Wed, 1 Aug 2012 10:29:25 -0700 (PDT) Received: from EXCHANGE-MBX-01.ACN.ad.nmsu.edu ([128.123.34.88]) by exchange-ht-02.ACN.ad.nmsu.edu ([128.123.34.236]) with mapi; Wed, 1 Aug 2012 11:29:25 -0600 From: Dr John P Mullen To: manet Date: Wed, 1 Aug 2012 11:29:24 -0600 Thread-Topic: [manet] Discussing LOADng suggestions Thread-Index: AQHNWdphm+u1REK/lkKRZGyT6FVJyZdDgSgAgAAA4wCAAD5HAIAAAY2AgAAB3gCAAArtgIAAAMAAgAEEyICAAICYQA== Message-ID: References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F9A5F0DF0BBF2547A0E94FC12263712E940C569F4BEXCHANGEMBX01_" MIME-Version: 1.0 Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:29:30 -0000 --_000_F9A5F0DF0BBF2547A0E94FC12263712E940C569F4BEXCHANGEMBX01_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A network can appear stationary to the naked eye, but quite dynamic to the = transceivers in it. Vehicles, people, air temperature storms, etc., will af= fect propagation paths. If there are multipath possibilities, the potential= for disruption is much greater. Also, as Chris points out, things happen = to the equipment. Even a small change in the local environment can have a profound change in = the radio world. I've talked to tank commanders who could see their wingman= , but not communicate. Move one tank or the other just a couple of feet, wa= it a few minutes, etc., and the problem clears up. Unless the MANET is in a location in which no one or nobody moves and absol= utely nothing changes, there could be changes that would require updating o= f the routing. Ah, but what's the fun in that? John Mullen From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of D= earlove, Christopher (UK) Sent: Wednesday, August 01, 2012 3:04 AM To: Ulrich Herberg; Velt, R. (Ronald) in 't Cc: manet; Abdussalam Baryun Subject: Re: [manet] Discussing LOADng suggestions If a network is static, but not preconfigured, then you may still want to r= un a proactive routing protocol up to the point where you have established = the topology, then turn it off. Or if there's a reason not to want to do th= at, you could run a reactive routing protocol, with anything up to infinite= expiry time on discovered routes. And one more scenario. Your nodes are all stationary, your propagation is s= tationary. You have no moving obstacles. But things are still (sporadically= ) dynamic when your nodes fail (battery exhaustion, accident, enemy action)= . -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of Ulric= h Herberg Sent: 31 July 2012 19:26 To: Velt, R. (Ronald) in 't Cc: manet; Abdussalam Baryun Subject: Re: [manet] Discussing LOADng suggestions *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Ronald, On Tue, Jul 31, 2012 at 11:23 AM, Velt, R. (Ronald) in 't > wrote: >-----Original Message----- >From: manet-bounces@ietf.org [mailto:manet-= bounces@ietf.org] On Behalf >Of Antonin Bas >Sent: dinsdag 31 juli 2012 19:44 >To: Ulrich Herberg >Cc: manet; Abdussalam Baryun >Subject: Re: [manet] Discussing LOADng suggestions > >According to MANET charter, > >The purpose of the MANET working group is to standardize IP routing > protocol functionality suitable for wireless routing application within > both static and dynamic topologies with increased dynamics due to node > motion or other factors. Strange wording, in my opinion. It seems to me that if the network _topolog= y_ is truly static, you do not need a routing protocol at all. I agree. (Note that just as the absence of movement does not imply a static topology= , a static topology does not imply stationary nodes). > >So I don't think MANETs are defined by mobility, but by "increased >dynamics",which can be due to motion, but also to lossy links. So why aren't they called ANETs? Or DANET ("dynamic"). It just did not sound as nice when the term was creat= ed. Best Ulrich Ronald > >2012/7/31 Ulrich Herberg >= : >> MANETs are not defined by mobility. It is rather about very dynamic >> topologies. Otherwise, community networks such as FunkFeuer would also >> not be qualified as MANETs. >> >> Ulrich >> >> >> On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal > wrote: >>> >>> The wireless network of "fixed" temperature monitoring sensors and >>> HVAC controllers in a building. This network is an LLN. Not sure if >>> it qualifies as a MANET (since nothing is mobile). >>> >>> Thanks >>> Mukul >>> >>> ----- Original Message ----- >>> From: "Henning Rogge" > >>> To: "Abdussalam Baryun" > >>> Cc: "manet" > >>> Sent: Tuesday, July 31, 2012 8:49:08 AM >>> Subject: Re: [manet] Discussing LOADng suggestions >>> >>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>> > wrote: >>> > IMHO this protocol was intended as for ROLL WG not for MANET WG, >>> > but then changed its direction to MANET [3]. However, please note >>> > that >>> > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. >That >>> > said, LOADng SHOULD specfy where is its limits. Then we can discuss >>> > adoption. >>> >>> Could you state an example what would be considered a LLN but not a >>> MANET. I normally consider LLNs a subset of what we call MANETs. >>> >>> Henning Rogge >>> >>> -- >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>> billions of percent in a tiny fraction of a second. Of course, that >>> was before the present government." >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_F9A5F0DF0BBF2547A0E94FC12263712E940C569F4BEXCHANGEMBX01_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

 

A network can appear stationary to the naked eye, = but quite dynamic to the transceivers in it. Vehicles, people, air temperat= ure storms, etc., will affect propagation paths. If there are multipath pos= sibilities, the potential for disruption is much greater.  Also, as Ch= ris points out, things happen to the equipment.

 

Even a small change in the local environment can have a profound change= in the radio world. I’ve talked to tank commanders who could see the= ir wingman, but not communicate. Move one tank or the other just a couple o= f feet, wait a few minutes, etc., and the problem clears up.

 

Unless the MANET is in a location in which no one or nobod= y moves and absolutely nothing changes, there could be changes that would r= equire updating of the routing.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

Ah, but what&= #8217;s the fun in that?

<= o:p> 

John Mullen

 

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> manet-bo= unces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Dearlove= , Christopher (UK)
Sent: Wednesday, August 01, 2012 3:04 AM
To: Ulrich Herberg; Velt, R. (Ronald) in 't
Cc: manet; Abdus= salam Baryun
Subject: Re: [manet] Discussing LOADng suggestions

 

<= p class=3DMsoNormal>If a network is static, but not pre= configured, then you may still want to run a proactive routing protocol up = to the point where you have established the topology, then turn it off. Or = if there's a reason not to want to do that, you could run a reactive routin= g protocol, with anything up to infinite expiry time on discovered routes.<= o:p>

 

And one more scenar= io. Your nodes are all stationary, your propagation is stationary. You have= no moving obstacles. But things are still (sporadically) dynamic when your= nodes fail (battery exhaustion, accident, enemy action).=

 

-- <= /o:p>

Christopher Dearlove

Senior Principal Engineer, Comm= unications Group
Communications, Networks and Image Analysis Capability<= br>BAE Systems Advanced Technology Centre
West Hanningfield Road, Great = Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: += 44 1245 242124

chris.dearlove@baesys= tems.com | http://www.baes= ystems.com

BAE Systems (Operations) Limited
Registered Office= : Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hant= s, GU14 6YU, UK
Registered in England & Wales No: 1996687=

 

From: man= et-bounces@ietf.org = [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg
<= b>Sent: 31 July 2012 19:26
To: Velt, R. (Ronald) in 't
= Cc: manet; Abdussalam Baryun
Subject: Re: [manet] Discussing = LOADng suggestions

 

 

<= b>*** WARNING ***

This message originates from = outside our organisation, either from an external partner or the internet.<= /span>
Keep this in mind if you answer this message.
= Please see this process on how to deal w= ith suspicious emails.<= /span>

<= span lang=3DEN-GB>Ronald,

On Tue, Jul 31, 2012 at 11:23 AM, Velt, R. (Ronald) in 't = <Ronald.intVe= lt@tno.nl> wrote:


>-----Original Message-----
>From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf>Of Antonin Bas
>Sent: dinsdag 31 juli 2012 19:44
>To: Ulri= ch Herberg
>Cc: manet; Abdussalam Baryun
>Subject: Re: [manet] = Discussing LOADng suggestions
>

>Accor= ding to MANET charter,
>
>The purpose of the MANET working grou= p is to standardize IP routing
>  protocol functionality suitabl= e for wireless routing application within
>  both static and dyn= amic topologies with increased dynamics due to node
>  motion or= other factors.

Strange wording, in my opinion. It seems to me that if the network= _topology_ is truly static, you do not need a routing protocol at all.



I a= gree.

 

(Note that just as the absence of movement does n= ot imply a static topology, a static topology does not imply stationary nod= es).


>
>So I don't think MANETs are defi= ned by mobility, but by "increased
>dynamics",which can be = due to motion, but also to lossy links.

So why aren't they called ANETs?=


Or DANET ("dynamic"). It just did not sound as nice when the te= rm was created.

Best
Ulrich


 


Ronald=

>= ;
>2012/7/31 Ulrich Herberg <ulrich@herberg.name>:
>> MANETs are not defined by mobili= ty. It is rather about very dynamic
>> topologies. Otherwise, comm= unity networks such as FunkFeuer would also
>> not be qualified as= MANETs.
>>
>> Ulrich
>>
>>
>>= On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal <mukul@uwm.edu> wrote:
>>>
>>> The w= ireless network of "fixed" temperature monitoring sensors and
= >>> HVAC controllers in a building. This network is an LLN. Not su= re if
>>> it qualifies as a MANET (since nothing is mobile).>>>
>>> Thanks
>>> Mukul
>>><= br>>>> ----- Original Message -----
>>> From: "He= nning Rogge" <hrogge@googl= email.com>
>>> To: "Abdussalam Baryun" <abdussalambaryun@gmail.com&g= t;
>>> Cc: "manet" <manet@ietf.org>
>>> Sent: Tuesday, July 31, 2012 8:4= 9:08 AM
>>> Subject: Re: [manet] Discussing LOADng suggestions<= br>>>>
>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam= Baryun
>>> <a= bdussalambaryun@gmail.com> wrote:
>>> > IMHO this pro= tocol was intended as for ROLL WG not for MANET WG,
>>> > bu= t then changed its direction to MANET [3]. However, please note
>>= > > that
>>> > *ONLY* some LLNs are MANETs, and *ONLY*= some MANETs are LLNs.
>That
>>> > said, LOADng SHOULD= specfy where is its limits. Then we can discuss
>>> > adopt= ion.
>>>
>>> Could you state an example what would = be considered a LLN but not a
>>> MANET. I normally consider LL= Ns a subset of what we call MANETs.
>>>
>>> Henning= Rogge
>>>
>>> --
>>> Steven Hawkings a= bout cosmic inflation: "An increase of billions of
>>> bil= lions of percent in a tiny fraction of a second. Of course, that
>>= ;> was before the present government."
>>> ____________= ___________________________________
>>> manet mailing list
&= gt;>> manet@ietf.org
>>= ;> https://www.ietf.org/mailman/listinfo/manet
>>> ______= _________________________________________
>>> manet mailing lis= t
>>> manet@ietf.org
&= gt;>> https://www.ietf.org/mailman/listinfo/manet
>>
= >>
>>
>> __________________________________________= _____
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo= /manet
>>
>_____________________________________________= __
>manet mailing list
>manet= @ietf.org
>https://www.ietf.org/mailman/listinfo/manet

This e-mail and its contents are subject to= the DISCLAIMER at http://www.tno.nl/emaildisclaimer

 <= /o:p>


***********************************************************= *********
This email and any attachments are confidential to the intende= d
recipient and may also be privileged. If you are not the intended
r= ecipient please delete it from your system and notify the sender.
You sh= ould not copy it or use it for any purpose nor disclose or
distribute it= s contents to any other person.
****************************************= ****************************

= --_000_F9A5F0DF0BBF2547A0E94FC12263712E940C569F4BEXCHANGEMBX01_-- From jpmacker@gmail.com Wed Aug 1 10:40:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AA811E82DB for ; Wed, 1 Aug 2012 10:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxq5+eQru7Ue for ; Wed, 1 Aug 2012 10:40:46 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9622511E82C2 for ; Wed, 1 Aug 2012 10:40:46 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so7842732vcb.31 for ; Wed, 01 Aug 2012 10:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2rClBIad7J6ZyLCORs47lXx0qHeLQoulKh7I30sYFnU=; b=Sau+34TCktKx/56eM+9nUq8yzBFjH8b6IqI6HAPsLnSoWgyIyDSrvPsyp3UkvfNh5b kmBAKeRjGaLdbcnCFaOv7BzCxNuF8o7meE6GMJVOTEdJFRu+KjXK/xoO8Zk6UKQ6IGpA JTwDAdo/nIBHj1WnTvfFfDeVno32U2GsDlnfWpAF+A/JQeBjHzuORs7QIBsNW1wJf2a4 VopjgaFCwAcF7K0wCbumaa/VHdtPNzHRzsUXc+LCUbOEP/8IifuxfGhQAQcyOlYuCCo8 err7HqyYVd5/1n6Zfh3lAIY819FhFOi2dD89yT4PAhjknrClIiKc3gGYgY+Dn+CYqXam kTqw== MIME-Version: 1.0 Received: by 10.58.74.196 with SMTP id w4mr6468218vev.7.1343842843605; Wed, 01 Aug 2012 10:40:43 -0700 (PDT) Received: by 10.58.94.40 with HTTP; Wed, 1 Aug 2012 10:40:43 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 10:40:43 -0700 Message-ID: From: Joseph Macker To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=047d7b86edf653bb8004c637cb25 Cc: manet Subject: Re: [manet] Propose update RFC2501 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:40:56 -0000 --047d7b86edf653bb8004c637cb25 Content-Type: text/plain; charset=ISO-8859-1 I responded to you already that I thought it was a bad idea. On Wed, Aug 1, 2012 at 12:27 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Joe, > > This is a reminder to a post I send before you as one author of > RFC2501, and the below. I need your respond to my suggestion. I > thought you will discuss it in the meeting but you did not mention it, > please comment/advise, > > AB > ==== > > On 7/4/12, Abdussalam Baryun wrote: > > Hi All, > > > > I want to propose draft-ietf work to be done on update the RFC2501, > > which I don't mind doing, on the following issues: > > > > 1- to include all active MANET routing RFCs as describing its network > > characteristics and its network context applicability, as mentioned by > > section-6. > > 2- to include the RFC5444 characteristics, or benefits to MANET > > performance. > > 3- to include NHDP RFC6130. > > 4- IPv6 considerations > > 5- Add more information in characteristic section on issue of > > reliability and scalability. > > > > RFC2501> 3. Characteristics of MANETs > > MANETs have several salient characteristics: > > AB>Add> 5) issue of variable E2E delay and node disconnecting from > > MANET. > > AB> suggest> to consider LLN > > > > 2501> 5. IP-Layer Mobile Routing > > AB> interfaces as physical layer technology, what about interfaces as > > logical? in some other parts we read wireless interface > > > > 2501> 5>Future interoperability may be achieved using mechanisms other > than > > mobile IP. > > AB> Are we there, could we answer to add some? > > > > 2501>5>Supporting these features appears only to require identifying > > host and router interfaces with IP addresses, identifying a router > > with a separate Router ID, and permitting routers to have multiple > > wired and wireless interfaces. > > AB> replace "host and router" with " router" as it was done in DYMO and > > OLSRv2 > > > > 2501> 4) Proactive operation: The flip-side of demand-based operation. > > AB> not clear > > > > 2501> Section 6.7, Duplex link and bidirectional link > > AB> why we use *duplex* with *link*, duplex is related to the > > interface system more than the link, so I recommend only using > > *bidirectional-link* and replace duplex-link. > > > > 2501> The following is a list of quantitative metrics that can be used to > > assess the performance of any routing protocol. > > AB> add examples of new metric used in industry or by active manet > > protocols > > > > 2501> 7. Security Considerations > > AB> Needs to be amended to consider new techniques > > > > The purpose of the proposed update, is first because RFC2501 is a > > reference to many new RFCs and that updates directs progress designs. > > Please note that I will not do this work until most active participant > > agree, thanking you, > > > > Best Regards > > Abdussalam > > > > +++++++++++++++++++++++++++++++++++++++++++++++++++++ > > On 6/21/12, Charles E. Perkins wrote: > >> > >> Hello Abdussalam, > >> > >> I didn't see what part of RFC 2501 needed to be revised. > >> Do you have a specific proposal? I think that, before you > >> could expect any discussion on revising that document, > >> you would have to point out what part or parts need > >> work. > >> > >> Regards, > >> Charlie P. > >> > >> On 6/21/2012 9:10 AM, Abdussalam Baryun wrote: > >>>> Could we Update RFC2501? > >>> I see that RFC2501 some how defines MANET technologies, which will be > >>> a good reference in the draft I am writting of L2 subnets, but maybe > >>> RFC2501 is enough for the protocols, and no need for a new draft. > >>> However, that will depend on the WG discussion and decision :) > >>> > >>> I got no answer of the question so far, therefore, I will propose it > >>> to be discussed in the next meeting IETF 84. > >>> > >>> AB > >>> ===================================================== > >>> On 6/6/12, Abdussalam Baryun wrote: > >>>> Hi Folks, > >>>> > >>>> the RFC2501 is the best RFC I read and I like it because it is easy to > >>>> read, understandable, and covers solid issues of MANET. I hope the > >>>> authors give us a feedback if they want to make new one as Version 2. > >>>> > >>>> I see that it is old (1999), and it may be interesting to update it > >>>> some how, I hope the authors can update its issues and evaluation, now > >>>> we got new RFCs and industries have new needs than 90s, it does not > >>>> cover different devices constraints as sensors and LLNs, and IPv6, > >>>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 are > >>>> getting renew versions. > >>>> > >>>> As I can see OLSRv2 and AODVv2 are going in progress, why we don't try > >>>> to update RFC2501 as well, it will only take few days or a month, to > >>>> draft and submit so why leave it old-documents with old > >>>> considerations? Please advise, > >>>> > >>>> Abdussalam Baryun > >>>> University of Glamorgan, UK. > >>>> ========================================================= > >>>> > >>> _______________________________________________ > >>> manet mailing list > >>> manet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/manet > >>> > >> > >> > >> -- > >> Regards, > >> Charlie P. > >> > >> > > > --047d7b86edf653bb8004c637cb25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I responded to you already that I thought it was a bad idea.

On Wed, Aug 1, 2012 at 12:27 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
Hi Joe,

This is a reminder to a post I send before you as one author of
RFC2501, and the below. I need your respond to my suggestion. I
thought you will discuss it in the meeting but you did not mention it,
please comment/advise,

AB
=3D=3D=3D=3D

On 7/4/12, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
> Hi All,
>
> I want to propose draft-ietf work to be done on update the RFC2501, > which I don't mind doing, on the following issues:
>
> 1- to include all active MANET routing RFCs as describing its network<= br> > characteristics and its network context applicability, as mentioned by=
> section-6.
> 2- to include the RFC5444 characteristics, or benefits to MANET
> performance.
> 3- to include NHDP RFC6130.
> 4- IPv6 considerations
> 5- Add more information in characteristic section on issue of
> reliability and scalability.
>
> RFC2501> 3. Characteristics of MANETs
> MANETs have several salient characteristics:
> AB>Add> =A0 =A05) issue of variable E2E delay and node disconnec= ting from
> MANET.
> AB> suggest> to consider LLN
>
> 2501> 5. IP-Layer Mobile Routing
> AB> interfaces as physical layer technology, what about interfaces = as
> logical? in some other parts we read wireless interface
>
> 2501> 5>Future interoperability may be achieved using mechanisms= other than
> mobile IP.
> AB> Are we there, could we answer to add some?
>
> 2501>5>Supporting these features appears only to require identif= ying
> host and router interfaces with IP addresses, identifying a router
> with a separate Router ID, and permitting routers to have multiple
> wired and wireless interfaces.
> AB> replace "host and router" with " router" as= it was done in DYMO and
> OLSRv2
>
> 2501> =A04) Proactive operation: The flip-side of demand-based oper= ation.
> AB> not clear
>
> 2501> Section 6.7, =A0 Duplex link and bidirectional link
> AB> why we use *duplex* with *link*, duplex is related to the
> interface system more than the link, so I recommend only using
> *bidirectional-link* and replace duplex-link.
>
> 2501> The following is a list of quantitative metrics that can be u= sed to
> assess the performance of any routing protocol.
> AB> add examples of new metric used in industry or by active manet<= br> > protocols
>
> 2501> 7. Security Considerations
> AB> Needs to be amended to consider new techniques
>
> The purpose of the proposed update, is first because RFC2501 is a
> reference to many new RFCs and that updates directs progress designs.<= br> > Please note that I will not do this work until most active participant=
> agree, thanking you,
>
> Best Regards
> Abdussalam
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++
> On 6/21/12, Charles E. Perkins <charliep@computer.org> wrote:
>>
>> Hello Abdussalam,
>>
>> I didn't see what part of RFC 2501 needed to be revised.
>> Do you have a specific proposal? =A0I think that, before you
>> could expect any discussion on revising that document,
>> you would have to point out what part or parts need
>> work.
>>
>> Regards,
>> Charlie P.
>>
>> On 6/21/2012 9:10 AM, Abdussalam Baryun wrote:
>>>> Could we Update RFC2501?
>>> I see that RFC2501 some how defines MANET technologies, which = will be
>>> a good reference in the draft I am writting of L2 subnets, but= maybe
>>> RFC2501 is enough for the protocols, and no need for a new dra= ft.
>>> However, that will depend on the WG discussion and decision :)=
>>>
>>> I got no answer of the question so far, therefore, I will prop= ose it
>>> to be discussed in the next meeting IETF 84.
>>>
>>> AB
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
>>> On 6/6/12, Abdussalam Baryun<abdussalambaryun@gmail.com> =A0wrote:
>>>> Hi Folks,
>>>>
>>>> the RFC2501 is the best RFC I read and I like it because i= t is easy to
>>>> read, understandable, and covers solid issues of MANET. I = hope the
>>>> authors give us a feedback if they want to make new one as= Version 2.
>>>>
>>>> I see that it is old (1999), and it may be interesting to = update it
>>>> some how, I hope the authors can update its issues and eva= luation, now
>>>> we got new RFCs and industries have new needs than 90s, it= does not
>>>> cover different devices constraints as sensors and LLNs, a= nd IPv6,
>>>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC= 3626 are
>>>> getting renew versions.
>>>>
>>>> As I can see OLSRv2 and AODVv2 are going in progress, why = we don't try
>>>> to update RFC2501 as well, it will only take few days or a= month, to
>>>> draft and submit so why leave it old-documents with old >>>> considerations? Please advise,
>>>>
>>>> Abdussalam Baryun
>>>> University of Glamorgan, UK.
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>
>>
>> --
>> Regards,
>> Charlie P.
>>
>>
>

--047d7b86edf653bb8004c637cb25-- From ietf@thomasclausen.org Wed Aug 1 10:44:27 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC95011E8303 for ; Wed, 1 Aug 2012 10:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXHeTLqX6Lnq for ; Wed, 1 Aug 2012 10:44:20 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAC311E817B for ; Wed, 1 Aug 2012 10:44:07 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 09CEFA3A89 for ; Wed, 1 Aug 2012 10:44:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4B52B1C9E23; Wed, 1 Aug 2012 10:44:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [130.129.87.250] (dhcp-57fa.meeting.ietf.org [130.129.87.250]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 0CA271C9E22; Wed, 1 Aug 2012 10:44:06 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-EB02A763-98BC-40EE-8E31-5064960CCC9C Message-Id: X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Wed, 1 Aug 2012 10:45:12 -0700 To: Joseph Macker Cc: manet , Abdussalam Baryun Subject: Re: [manet] Propose update RFC2501 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:44:28 -0000 --Apple-Mail-EB02A763-98BC-40EE-8E31-5064960CCC9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 (which I also already did, I think) --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees On 1 Aug 2012, at 10:40, Joseph Macker wrote: > I responded to you already that I thought it was a bad idea. >=20 > On Wed, Aug 1, 2012 at 12:27 AM, Abdussalam Baryun wrote: > Hi Joe, >=20 > This is a reminder to a post I send before you as one author of > RFC2501, and the below. I need your respond to my suggestion. I > thought you will discuss it in the meeting but you did not mention it, > please comment/advise, >=20 > AB > =3D=3D=3D=3D >=20 > On 7/4/12, Abdussalam Baryun wrote: > > Hi All, > > > > I want to propose draft-ietf work to be done on update the RFC2501, > > which I don't mind doing, on the following issues: > > > > 1- to include all active MANET routing RFCs as describing its network > > characteristics and its network context applicability, as mentioned by > > section-6. > > 2- to include the RFC5444 characteristics, or benefits to MANET > > performance. > > 3- to include NHDP RFC6130. > > 4- IPv6 considerations > > 5- Add more information in characteristic section on issue of > > reliability and scalability. > > > > RFC2501> 3. Characteristics of MANETs > > MANETs have several salient characteristics: > > AB>Add> 5) issue of variable E2E delay and node disconnecting from > > MANET. > > AB> suggest> to consider LLN > > > > 2501> 5. IP-Layer Mobile Routing > > AB> interfaces as physical layer technology, what about interfaces as > > logical? in some other parts we read wireless interface > > > > 2501> 5>Future interoperability may be achieved using mechanisms other t= han > > mobile IP. > > AB> Are we there, could we answer to add some? > > > > 2501>5>Supporting these features appears only to require identifying > > host and router interfaces with IP addresses, identifying a router > > with a separate Router ID, and permitting routers to have multiple > > wired and wireless interfaces. > > AB> replace "host and router" with " router" as it was done in DYMO and > > OLSRv2 > > > > 2501> 4) Proactive operation: The flip-side of demand-based operation. > > AB> not clear > > > > 2501> Section 6.7, Duplex link and bidirectional link > > AB> why we use *duplex* with *link*, duplex is related to the > > interface system more than the link, so I recommend only using > > *bidirectional-link* and replace duplex-link. > > > > 2501> The following is a list of quantitative metrics that can be used t= o > > assess the performance of any routing protocol. > > AB> add examples of new metric used in industry or by active manet > > protocols > > > > 2501> 7. Security Considerations > > AB> Needs to be amended to consider new techniques > > > > The purpose of the proposed update, is first because RFC2501 is a > > reference to many new RFCs and that updates directs progress designs. > > Please note that I will not do this work until most active participant > > agree, thanking you, > > > > Best Regards > > Abdussalam > > > > +++++++++++++++++++++++++++++++++++++++++++++++++++++ > > On 6/21/12, Charles E. Perkins wrote: > >> > >> Hello Abdussalam, > >> > >> I didn't see what part of RFC 2501 needed to be revised. > >> Do you have a specific proposal? I think that, before you > >> could expect any discussion on revising that document, > >> you would have to point out what part or parts need > >> work. > >> > >> Regards, > >> Charlie P. > >> > >> On 6/21/2012 9:10 AM, Abdussalam Baryun wrote: > >>>> Could we Update RFC2501? > >>> I see that RFC2501 some how defines MANET technologies, which will be > >>> a good reference in the draft I am writting of L2 subnets, but maybe > >>> RFC2501 is enough for the protocols, and no need for a new draft. > >>> However, that will depend on the WG discussion and decision :) > >>> > >>> I got no answer of the question so far, therefore, I will propose it > >>> to be discussed in the next meeting IETF 84. > >>> > >>> AB > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >>> On 6/6/12, Abdussalam Baryun wrote: > >>>> Hi Folks, > >>>> > >>>> the RFC2501 is the best RFC I read and I like it because it is easy t= o > >>>> read, understandable, and covers solid issues of MANET. I hope the > >>>> authors give us a feedback if they want to make new one as Version 2.= > >>>> > >>>> I see that it is old (1999), and it may be interesting to update it > >>>> some how, I hope the authors can update its issues and evaluation, no= w > >>>> we got new RFCs and industries have new needs than 90s, it does not > >>>> cover different devices constraints as sensors and LLNs, and IPv6, > >>>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 are > >>>> getting renew versions. > >>>> > >>>> As I can see OLSRv2 and AODVv2 are going in progress, why we don't tr= y > >>>> to update RFC2501 as well, it will only take few days or a month, to > >>>> draft and submit so why leave it old-documents with old > >>>> considerations? Please advise, > >>>> > >>>> Abdussalam Baryun > >>>> University of Glamorgan, UK. > >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > >>>> > >>> _______________________________________________ > >>> manet mailing list > >>> manet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/manet > >>> > >> > >> > >> -- > >> Regards, > >> Charlie P. > >> > >> > > >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-EB02A763-98BC-40EE-8E31-5064960CCC9C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
+1 (which I also already d= id, I think)

-- 
Thomas Heide Clausen
<= a href=3D"http://www.thomasclausen.org/">http://www.thomasclausen.org/

"Any simple problem can be made insoluble if enough m= eetings are held to
 discuss it."
   -- M= itchell's Law of Committees


On 1 Au= g 2012, at 10:40, Joseph Macker <jp= macker@gmail.com> wrote:

I responded to you already that I thought it was a bad idea.
<= br>
On Wed, Aug 1, 2012 at 12:27 AM, Abdussalam Ba= ryun <abdussalambaryun@gmail.com> wrote:
Hi Joe,

This is a reminder to a post I send before you as one author of
RFC2501, and the below. I need your respond to my suggestion. I
thought you will discuss it in the meeting but you did not mention it,
please comment/advise,

AB
=3D=3D=3D=3D

On 7/4/12, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
> Hi All,
>
> I want to propose draft-ietf work to be done on update the RFC2501,
= > which I don't mind doing, on the following issues:
>
> 1- to include all active MANET routing RFCs as describing its network > characteristics and its network context applicability, as mentioned by<= br> > section-6.
> 2- to include the RFC5444 characteristics, or benefits to MANET
> performance.
> 3- to include NHDP RFC6130.
> 4- IPv6 considerations
> 5- Add more information in characteristic section on issue of
> reliability and scalability.
>
> RFC2501> 3. Characteristics of MANETs
> MANETs have several salient characteristics:
> AB>Add>    5) issue of variable E2E delay and node disc= onnecting from
> MANET.
> AB> suggest> to consider LLN
>
> 2501> 5. IP-Layer Mobile Routing
> AB> interfaces as physical layer technology, what about interfaces a= s
> logical? in some other parts we read wireless interface
>
> 2501> 5>Future interoperability may be achieved using mechanisms o= ther than
> mobile IP.
> AB> Are we there, could we answer to add some?
>
> 2501>5>Supporting these features appears only to require identify= ing
> host and router interfaces with IP addresses, identifying a router
> with a separate Router ID, and permitting routers to have multiple
> wired and wireless interfaces.
> AB> replace "host and router" with " router" as it was done in DYMO a= nd
> OLSRv2
>
> 2501>  4) Proactive operation: The flip-side of demand-based op= eration.
> AB> not clear
>
> 2501> Section 6.7,   Duplex link and bidirectional link
> AB> why we use *duplex* with *link*, duplex is related to the
> interface system more than the link, so I recommend only using
> *bidirectional-link* and replace duplex-link.
>
> 2501> The following is a list of quantitative metrics that can be us= ed to
> assess the performance of any routing protocol.
> AB> add examples of new metric used in industry or by active manet > protocols
>
> 2501> 7. Security Considerations
> AB> Needs to be amended to consider new techniques
>
> The purpose of the proposed update, is first because RFC2501 is a
> reference to many new RFCs and that updates directs progress designs. > Please note that I will not do this work until most active participant<= br> > agree, thanking you,
>
> Best Regards
> Abdussalam
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++
> On 6/21/12, Charles E. Perkins <charliep@computer.org> wrote:
>>
>> Hello Abdussalam,
>>
>> I didn't see what part of RFC 2501 needed to be revised.
>> Do you have a specific proposal?  I think that, before you
= >> could expect any discussion on revising that document,
>> you would have to point out what part or parts need
>> work.
>>
>> Regards,
>> Charlie P.
>>
>> On 6/21/2012 9:10 AM, Abdussalam Baryun wrote:
>>>> Could we Update RFC2501?
>>> I see that RFC2501 some how defines MANET technologies, which w= ill be
>>> a good reference in the draft I am writting of L2 subnets, but m= aybe
>>> RFC2501 is enough for the protocols, and no need for a new draf= t.
>>> However, that will depend on the WG discussion and decision :)<= br> >>>
>>> I got no answer of the question so far, therefore, I will propo= se it
>>> to be discussed in the next meeting IETF 84.
>>>
>>> AB
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
>>> On 6/6/12, Abdussalam Baryun<abdussalambaryun@gmail.com>  wrote:
>>>> Hi Folks,
>>>>
>>>> the RFC2501 is the best RFC I read and I like it because it= is easy to
>>>> read, understandable, and covers solid issues of MANET. I h= ope the
>>>> authors give us a feedback if they want to make new one as V= ersion 2.
>>>>
>>>> I see that it is old (1999), and it may be interesting to u= pdate it
>>>> some how, I hope the authors can update its issues and eval= uation, now
>>>> we got new RFCs and industries have new needs than 90s, it d= oes not
>>>> cover different devices constraints as sensors and LLNs, an= d IPv6,
>>>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3= 626 are
>>>> getting renew versions.
>>>>
>>>> As I can see OLSRv2 and AODVv2 are going in progress, why w= e don't try
>>>> to update RFC2501 as well, it will only take few days or a m= onth, to
>>>> draft and submit so why leave it old-documents with old
= >>>> considerations? Please advise,
>>>>
>>>> Abdussalam Baryun
>>>> University of Glamorgan, UK.
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>
>>
>> --
>> Regards,
>> Charlie P.
>>
>>
>

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-EB02A763-98BC-40EE-8E31-5064960CCC9C-- From sratliff@cisco.com Wed Aug 1 10:45:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EE211E830C for ; Wed, 1 Aug 2012 10:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdCsDLaNcy8l for ; Wed, 1 Aug 2012 10:45:37 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B66AC11E8347 for ; Wed, 1 Aug 2012 10:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=14892; q=dns/txt; s=iport; t=1343843104; x=1345052704; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VgeUaZqFCBKFGDk9OTjbDsSieJUuYgGWycOMJPdU0Xo=; b=NT7MQTmgvceZ2i60NxKlUmORoUvhiQF9Q5JedP8mV1AKiwnlsZJi1vhB XlsES1qyqc/X/g7ibXt6fN3vHn23Qjrcaf/As2rolGAYkkDf8DWi5RgBg IFGnbnBiHd9L01ZgR4RW7B7yvSb57SJNboDSkLhTW4fqGEknrpZe3u6o4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANppGVCtJXG8/2dsb2JhbABFuRCBB4IgAQEBAwEBAQEPAUIWAwMIBQcEAgEIDgMEAQEBJwchBgsUCQgCBA4FCQsOh1wDBgYLnGOWdA2JTopiZwUFCgcHhgdgA4gYi1yBU4EUiXaDHYFmgl+BVgk X-IronPort-AV: E=Sophos;i="4.77,695,1336348800"; d="scan'208";a="107561862" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 01 Aug 2012 17:45:03 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q71Hj35x001659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 17:45:03 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.180]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 12:45:03 -0500 From: "Stan Ratliff (sratliff)" To: Rex Buddenberg Thread-Topic: [manet] Some LLNs are NOT MANETs Thread-Index: AQHNb+i2NIMVZDkBeEWaaQkwSTqYtJdFaAmAgAAPqoCAAAsIAIAADAWA Date: Wed, 1 Aug 2012 17:45:02 +0000 Message-ID: <959D9FFE-0636-4592-B21A-77451A3EAC78@cisco.com> References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> <1343840520.981.874.camel@localhost.localdomain> In-Reply-To: <1343840520.981.874.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.209.17] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.006 x-tm-as-result: No--59.661000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , manet , Abdussalam Baryun Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:45:40 -0000 Rex,=20 Good point. I agree.=20 Regards, Stan On Aug 1, 2012, at 1:02 PM, Rex Buddenberg wrote: > I think a topology differentiation is worthwhile ... hasn't appeared in > this thread. >=20 > Most of the 'mobility' discussion in the commercial world has had the > radio network at the fringe -- in a LAN role. But the problems (my > instrumented ambulance example is good for this) that we need to grow > into are ones where the radio network is in a WAN position in the > internetwork -- it's a router-router problem, not a last-router-to-end > system one. =20 >=20 >=20 >=20 >=20 > On Wed, 2012-08-01 at 16:22 +0000, Stan Ratliff (sratliff) wrote: >> Precisely, Chris.=20 >>=20 >> I've come to view MANETs more and more in the terms of an "opportunistic= network". By that, I mean a network with a fairly large amount of dynamism= , and also a network that contains heterogeneity of links (e.g., different = radio types, and/or some wired portions). The challenge of these networks i= s to opportunistically (and maximally) use the resources available to it at= any point in time.=20 >>=20 >> And at least for me (and I know this will draw some fire in return), ano= ther distinction in MANET as opposed to LLN is a greater requirement for pe= er-to-peer (node-to-node) communication, From what I've seen of LLN deploym= ents (and I'm no expert), they tend to have more of a "multiple source/sing= le sink" model for the data flow. >>=20 >> Again, just one opinion.=20 >>=20 >> Regards, >> Stan >>=20 >> On Aug 1, 2012, at 11:26 AM, Dearlove, Christopher (UK) wrote: >>=20 >>> The statement that MANETs refers only to networks with physical mobilit= y is simply false. While the expansion of the acronym might suggest that, i= n fact MANET has become a term of art, and that art includes many networks = with some or all nodes that are not physically moving. >>>=20 >>> --=20 >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cent= re, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Abdussalam Baryun >>> Sent: 01 August 2012 14:21 >>> To: C Chauvenet >>> Cc: manet >>> Subject: Re: [manet] Some LLNs are NOT MANETs >>>=20 >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>>=20 >>> Hi C=E9dric, >>>=20 >>> Ok we can discuss efficiently when we read the documents (production >>> of such WG)as you agreed. >>>=20 >>>> When you say "IMHO, as long we have a ROLL WG in IETF we need to forwa= rd >>>> work to it which has no mobility behavior", do you mean that the diffe= rence >>>> between ROLL and MANET is limited to mobility considerations ? >>>=20 >>> *Mobility* It is the mostly difference clearly spoted between the >>> documents produced by the both WGs, also the name MANET starts with >>> Mobile, the word mobile is not equal to change/dynamic. So MANET >>> refers to mobile node or mobile network, which means location change >>> *NOT* topology change/dynamic. In the old days there was no ROLL WG so >>> MANET WG was doing the job. >>>=20 >>>>=20 >>>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC5= 867 >>>> all include the usual IoT constraints : Memory, Processing, Power, Bat= tery, >>>> Cost and Size of device. >>>> RFC5673 does not mention explicitly processing and size constraints, b= ut >>>> mention all the others. >>>>=20 >>>=20 >>> Ok, >>>=20 >>>> RFC 2501 speak about energy and power, as you previously mentioned, bu= t does >>>> not say something on the following constraints : Memory, Processing, = Cost >>>> and Size. >>>=20 >>> Yes your right, but be careful RFC2501 does not exclude thoes >>> constraints either. However, if the MANET network has some nodes with >>> constraints but clearly mobility is the main constraint. >>>=20 >>>>=20 >>>> Do you think that these constraints are in the MANET scope ? >>>> I guess that they may be (obviously for Cost), but not in the same ord= er of >>>> magnitude as the type of devices described in the requirements RFC of = ROLL. >>>=20 >>> Really don't mind either way for MANET WG, and will think that the WG >>> community wants it in between In-Scope and Out-Scope, that may be >>> strange but seems that is what is happening as I read documents. Out >>> of IETF, MANET is mostly understood as mobile nodes connecting, not >>> LLNs. >>>=20 >>> Overall, IMHO, in the end it is the decision of the IETF community to >>> decide of any new idea or any I-D acceptance/adoption, but for the WG >>> it MAY take over a WORK as an IETF I-D, but it may not be successful >>> to convince the IETF community to continue the work or make it become >>> a RFC, we always have to see through to make the work efforts flow >>> successfully. We do not forget that many participants work in both >>> WGs. >>>=20 >>> Regards >>> Abdussalam >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> On 8/1/12, C Chauvenet wrote: >>>> Hi, >>>>=20 >>>> Thank you for your answer, >>>>=20 >>>> See inline. >>>>=20 >>>> Le 1 ao=FBt 2012 =E0 13:41, Abdussalam Baryun a =E9crit : >>>>=20 >>>>> Hi C=E9dric, >>>>>=20 >>>>> I think the RFC2501 is more important than the WG charter, because th= e >>>>> charter MAY change but RFCs never changes (only can be updated, >>>>> obsoleted or replaced). >>>>=20 >>>> Good Point, 100% agree. >>>>=20 >>>>> So far now all MANET-protocols are refering to >>>>> RFC2501 which is good and SHOULD continue, and I like this referencin= g >>>>> to documents (even if they are old or expired) not referencing to >>>>> charters, because for example, if in a journal paper we reference to >>>>> the charter of MANET WG or ROLL WG the information is not solid like >>>>> if you reference a published document (publisher date), but still we >>>>> can reference the charter as web reference sited date. >>>>>=20 >>>>> I read some paper that reference sited web documents but they may be >>>>> not valid and cannot be read for some reason. Therefore, IMHO, we nee= d >>>>> to stick to the following document to make a right decision in >>>>> definitions: >>>>>=20 >>>>> 1) [RFC2501] for MANETs. (published in 1999) >>>>> 2) [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] for LLNs. >>>>> (published in 2009) >>>>=20 >>>> I think they are good references to build some arguments into this >>>> discussion. >>>>=20 >>>>>=20 >>>>> Low power was indicated in RFC2501 in section 5.1 as >>>> constraints> and also the word *sink*, in page 7 you read >>>> for energy conservation>. IMHO, as long we have a ROLL WG in IETF we >>>>> need to forward work to it which has no mobility behavior. Delegation >>>>> will help make work flowing and more focused. >>>>=20 >>>> When you say "IMHO, as long we have a ROLL WG in IETF we need to forwa= rd >>>> work to it which has no mobility behavior", do you mean that the diffe= rence >>>> between ROLL and MANET is limited to mobility considerations ? >>>>=20 >>>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC5= 867 >>>> all include the usual IoT constraints : Memory, Processing, Power, Bat= tery, >>>> Cost and Size of device. >>>> RFC5673 does not mention explicitly processing and size constraints, b= ut >>>> mention all the others. >>>>=20 >>>> RFC 2501 speak about energy and power, as you previously mentioned, bu= t does >>>> not say something on the following constraints : Memory, Processing, = Cost >>>> and Size. >>>>=20 >>>> Do you think that these constraints are in the MANET scope ? >>>> I guess that they may be (obviously for Cost), but not in the same ord= er of >>>> magnitude as the type of devices described in the requirements RFC of = ROLL. >>>>=20 >>>> Regards, >>>>=20 >>>> C=E9dric. >>>>=20 >>>>>=20 >>>>> Regards >>>>> AB >>>>> =3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>>> On 8/1/12, C Chauvenet wrote: >>>>>> Hi, >>>>>>=20 >>>>>> This is an interesting discussion. >>>>>>=20 >>>>>> My understanding is that both MANET and ROLL considers lossy/dynamic >>>>>> links >>>>>> in the way described in the MANET charter : "static and dynamic >>>>>> topologies >>>>>> with increased dynamics due to node motion or other factors." I also >>>>>> agree >>>>>> that dynamicity of links is not hard wired to node mobility. >>>>>>=20 >>>>>> So, in the LLN Vs MANET debate, I think they share the "N" for Netwo= rks, >>>>>> and >>>>>> the 2nd "L" for Lossy. >>>>>> So the remaining point is the first L, meaning Low Power. >>>>>>=20 >>>>>> Low Power requirements is explicit in the ROLL charter and not menti= oned >>>>>> at >>>>>> all in the MANET charter. >>>>>> Is the power efficiency consideration the big difference between ROL= L >>>>>> and >>>>>> MANET ? >>>>>>=20 >>>>>> C=E9dric. >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part= de >>>>>> Abdussalam Baryun >>>>>> Envoy=E9 : mercredi 1 ao=FBt 2012 09:22 >>>>>> =C0 : Henning Rogge >>>>>> Cc : roll; manet >>>>>> Objet : [Roll] Some LLNs are NOT MANETs >>>>>>=20 >>>>>> Hi Henning, >>>>>>=20 >>>>>> I am about to say many LLNs are NOT MANETs but it seems like the mar= ket >>>>>> or >>>>>> community will decide the outcome, but surly that some LLNs are NOT >>>>>> MANETs. >>>>>>=20 >>>>>>> Could you state an example what would be considered a LLN but not a >>>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>>=20 >>>>>> I not totally agree with that, because we need to be considering bot= h >>>>>> NETs >>>>>> use case and applicability in the vision of the different WGs (MANET= and >>>>>> ROLL). There are many examples we can find them in the [RFC2501] for >>>>>> MANETs >>>>>> characteristics and applicability, and for LLNs characteristics in >>>>>> [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs >>>>>> requirements. That is why I suggested before that >>>>>> OLSRv2 and AODVv2 should mention their applicability to LLN if they = do. >>>>>> They >>>>>> just refer to RFC2501, but RFC2501 is OLD and does not mention LLN b= ut >>>>>> describes the meaning. The authors of RFC2501 still not responded to= my >>>>>> update suggestions. >>>>>>=20 >>>>>> I understood from one discussion in MANET WG that few don't have tim= e to >>>>>> read many pages of documents, so that is why I suggested to have >>>>>> terminology >>>>>> I-D [1] as we have ROLL terminology [ROLL] . I also taken initiative= to >>>>>> make >>>>>> new draft of MANET subnet technologies which include only related L= LNs >>>>>> [AB2]. >>>>>>=20 >>>>>> Therefore, I will add the definition for MANET and LLN into my >>>>>> manet-terminology draft [AB1] (propose that authors of [ROLL] define= LLN >>>>>> more details) to assist discussions as it is proved now in the list = that >>>>>> there still is problems in definitions in MANET WG or in some I-D >>>>>> editorial >>>>>> content. >>>>>>=20 >>>>>> [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >>>>>> [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >>>>>> [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt >>>>>>=20 >>>>>> Best Wishes >>>>>>=20 >>>>>> Abdussalam Baryun >>>>>> University of Glamorgan, UK >>>>>>=20 >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>> On 7/31/12, Henning Rogge wrote: >>>>>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>>>>>> subject: Re: [manet] Discussing LOADng suggestions >>>>>>> wrote: >>>>>>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, b= ut >>>>>>>> then changed its direction to MANET [3]. However, please note that >>>>>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >>>>>>>> said, LOADng SHOULD specfy where is its limits. Then we can discus= s >>>>>>>> adoption. >>>>>>>=20 >>>>>>> Could you state an example what would be considered a LLN but not a >>>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>>>=20 >>>>>>> Henning Rogge >>>>>>>=20 >>>>>>> -- >>>>>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>>>>> billions of percent in a tiny fraction of a second. Of course, that >>>>>>> was before the present government." >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> Roll mailing list >>>>>> Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ******************************************************************** >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 From sratliff@cisco.com Wed Aug 1 10:46:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED6111E8196 for ; Wed, 1 Aug 2012 10:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iK5qtiwWD8QM for ; Wed, 1 Aug 2012 10:45:59 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2900711E8300 for ; Wed, 1 Aug 2012 10:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=14592; q=dns/txt; s=iport; t=1343843159; x=1345052759; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=n6HF9yf/bdsYhOqEQylOi8RimkzIoMuy+as4+XCRg54=; b=KCYdKC1N0MDWI6Sc6q9IbsAWzARYabA20b6kWejkeKHPYaw5WWL7GzkR PX2mpXhFR3jy1N68Ei9Oc7P2tnX4rph2fPVNARbkeIymNTEe84gGG9Jvx suQ80UcAh8Sb0sfHmp0giLctZc2ONzf7GoRmxJFA1dqmeb4XFQE/pr5rD Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHxqGVCtJV2Z/2dsb2JhbABFuRCBB4IgAQEBBAEBAQ8BWwsQAgEIDgonByEGCxQRAgQOBSKHXAMMC5xilnQNiUoEimJnhilgA4gYi1yBU4sKgx2BZoJf X-IronPort-AV: E=Sophos;i="4.77,695,1336348800"; d="scan'208,217";a="107544194" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 01 Aug 2012 17:45:58 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q71HjvmF003410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 17:45:57 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.180]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 12:45:56 -0500 From: "Stan Ratliff (sratliff)" To: Joseph Macker Thread-Topic: [manet] Propose update RFC2501 Thread-Index: AQHNWiEyQ3V4scRHnk+N4ix+dji32pdFDdUAgACrRoCAAAF0gA== Date: Wed, 1 Aug 2012 17:45:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.209.17] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.006 x-tm-as-result: No--51.966200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_A65B90C9E4894B69B10BE98A60BEB1CBciscocom_" MIME-Version: 1.0 Cc: manet , Abdussalam Baryun Subject: Re: [manet] Propose update RFC2501 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:46:01 -0000 --_000_A65B90C9E4894B69B10BE98A60BEB1CBciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I concur with Joe's opinion. This update is a bad idea. Stan On Aug 1, 2012, at 1:40 PM, Joseph Macker wrote: I responded to you already that I thought it was a bad idea. On Wed, Aug 1, 2012 at 12:27 AM, Abdussalam Baryun > wrote: Hi Joe, This is a reminder to a post I send before you as one author of RFC2501, and the below. I need your respond to my suggestion. I thought you will discuss it in the meeting but you did not mention it, please comment/advise, AB =3D=3D=3D=3D On 7/4/12, Abdussalam Baryun > wrote: > Hi All, > > I want to propose draft-ietf work to be done on update the RFC2501, > which I don't mind doing, on the following issues: > > 1- to include all active MANET routing RFCs as describing its network > characteristics and its network context applicability, as mentioned by > section-6. > 2- to include the RFC5444 characteristics, or benefits to MANET > performance. > 3- to include NHDP RFC6130. > 4- IPv6 considerations > 5- Add more information in characteristic section on issue of > reliability and scalability. > > RFC2501> 3. Characteristics of MANETs > MANETs have several salient characteristics: > AB>Add> 5) issue of variable E2E delay and node disconnecting from > MANET. > AB> suggest> to consider LLN > > 2501> 5. IP-Layer Mobile Routing > AB> interfaces as physical layer technology, what about interfaces as > logical? in some other parts we read wireless interface > > 2501> 5>Future interoperability may be achieved using mechanisms other th= an > mobile IP. > AB> Are we there, could we answer to add some? > > 2501>5>Supporting these features appears only to require identifying > host and router interfaces with IP addresses, identifying a router > with a separate Router ID, and permitting routers to have multiple > wired and wireless interfaces. > AB> replace "host and router" with " router" as it was done in DYMO and > OLSRv2 > > 2501> 4) Proactive operation: The flip-side of demand-based operation. > AB> not clear > > 2501> Section 6.7, Duplex link and bidirectional link > AB> why we use *duplex* with *link*, duplex is related to the > interface system more than the link, so I recommend only using > *bidirectional-link* and replace duplex-link. > > 2501> The following is a list of quantitative metrics that can be used to > assess the performance of any routing protocol. > AB> add examples of new metric used in industry or by active manet > protocols > > 2501> 7. Security Considerations > AB> Needs to be amended to consider new techniques > > The purpose of the proposed update, is first because RFC2501 is a > reference to many new RFCs and that updates directs progress designs. > Please note that I will not do this work until most active participant > agree, thanking you, > > Best Regards > Abdussalam > > +++++++++++++++++++++++++++++++++++++++++++++++++++++ > On 6/21/12, Charles E. Perkins > wrote: >> >> Hello Abdussalam, >> >> I didn't see what part of RFC 2501 needed to be revised. >> Do you have a specific proposal? I think that, before you >> could expect any discussion on revising that document, >> you would have to point out what part or parts need >> work. >> >> Regards, >> Charlie P. >> >> On 6/21/2012 9:10 AM, Abdussalam Baryun wrote: >>>> Could we Update RFC2501? >>> I see that RFC2501 some how defines MANET technologies, which will be >>> a good reference in the draft I am writting of L2 subnets, but maybe >>> RFC2501 is enough for the protocols, and no need for a new draft. >>> However, that will depend on the WG discussion and decision :) >>> >>> I got no answer of the question so far, therefore, I will propose it >>> to be discussed in the next meeting IETF 84. >>> >>> AB >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>> On 6/6/12, Abdussalam Baryun> wrote: >>>> Hi Folks, >>>> >>>> the RFC2501 is the best RFC I read and I like it because it is easy to >>>> read, understandable, and covers solid issues of MANET. I hope the >>>> authors give us a feedback if they want to make new one as Version 2. >>>> >>>> I see that it is old (1999), and it may be interesting to update it >>>> some how, I hope the authors can update its issues and evaluation, now >>>> we got new RFCs and industries have new needs than 90s, it does not >>>> cover different devices constraints as sensors and LLNs, and IPv6, >>>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 are >>>> getting renew versions. >>>> >>>> As I can see OLSRv2 and AODVv2 are going in progress, why we don't try >>>> to update RFC2501 as well, it will only take few days or a month, to >>>> draft and submit so why leave it old-documents with old >>>> considerations? Please advise, >>>> >>>> Abdussalam Baryun >>>> University of Glamorgan, UK. >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> >> -- >> Regards, >> Charlie P. >> >> > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_A65B90C9E4894B69B10BE98A60BEB1CBciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <3DFEFA7D261B914FB44299001CCF9832@cisco.com> Content-Transfer-Encoding: quoted-printable I concur with Joe's opinion. This update is a bad idea.

Stan

On Aug 1, 2012, at 1:40 PM, Joseph Macker wrote:

I responded to you already that I thought it was = a bad idea.

On Wed, Aug 1, 2012 at 12:27 AM, Abdussalam Bary= un <abdussa= lambaryun@gmail.com> wrote:
Hi Joe,

This is a reminder to a post I send before you as one author of
RFC2501, and the below. I need your respond to my suggestion. I
thought you will discuss it in the meeting but you did not mention it,
please comment/advise,

AB
=3D=3D=3D=3D

On 7/4/12, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
> Hi All,
>
> I want to propose draft-ietf work to be done on update the RFC2501, > which I don't mind doing, on the following issues:
>
> 1- to include all active MANET routing RFCs as describing its network<= br> > characteristics and its network context applicability, as mentioned by=
> section-6.
> 2- to include the RFC5444 characteristics, or benefits to MANET
> performance.
> 3- to include NHDP RFC6130.
> 4- IPv6 considerations
> 5- Add more information in characteristic section on issue of
> reliability and scalability.
>
> RFC2501> 3. Characteristics of MANETs
> MANETs have several salient characteristics:
> AB>Add>    5) issue of variable E2E delay and node dis= connecting from
> MANET.
> AB> suggest> to consider LLN
>
> 2501> 5. IP-Layer Mobile Routing
> AB> interfaces as physical layer technology, what about interfaces = as
> logical? in some other parts we read wireless interface
>
> 2501> 5>Future interoperability may be achieved using mechanisms= other than
> mobile IP.
> AB> Are we there, could we answer to add some?
>
> 2501>5>Supporting these features appears only to require identif= ying
> host and router interfaces with IP addresses, identifying a router
> with a separate Router ID, and permitting routers to have multiple
> wired and wireless interfaces.
> AB> replace "host and router" with " router" as= it was done in DYMO and
> OLSRv2
>
> 2501>  4) Proactive operation: The flip-side of demand-based o= peration.
> AB> not clear
>
> 2501> Section 6.7,   Duplex link and bidirectional link
> AB> why we use *duplex* with *link*, duplex is related to the
> interface system more than the link, so I recommend only using
> *bidirectional-link* and replace duplex-link.
>
> 2501> The following is a list of quantitative metrics that can be u= sed to
> assess the performance of any routing protocol.
> AB> add examples of new metric used in industry or by active manet<= br> > protocols
>
> 2501> 7. Security Considerations
> AB> Needs to be amended to consider new techniques
>
> The purpose of the proposed update, is first because RFC2501 is a
> reference to many new RFCs and that updates directs progress designs.<= br> > Please note that I will not do this work until most active participant=
> agree, thanking you,
>
> Best Regards
> Abdussalam
>
> ++++++++++++++= +++++++++++++++= +++++++++++++++= +++++++++
> On 6/21/12, Charles E. Perkins <charliep@computer.org> wrote:
>>
>> Hello Abdussalam,
>>
>> I didn't see what part of RFC 2501 needed to be revised.
>> Do you have a specific proposal?  I think that, before you >> could expect any discussion on revising that document,
>> you would have to point out what part or parts need
>> work.
>>
>> Regards,
>> Charlie P.
>>
>> On 6/21/2012 9:10 AM, Abdussalam Baryun wrote:
>>>> Could we Update RFC2501?
>>> I see that RFC2501 some how defines MANET technologies, which = will be
>>> a good reference in the draft I am writting of L2 subnets, but= maybe
>>> RFC2501 is enough for the protocols, and no need for a new dra= ft.
>>> However, that will depend on the WG discussion and decision :)=
>>>
>>> I got no answer of the question so far, therefore, I will prop= ose it
>>> to be discussed in the next meeting IETF 84.
>>>
>>> AB
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
>>> On 6/6/12, Abdussalam Baryun<abdussalambaryun@gmail.com>  wrote:
>>>> Hi Folks,
>>>>
>>>> the RFC2501 is the best RFC I read and I like it because i= t is easy to
>>>> read, understandable, and covers solid issues of MANET. I = hope the
>>>> authors give us a feedback if they want to make new one as= Version 2.
>>>>
>>>> I see that it is old (1999), and it may be interesting to = update it
>>>> some how, I hope the authors can update its issues and eva= luation, now
>>>> we got new RFCs and industries have new needs than 90s, it= does not
>>>> cover different devices constraints as sensors and LLNs, a= nd IPv6,
>>>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC= 3626 are
>>>> getting renew versions.
>>>>
>>>> As I can see OLSRv2 and AODVv2 are going in progress, why = we don't try
>>>> to update RFC2501 as well, it will only take few days or a= month, to
>>>> draft and submit so why leave it old-documents with old >>>> considerations? Please advise,
>>>>
>>>> Abdussalam Baryun
>>>> University of Glamorgan, UK.
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>
>>
>> --
>> Regards,
>> Charlie P.
>>
>>
>

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_A65B90C9E4894B69B10BE98A60BEB1CBciscocom_-- From abdussalambaryun@gmail.com Wed Aug 1 10:47:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B59E11E8357 for ; Wed, 1 Aug 2012 10:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.48 X-Spam-Level: X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6tiR0yZTIsG for ; Wed, 1 Aug 2012 10:47:33 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B233911E8355 for ; Wed, 1 Aug 2012 10:47:32 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so7850664vcb.31 for ; Wed, 01 Aug 2012 10:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bhhght0b3u4OAuUhADcggheaML4Rs31muz/NYy101Y8=; b=qEQq37M22wNvsdqqO2UVQUvUJC3FXyKdphLxxsvhIVjTIWDGWvbuOtt/E89j3CzSiH Qh0pzfaI0a/Jm51wefQovwa9OKCYGxft4CG1RLEYesfUPHt2GatfXAlE0djPc1paq1Eo xDKZ6UTjilkYbrCtZLwRmN3BE2eLOMdQwZNkGOvGgdj0QOG2plNdbfmZJ0hTtPul4PD2 HaozwBx33JixvIbpB/SDjD8Netbrlpt2ajE4CEonwMkYgxzjx8imAZsNtk2LxGT8rbyp CUU+T8bjEQb7nEvp9T2ruSzFDP0WA4i9snQxzX8ULkSWraXBUIxrPu28YDjXK7BzgLJ4 QMaQ== MIME-Version: 1.0 Received: by 10.58.128.3 with SMTP id nk3mr6601846veb.9.1343843252019; Wed, 01 Aug 2012 10:47:32 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Wed, 1 Aug 2012 10:47:31 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 19:47:31 +0200 Message-ID: From: Abdussalam Baryun To: Joseph Macker Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Propose update RFC2501 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:47:34 -0000 Hi Joe, Thanks for your comment. could I know the reason please, for the future, AB == On 8/1/12, Joseph Macker wrote: > I responded to you already that I thought it was a bad idea. > > On Wed, Aug 1, 2012 at 12:27 AM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> Hi Joe, >> >> This is a reminder to a post I send before you as one author of >> RFC2501, and the below. I need your respond to my suggestion. I >> thought you will discuss it in the meeting but you did not mention it, >> please comment/advise, >> >> AB >> ==== >> >> On 7/4/12, Abdussalam Baryun wrote: >> > Hi All, >> > >> > I want to propose draft-ietf work to be done on update the RFC2501, >> > which I don't mind doing, on the following issues: >> > >> > 1- to include all active MANET routing RFCs as describing its network >> > characteristics and its network context applicability, as mentioned by >> > section-6. >> > 2- to include the RFC5444 characteristics, or benefits to MANET >> > performance. >> > 3- to include NHDP RFC6130. >> > 4- IPv6 considerations >> > 5- Add more information in characteristic section on issue of >> > reliability and scalability. >> > >> > RFC2501> 3. Characteristics of MANETs >> > MANETs have several salient characteristics: >> > AB>Add> 5) issue of variable E2E delay and node disconnecting from >> > MANET. >> > AB> suggest> to consider LLN >> > >> > 2501> 5. IP-Layer Mobile Routing >> > AB> interfaces as physical layer technology, what about interfaces as >> > logical? in some other parts we read wireless interface >> > >> > 2501> 5>Future interoperability may be achieved using mechanisms other >> than >> > mobile IP. >> > AB> Are we there, could we answer to add some? >> > >> > 2501>5>Supporting these features appears only to require identifying >> > host and router interfaces with IP addresses, identifying a router >> > with a separate Router ID, and permitting routers to have multiple >> > wired and wireless interfaces. >> > AB> replace "host and router" with " router" as it was done in DYMO and >> > OLSRv2 >> > >> > 2501> 4) Proactive operation: The flip-side of demand-based operation. >> > AB> not clear >> > >> > 2501> Section 6.7, Duplex link and bidirectional link >> > AB> why we use *duplex* with *link*, duplex is related to the >> > interface system more than the link, so I recommend only using >> > *bidirectional-link* and replace duplex-link. >> > >> > 2501> The following is a list of quantitative metrics that can be used >> > to >> > assess the performance of any routing protocol. >> > AB> add examples of new metric used in industry or by active manet >> > protocols >> > >> > 2501> 7. Security Considerations >> > AB> Needs to be amended to consider new techniques >> > >> > The purpose of the proposed update, is first because RFC2501 is a >> > reference to many new RFCs and that updates directs progress designs. >> > Please note that I will not do this work until most active participant >> > agree, thanking you, >> > >> > Best Regards >> > Abdussalam >> > >> > +++++++++++++++++++++++++++++++++++++++++++++++++++++ >> > On 6/21/12, Charles E. Perkins wrote: >> >> >> >> Hello Abdussalam, >> >> >> >> I didn't see what part of RFC 2501 needed to be revised. >> >> Do you have a specific proposal? I think that, before you >> >> could expect any discussion on revising that document, >> >> you would have to point out what part or parts need >> >> work. >> >> >> >> Regards, >> >> Charlie P. >> >> >> >> On 6/21/2012 9:10 AM, Abdussalam Baryun wrote: >> >>>> Could we Update RFC2501? >> >>> I see that RFC2501 some how defines MANET technologies, which will be >> >>> a good reference in the draft I am writting of L2 subnets, but maybe >> >>> RFC2501 is enough for the protocols, and no need for a new draft. >> >>> However, that will depend on the WG discussion and decision :) >> >>> >> >>> I got no answer of the question so far, therefore, I will propose it >> >>> to be discussed in the next meeting IETF 84. >> >>> >> >>> AB >> >>> ===================================================== >> >>> On 6/6/12, Abdussalam Baryun wrote: >> >>>> Hi Folks, >> >>>> >> >>>> the RFC2501 is the best RFC I read and I like it because it is easy >> >>>> to >> >>>> read, understandable, and covers solid issues of MANET. I hope the >> >>>> authors give us a feedback if they want to make new one as Version >> >>>> 2. >> >>>> >> >>>> I see that it is old (1999), and it may be interesting to update it >> >>>> some how, I hope the authors can update its issues and evaluation, >> >>>> now >> >>>> we got new RFCs and industries have new needs than 90s, it does not >> >>>> cover different devices constraints as sensors and LLNs, and IPv6, >> >>>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 are >> >>>> getting renew versions. >> >>>> >> >>>> As I can see OLSRv2 and AODVv2 are going in progress, why we don't >> >>>> try >> >>>> to update RFC2501 as well, it will only take few days or a month, to >> >>>> draft and submit so why leave it old-documents with old >> >>>> considerations? Please advise, >> >>>> >> >>>> Abdussalam Baryun >> >>>> University of Glamorgan, UK. >> >>>> ========================================================= >> >>>> >> >>> _______________________________________________ >> >>> manet mailing list >> >>> manet@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/manet >> >>> >> >> >> >> >> >> -- >> >> Regards, >> >> Charlie P. >> >> >> >> >> > >> > From yi.jiazi@gmail.com Wed Aug 1 11:53:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B2C11E809B for ; Wed, 1 Aug 2012 11:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdVqzebM-9k5 for ; Wed, 1 Aug 2012 11:53:14 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 63EBD11E808A for ; Wed, 1 Aug 2012 11:53:14 -0700 (PDT) Received: by ggnc4 with SMTP id c4so8279888ggn.31 for ; Wed, 01 Aug 2012 11:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=NfxIErSGOxba7dpFXKuL2qSKuheLuazdQMcEYCyFLzk=; b=J6fnH6tsYW+ofmqAp9tfqHvQkDXXmxk5xIau7FLxGKVnkv8l7IyxRArF+YUouTV6kF l+bmmJB4+RWIHJHElsWmQ8iRF05/7LxtckAzUr7WGyTwn+IKQT4lwnZODQy4u4Ap9TJv JdEske9Rp/1j3VL0Wc4tlPsEx3EsjM4V1tuOEEi0fJmam1OagdCIGBFVhR2rFaWB/YK2 /OZOPbSoe9XNT1/9p35gnogIjhb/fUTV4Gy0enXA1JBRqVxXbFZ9CpkjM856uDS+MyAz +78LMOiCmHFE9btrmvaKGngwl9vyECibhpTFZPdVF1J/KoQpsKuBPC3rEo2ef5AHj1Ws hAnQ== Received: by 10.66.9.2 with SMTP id v2mr41783202paa.65.1343847193276; Wed, 01 Aug 2012 11:53:13 -0700 (PDT) Received: from [208.181.207.220] ([64.114.255.126]) by mx.google.com with ESMTPS id qb10sm3091264pbc.21.2012.08.01.11.53.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 11:53:12 -0700 (PDT) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_7001C70D-21AD-41F7-BCEB-3E745ECF6C8C" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Jiazi YI In-Reply-To: Date: Wed, 1 Aug 2012 11:53:13 -0700 Message-Id: <2C6647B8-18F9-4039-B1E2-5371E4F27EF7@jiaziyi.com> References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1485) Cc: manet , "Velt, R. \(Ronald\) in 't" Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:53:16 -0000 --Apple-Mail=_7001C70D-21AD-41F7-BCEB-3E745ECF6C8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi,=20 please check inline: On Aug 1, 2012, at 12:41 AM, Abdussalam Baryun = wrote: > Hi Ulrich, >=20 > comments in lines: >>>> According to MANET charter, >>>>=20 >>>> The purpose of the MANET working group is to standardize IP routing >>>> protocol functionality suitable for wireless routing application >>>> within >>>> both static and dynamic topologies with increased dynamics due to = node >>>> motion or other factors. >>>=20 >>> Strange wording, in my opinion. It seems to me that if the network >>> _topology_ is truly static, you do not need a routing protocol at = all. >>=20 >> I agree. >>=20 >=20 > I like the wording in the charter, but it MAY need to be more clear to > distinguish between ROLL and MANET charters I think the AD can help us > in this matter. >=20 >>=20 >>=20 >>> (Note that just as the absence of movement does not imply a static >>> topology, a static topology does not imply stationary nodes). >>>=20 >>>>=20 >>>> So I don't think MANETs are defined by mobility, but by "increased >>>> dynamics",which can be due to motion, but also to lossy links. >>>=20 >>> So why aren't they called ANETs? >>=20 >> Or DANET ("dynamic"). It just did not sound as nice when the term was >> created. >>=20 >=20 > I like that *dynamic* word, I agree with it, but we don't forget that > ROLL or LLNs are also DANETs so there SHOULD be differences when we > read through their documents and also in MANET documents which I am > trying to solve by my drafts [1] and [2]. >=20 > I agree that Mobility is the Mostly the concern of MANET (use cases > and applicability), so the *dynamic* is mostly caused by Mobility in > MANET, but in LLNs the *dynamic* is Mostly caused by the Losses or Low > power. I will put that in my terminology draft :) I don't think we can distinguish LLN and MANET by *mobility*. In LLNs, = the mobility can be not only caused by radio, but also physical = movement, such as in wildlife monitoring, water monitoring, etc. You can = find a lot of examples of that.=20 The key point of LLN is "low power", i.e., resource constrained. A = vehicle network is a MANET, but we won't say it's a LLN.=20 Therefore, I would rather say LLN is resource constrained MANET.=20 >=20 > [1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt > [2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >=20 > Best Regards >=20 > Abdussalam Baryun > University of glamorgan, UK >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >>=20 >>>=20 >>> Ronald >>>>=20 >>>> 2012/7/31 Ulrich Herberg : >>>>> MANETs are not defined by mobility. It is rather about very = dynamic >>>>> topologies. Otherwise, community networks such as FunkFeuer would = also >>>>> not be qualified as MANETs. >>>>>=20 >>>>> Ulrich >>>>>=20 >>>>>=20 >>>>> On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal = wrote: >>>>>>=20 >>>>>> The wireless network of "fixed" temperature monitoring sensors = and >>>>>> HVAC controllers in a building. This network is an LLN. Not sure = if >>>>>> it qualifies as a MANET (since nothing is mobile). >>>>>>=20 >>>>>> Thanks >>>>>> Mukul >>>>>>=20 >>>>>> ----- Original Message ----- >>>>>> From: "Henning Rogge" >>>>>> To: "Abdussalam Baryun" >>>>>> Cc: "manet" >>>>>> Sent: Tuesday, July 31, 2012 8:49:08 AM >>>>>> Subject: Re: [manet] Discussing LOADng suggestions >>>>>>=20 >>>>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>>>>> wrote: >>>>>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, >>>>>>> but then changed its direction to MANET [3]. However, please = note >>>>>>> that >>>>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. >>>> That >>>>>>> said, LOADng SHOULD specfy where is its limits. Then we can = discuss >>>>>>> adoption. >>>>>>=20 >>>>>> Could you state an example what would be considered a LLN but not = a >>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>>=20 >>>>>> Henning Rogge >>>>>>=20 >>>>>> -- >>>>>> Steven Hawkings about cosmic inflation: "An increase of billions = of >>>>>> billions of percent in a tiny fraction of a second. Of course, = that >>>>>> was before the present government." >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> This e-mail and its contents are subject to the DISCLAIMER at >>> http://www.tno.nl/emaildisclaimer >>>=20 >>>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_7001C70D-21AD-41F7-BCEB-3E745ECF6C8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
please check = inline:


On Aug 1, 2012, at 12:41 AM, Abdussalam Baryun <abdussalambaryun@gmail.com&= gt; wrote:

Hi Ulrich,

comments in lines:
According to MANET charter,

The purpose of the = MANET working group is to standardize IP routing
protocol = functionality suitable for wireless routing application
within
= both static and dynamic topologies with increased dynamics due to = node
motion or other factors.

Strange wording, = in my opinion. It seems to me that if the network
_topology_ is truly = static, you do not need a routing protocol at all.

I = agree.


I like the wording in the charter, but it = MAY need to be more clear to
distinguish between ROLL and MANET = charters I think the AD can help us
in this = matter.



(Note that just as the absence of movement does not imply = a static
topology, a static topology does not imply stationary = nodes).


So I don't think MANETs are = defined by mobility, but by "increased
dynamics",which can be due to = motion, but also to lossy links.

So why aren't they = called ANETs?

Or DANET ("dynamic"). It just did not = sound as nice when the term was
created.


I = like that *dynamic* word, I agree with it, but we don't forget = that
ROLL or LLNs are also DANETs so there SHOULD be differences when = we
read through their documents and also in MANET documents which I = am
trying to solve by my drafts [1] and [2].

I agree that = Mobility is the Mostly the concern of MANET (use cases
and = applicability), so the *dynamic* is mostly caused by Mobility = in
MANET, but in LLNs the *dynamic* is Mostly caused by the Losses or = Low
power. I will put that in my terminology draft = :)


I don't think we = can distinguish LLN and MANET by *mobility*. In LLNs, the mobility can = be not only caused by radio, but also physical movement, such as in = wildlife monitoring, water monitoring, etc. You can find a lot of = examples of that. 

The key point of LLN is = "low power", i.e., resource constrained. A vehicle network is a MANET, = but we won't say it's a LLN. 

Therefore, I = would rather say LLN is resource constrained = MANET. 



[1] = http= ://www.ietf.org/id/draft-baryun-manet-terminology-00.txt
[2] http:= //www.ietf.org/id/draft-baryun-manet-technology-00.txt

Best = Regards

Abdussalam Baryun
University of glamorgan, = UK

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D




Ronald

2012/7/31 = Ulrich Herberg <ulrich@herberg.name>:
MANETs are not defined by mobility. It is rather = about very dynamic
topologies. Otherwise, community networks such as = FunkFeuer would also
not be qualified as = MANETs.

Ulrich


On Tue, Jul 31, 2012 at 10:32 AM, Mukul = Goyal <mukul@uwm.edu> = wrote:

The wireless network of "fixed" = temperature monitoring sensors and
HVAC controllers in a building. = This network is an LLN. Not sure if
it qualifies as a MANET (since = nothing is mobile).

Thanks
Mukul

----- Original Message = -----
From: "Henning Rogge" <hrogge@googlemail.com>
To:= "Abdussalam Baryun" <abdussalambaryun@gmail.com&= gt;
Cc: "manet" <manet@ietf.org>
Sent: Tuesday, = July 31, 2012 8:49:08 AM
Subject: Re: [manet] Discussing LOADng = suggestions

On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam = Baryun
<abdussalambaryun@gmail.com&= gt; wrote:
IMHO this protocol was intended = as for ROLL WG not for MANET WG,
but then changed its direction to = MANET [3]. However, please note
that
*ONLY* some LLNs are MANETs, = and *ONLY* some MANETs are = LLNs.
That
said, = LOADng SHOULD specfy where is its limits. Then we can = discuss
adoption.

Could you state an example what = would be considered a LLN but not a
MANET. I normally consider LLNs a = subset of what we call MANETs.

Henning Rogge

--
Steven = Hawkings about cosmic inflation: "An increase of billions of
billions = of percent in a tiny fraction of a second. Of course, that
was before = the present = government."
_______________________________________________
manet = mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet
_______________________________________________<= br>manet mailing = list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
<= /blockquote>


_______________________________________________manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

_______________________________= ________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet
This e-mail and its contents are = subject to the DISCLAIMER at
http://www.tno.nl/emaildisclaim= er



__________________________= _____________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail=_7001C70D-21AD-41F7-BCEB-3E745ECF6C8C-- From c.chauvenet@watteco.com Wed Aug 1 12:59:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A974B11E81DD for ; Wed, 1 Aug 2012 12:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXCcx5YVoPsW for ; Wed, 1 Aug 2012 12:59:02 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 4A75811E81CE for ; Wed, 1 Aug 2012 12:59:01 -0700 (PDT) Received: from mail105-co1-R.bigfish.com (10.243.78.238) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.23; Wed, 1 Aug 2012 19:59:01 +0000 Received: from mail105-co1 (localhost [127.0.0.1]) by mail105-co1-R.bigfish.com (Postfix) with ESMTP id 16627A20341; Wed, 1 Aug 2012 19:59:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT005.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zzbb2dI98dI9371Ic89bh542Mc85dhf10Izz1202hzz1033IL8275bh8275dh84d07hz2dh2a8h668h839hd25he5bhf0ah107ahbe3k) Received: from mail105-co1 (localhost.localdomain [127.0.0.1]) by mail105-co1 (MessageSwitch) id 1343851137998864_2615; Wed, 1 Aug 2012 19:58:57 +0000 (UTC) Received: from CO1EHSMHS004.bigfish.com (unknown [10.243.78.244]) by mail105-co1.bigfish.com (Postfix) with ESMTP id F1E06D8004E; Wed, 1 Aug 2012 19:58:57 +0000 (UTC) Received: from DBXPRD0510HT005.eurprd05.prod.outlook.com (157.56.252.165) by CO1EHSMHS004.bigfish.com (10.243.66.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 1 Aug 2012 19:58:57 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.6.25]) by DBXPRD0510HT005.eurprd05.prod.outlook.com ([10.255.67.168]) with mapi id 14.16.0175.005; Wed, 1 Aug 2012 19:58:24 +0000 From: C Chauvenet To: Jiazi YI Thread-Topic: [manet] Discussing LOADng suggestions Thread-Index: AQHNcBbmm+u1REK/lkKRZGyT6FVJyZdFX9QA Date: Wed, 1 Aug 2012 19:58:24 +0000 Message-ID: <4F314E84-0E4A-47C0-A27B-19E40B634B0C@watteco.com> References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> <2C6647B8-18F9-4039-B1E2-5371E4F27EF7@jiaziyi.com> In-Reply-To: <2C6647B8-18F9-4039-B1E2-5371E4F27EF7@jiaziyi.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.57.4] Content-Type: multipart/alternative; boundary="_000_4F314E840E4A47C0A27B19E40B634B0Cwattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: MANET IETF Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 19:59:03 -0000 --_000_4F314E840E4A47C0A27B19E40B634B0Cwattecocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The key point of LLN is "low power", i.e., resource constrained. Agree. I tried to make the difference clear in a previous mail when parsing= the constraints of LLN Vs MANET. A vehicle network is a MANET, but we won't say it's a LLN. Therefore, I would rather say LLN is resource constrained MANET. Agree. I think most of people on the list agree that LLN and MANET are not identic= al, and that, as you mentioned, LLN are more resource constrained. That's why IETF created ROLL in the routing area for these specific needs. http://tools.ietf.org/html/draft-clausen-lln-loadng-05#section-3 states tha= t it target LLN. So I'm a little bit surprised about this submission in MANET. Could you clarify the scope of LOADng regarding the MANET scope ? C=E9dric. Le 1 ao=FBt 2012 =E0 20:53, Jiazi YI a =E9crit : Hi, please check inline: On Aug 1, 2012, at 12:41 AM, Abdussalam Baryun > wrote: Hi Ulrich, comments in lines: According to MANET charter, The purpose of the MANET working group is to standardize IP routing protocol functionality suitable for wireless routing application within both static and dynamic topologies with increased dynamics due to node motion or other factors. Strange wording, in my opinion. It seems to me that if the network _topology_ is truly static, you do not need a routing protocol at all. I agree. I like the wording in the charter, but it MAY need to be more clear to distinguish between ROLL and MANET charters I think the AD can help us in this matter. (Note that just as the absence of movement does not imply a static topology, a static topology does not imply stationary nodes). So I don't think MANETs are defined by mobility, but by "increased dynamics",which can be due to motion, but also to lossy links. So why aren't they called ANETs? Or DANET ("dynamic"). It just did not sound as nice when the term was created. I like that *dynamic* word, I agree with it, but we don't forget that ROLL or LLNs are also DANETs so there SHOULD be differences when we read through their documents and also in MANET documents which I am trying to solve by my drafts [1] and [2]. I agree that Mobility is the Mostly the concern of MANET (use cases and applicability), so the *dynamic* is mostly caused by Mobility in MANET, but in LLNs the *dynamic* is Mostly caused by the Losses or Low power. I will put that in my terminology draft :) I don't think we can distinguish LLN and MANET by *mobility*. In LLNs, the = mobility can be not only caused by radio, but also physical movement, such = as in wildlife monitoring, water monitoring, etc. You can find a lot of exa= mples of that. The key point of LLN is "low power", i.e., resource constrained. A vehicle = network is a MANET, but we won't say it's a LLN. Therefore, I would rather say LLN is resource constrained MANET. [1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt [2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt Best Regards Abdussalam Baryun University of glamorgan, UK =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Ronald 2012/7/31 Ulrich Herberg >: MANETs are not defined by mobility. It is rather about very dynamic topologies. Otherwise, community networks such as FunkFeuer would also not be qualified as MANETs. Ulrich On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal > wrote: The wireless network of "fixed" temperature monitoring sensors and HVAC controllers in a building. This network is an LLN. Not sure if it qualifies as a MANET (since nothing is mobile). Thanks Mukul ----- Original Message ----- From: "Henning Rogge" > To: "Abdussalam Baryun" > Cc: "manet" > Sent: Tuesday, July 31, 2012 8:49:08 AM Subject: Re: [manet] Discussing LOADng suggestions On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun > wrote: IMHO this protocol was intended as for ROLL WG not for MANET WG, but then changed its direction to MANET [3]. However, please note that *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That said, LOADng SHOULD specfy where is its limits. Then we can discuss adoption. Could you state an example what would be considered a LLN but not a MANET. I normally consider LLNs a subset of what we call MANETs. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_4F314E840E4A47C0A27B19E40B634B0Cwattecocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <2CA513808AAD664FB7CE2DA4C7136031@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi, 

The key point of LLN is "low power", i.e., resource constrai= ned.

Agree. I tried to make the difference clear in a previous mail when pa= rsing the constraints of LLN Vs MANET.

A vehicle network is a MANET, but we won't say it's a LLN. 

Therefore, I would rather say LLN is resource constrained MANET. =

Agree.

I think most of people on the list agree that LLN and MANET are not id= entical, and that, as you mentioned, LLN are more resource constrained.

That's why IETF created ROLL in the routing area for these specific ne= eds.


So I'm a little bit surprised about this submission in MANET.

Could you clarify the scope of LOADng regarding the MANET scope ?

C=E9dric.

Le 1 ao=FBt 2012 =E0 20:53, Jiazi YI a =E9crit :

Hi, 

please check inline:


On Aug 1, 2012, at 12:41 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Ulrich,

comments in lines:
According to MANET charter,

The purpose of the MANET working group is to standardize IP routing
protocol functionality suitable for wireless routing application
within
both static and dynamic topologies with increased dynamics due to node
motion or other factors.

Strange wording, in my opinion. It seems to me that if the network
_topology_ is truly static, you do not need a routing protocol at all.

I agree.


I like the wording in the charter, but it MAY need to be more clear to
distinguish between ROLL and MANET charters I think the AD can help us
in this matter.



(Note that just as the absence of movement does n= ot imply a static
topology, a static topology does not imply stationary nodes).


So I don't think MANETs are defined by mobility, but by "increased
dynamics",which can be due to motion, but also to lossy links.

So why aren't they called ANETs?

Or DANET ("dynamic"). It just did not sound as nice when the term= was
created.


I like that *dynamic* word, I agree with it, but we don't forget that
ROLL or LLNs are also DANETs so there SHOULD be differences when we
read through their documents and also in MANET documents which I am
trying to solve by my drafts [1] and [2].

I agree that Mobility is the Mostly the concern of MANET (use cases
and applicability), so the *dynamic* is mostly caused by Mobility in
MANET, but in LLNs the *dynamic* is Mostly caused by the Losses or Low
power. I will put that in my terminology draft :)


I don't think we can distinguish LLN and MANET by *mobility*. In LLNs,= the mobility can be not only caused by radio, but also physical movement, = such as in wildlife monitoring, water monitoring, etc. You can find a lot o= f examples of that. 

The key point of LLN is "low power", i.e., resource constrai= ned. A vehicle network is a MANET, but we won't say it's a LLN. 

Therefore, I would rather say LLN is resource constrained MANET. =



[1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt
[2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt

Best Regards

Abdussalam Baryun
University of glamorgan, UK

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D




Ronald

2012/7/31 Ulrich Herberg <ulrich@= herberg.name>:
MANETs are not defined by mobility. It is rather = about very dynamic
topologies. Otherwise, community networks such as FunkFeuer would also
not be qualified as MANETs.

Ulrich


On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal <mukul@uwm.edu> wrote:

The wireless network of "fixed" temperature monitoring sensors an= d
HVAC controllers in a building. This network is an LLN. Not sure if
it qualifies as a MANET (since nothing is mobile).

Thanks
Mukul

----- Original Message -----
From: "Henning Rogge" <hrogge@googlemail.com>
To: "Abdussalam Baryun" <abdussalambaryun@gmail.com>
Cc: "manet" <manet@ietf.org<= /a>>
Sent: Tuesday, July 31, 2012 8:49:08 AM
Subject: Re: [manet] Discussing LOADng suggestions

On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun
<abdussalambaryun@gmail.co= m> wrote:
IMHO this protocol was intended as for ROLL WG no= t for MANET WG,
but then changed its direction to MANET [3]. However, please note
that
*ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs.
That
said, LOADng SHOULD specfy where is its limits. T= hen we can discuss
adoption.

Could you state an example what would be considered a LLN but not a
MANET. I normally consider LLNs a subset of what we call MANETs.

Henning Rogge

--
Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that
was before the present government."
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet
This e-mail and its contents are subject to the DISCLAIMER at
http://www.tno.nl/emaildiscla= imer



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_4F314E840E4A47C0A27B19E40B634B0Cwattecocom_-- From yi.jiazi@gmail.com Wed Aug 1 13:32:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A351011E8179 for ; Wed, 1 Aug 2012 13:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdOTAufqj+Gu for ; Wed, 1 Aug 2012 13:32:04 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 30B6611E8173 for ; Wed, 1 Aug 2012 13:32:04 -0700 (PDT) Received: by yhq56 with SMTP id 56so8402333yhq.31 for ; Wed, 01 Aug 2012 13:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=5vE8lT8icGYbijW31VGh0BDEwXCWQ0aqvMXy/9z1bog=; b=SA1HDLgob16Z8HhLfe8Uyydtzee3XRNzBR4EuxxmOSqKnE48LeDBxNCSMBOdsKFkmD jPBctJvB+6IY0fwnkHyfYG/LECmIpDgQKurGhoOhJD5U7kFPMWauPOSv6ZSwt/GuTIxq GEK2Pvm+u/8EkPbQMgy0cjsk+y8XACMHRFaT3hSsiIdvULSp2Imi/6Jqr+STRctbhPlY 9RM2UOYp+so/CzaBWWuXPa3TzAakMohPPG5g7DqIMt8+cBciP7Vf12HPCwNthHa1+TQ3 5j+SrsU+f5f+7wzGmO2T72CFqewe729LX8Qr6xEzxWTGMaRPOdAzNuASCjRhWgdq4Ra9 /GvQ== Received: by 10.68.231.10 with SMTP id tc10mr54477378pbc.107.1343853122996; Wed, 01 Aug 2012 13:32:02 -0700 (PDT) Received: from ?IPv6:2001:df8::16:1c1f:f442:2e98:f910? ([2001:df8:0:16:1c1f:f442:2e98:f910]) by mx.google.com with ESMTPS id hw6sm3215227pbc.73.2012.08.01.13.32.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 13:32:02 -0700 (PDT) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_BE612265-A1E8-4635-BB08-5D8F890B1387" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Jiazi YI In-Reply-To: <4F314E84-0E4A-47C0-A27B-19E40B634B0C@watteco.com> Date: Wed, 1 Aug 2012 13:31:59 -0700 Message-Id: <943624B4-3678-483B-85EF-19ACD204180F@jiaziyi.com> References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> <2C6647B8-18F9-4039-B1E2-5371E4F27EF7@jiaziyi.com> <4F314E84-0E4A-47C0-A27B-19E40B634B0C@watteco.com> To: C Chauvenet X-Mailer: Apple Mail (2.1485) Cc: MANET IETF Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 20:32:05 -0000 --Apple-Mail=_BE612265-A1E8-4635-BB08-5D8F890B1387 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi,=20 LOADng is a MANET routing protocol, and therefore can be applied to LLN.=20= The authors are discussing about rephrasing some of the text in = abstract/introduction/applicability statement based on the feedback = from the WG.=20 regards Jiazi On Aug 1, 2012, at 12:58 PM, C Chauvenet = wrote: > Hi,=20 >=20 >> The key point of LLN is "low power", i.e., resource constrained. >=20 > Agree. I tried to make the difference clear in a previous mail when = parsing the constraints of LLN Vs MANET. >=20 >> A vehicle network is a MANET, but we won't say it's a LLN.=20 >>=20 >> Therefore, I would rather say LLN is resource constrained MANET.=20 >=20 > Agree. >=20 > I think most of people on the list agree that LLN and MANET are not = identical, and that, as you mentioned, LLN are more resource = constrained. >=20 > That's why IETF created ROLL in the routing area for these specific = needs. >=20 > http://tools.ietf.org/html/draft-clausen-lln-loadng-05#section-3 = states that it target LLN. >=20 > So I'm a little bit surprised about this submission in MANET. >=20 > Could you clarify the scope of LOADng regarding the MANET scope ? >=20 > C=E9dric. >=20 > Le 1 ao=FBt 2012 =E0 20:53, Jiazi YI a =E9crit : >=20 >> Hi,=20 >>=20 >> please check inline: >>=20 >>=20 >> On Aug 1, 2012, at 12:41 AM, Abdussalam Baryun = wrote: >>=20 >>> Hi Ulrich, >>>=20 >>> comments in lines: >>>>>> According to MANET charter, >>>>>>=20 >>>>>> The purpose of the MANET working group is to standardize IP = routing >>>>>> protocol functionality suitable for wireless routing application >>>>>> within >>>>>> both static and dynamic topologies with increased dynamics due to = node >>>>>> motion or other factors. >>>>>=20 >>>>> Strange wording, in my opinion. It seems to me that if the network >>>>> _topology_ is truly static, you do not need a routing protocol at = all. >>>>=20 >>>> I agree. >>>>=20 >>>=20 >>> I like the wording in the charter, but it MAY need to be more clear = to >>> distinguish between ROLL and MANET charters I think the AD can help = us >>> in this matter. >>>=20 >>>>=20 >>>>=20 >>>>> (Note that just as the absence of movement does not imply a static >>>>> topology, a static topology does not imply stationary nodes). >>>>>=20 >>>>>>=20 >>>>>> So I don't think MANETs are defined by mobility, but by = "increased >>>>>> dynamics",which can be due to motion, but also to lossy links. >>>>>=20 >>>>> So why aren't they called ANETs? >>>>=20 >>>> Or DANET ("dynamic"). It just did not sound as nice when the term = was >>>> created. >>>>=20 >>>=20 >>> I like that *dynamic* word, I agree with it, but we don't forget = that >>> ROLL or LLNs are also DANETs so there SHOULD be differences when we >>> read through their documents and also in MANET documents which I am >>> trying to solve by my drafts [1] and [2]. >>>=20 >>> I agree that Mobility is the Mostly the concern of MANET (use cases >>> and applicability), so the *dynamic* is mostly caused by Mobility in >>> MANET, but in LLNs the *dynamic* is Mostly caused by the Losses or = Low >>> power. I will put that in my terminology draft :) >>=20 >>=20 >> I don't think we can distinguish LLN and MANET by *mobility*. In = LLNs, the mobility can be not only caused by radio, but also physical = movement, such as in wildlife monitoring, water monitoring, etc. You can = find a lot of examples of that.=20 >>=20 >> The key point of LLN is "low power", i.e., resource constrained. A = vehicle network is a MANET, but we won't say it's a LLN.=20 >>=20 >> Therefore, I would rather say LLN is resource constrained MANET.=20 >>=20 >>=20 >>>=20 >>> [1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >>> [2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >>>=20 >>> Best Regards >>>=20 >>> Abdussalam Baryun >>> University of glamorgan, UK >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Ronald >>>>>>=20 >>>>>> 2012/7/31 Ulrich Herberg : >>>>>>> MANETs are not defined by mobility. It is rather about very = dynamic >>>>>>> topologies. Otherwise, community networks such as FunkFeuer = would also >>>>>>> not be qualified as MANETs. >>>>>>>=20 >>>>>>> Ulrich >>>>>>>=20 >>>>>>>=20 >>>>>>> On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal = wrote: >>>>>>>>=20 >>>>>>>> The wireless network of "fixed" temperature monitoring sensors = and >>>>>>>> HVAC controllers in a building. This network is an LLN. Not = sure if >>>>>>>> it qualifies as a MANET (since nothing is mobile). >>>>>>>>=20 >>>>>>>> Thanks >>>>>>>> Mukul >>>>>>>>=20 >>>>>>>> ----- Original Message ----- >>>>>>>> From: "Henning Rogge" >>>>>>>> To: "Abdussalam Baryun" >>>>>>>> Cc: "manet" >>>>>>>> Sent: Tuesday, July 31, 2012 8:49:08 AM >>>>>>>> Subject: Re: [manet] Discussing LOADng suggestions >>>>>>>>=20 >>>>>>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>>>>>>> wrote: >>>>>>>>> IMHO this protocol was intended as for ROLL WG not for MANET = WG, >>>>>>>>> but then changed its direction to MANET [3]. However, please = note >>>>>>>>> that >>>>>>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. >>>>>> That >>>>>>>>> said, LOADng SHOULD specfy where is its limits. Then we can = discuss >>>>>>>>> adoption. >>>>>>>>=20 >>>>>>>> Could you state an example what would be considered a LLN but = not a >>>>>>>> MANET. I normally consider LLNs a subset of what we call = MANETs. >>>>>>>>=20 >>>>>>>> Henning Rogge >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Steven Hawkings about cosmic inflation: "An increase of = billions of >>>>>>>> billions of percent in a tiny fraction of a second. Of course, = that >>>>>>>> was before the present government." >>>>>>>> _______________________________________________ >>>>>>>> manet mailing list >>>>>>>> manet@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>> _______________________________________________ >>>>>>>> manet mailing list >>>>>>>> manet@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> This e-mail and its contents are subject to the DISCLAIMER at >>>>> http://www.tno.nl/emaildisclaimer >>>>>=20 >>>>>=20 >>>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail=_BE612265-A1E8-4635-BB08-5D8F890B1387 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi, 

LOADng is a MANET routing protocol, and = therefore can be applied to LLN. 
The authors are discussing about = rephrasing some of the text in abstract/introduction/applicability = statement  based on the feedback from the WG. 

regards

Jiazi


On Aug 1, 2012, at 12:58 PM, C Chauvenet <c.chauvenet@watteco.com> = wrote:

Hi, 

The key point of LLN is "low power", i.e., resource constrained. =

Agree. I tried to make the difference clear in a previous mail when = parsing the constraints of LLN Vs MANET.

A vehicle network is a MANET, but we won't say it's a = LLN. 

Therefore, I would rather say LLN is resource constrained = MANET. 

Agree.

I think most of people on the list agree that LLN and MANET are not = identical, and that, as you mentioned, LLN are more resource = constrained.

That's why IETF created ROLL in the routing area for these specific = needs.


So I'm a little bit surprised about this submission in MANET.

Could you clarify the scope of LOADng regarding the MANET scope = ?

C=E9dric.

Le 1 ao=FBt 2012 =E0 20:53, Jiazi YI a =E9crit :

Hi, 

please check inline:


On Aug 1, 2012, at 12:41 AM, Abdussalam Baryun <abdussalambaryun@gmail.com&= gt; wrote:

Hi Ulrich,

comments in lines:
According to MANET charter,

The purpose of the MANET working group is to standardize IP routing
protocol functionality suitable for wireless routing application
within
both static and dynamic topologies with increased dynamics due to = node
motion or other factors.

Strange wording, in my opinion. It seems to me that if the network
_topology_ is truly static, you do not need a routing protocol at = all.

I agree.


I like the wording in the charter, but it MAY need to be more clear = to
distinguish between ROLL and MANET charters I think the AD can help = us
in this matter.



(Note that just as the absence of movement = does not imply a static
topology, a static topology does not imply stationary nodes).


So I don't think MANETs are defined by mobility, but by "increased
dynamics",which can be due to motion, but also to lossy links.

So why aren't they called ANETs?

Or DANET ("dynamic"). It just did not sound as nice when the term = was
created.


I like that *dynamic* word, I agree with it, but we don't forget = that
ROLL or LLNs are also DANETs so there SHOULD be differences when we
read through their documents and also in MANET documents which I am
trying to solve by my drafts [1] and [2].

I agree that Mobility is the Mostly the concern of MANET (use cases
and applicability), so the *dynamic* is mostly caused by Mobility in
MANET, but in LLNs the *dynamic* is Mostly caused by the Losses or = Low
power. I will put that in my terminology draft :)


I don't think we can distinguish LLN and MANET by *mobility*. In = LLNs, the mobility can be not only caused by radio, but also physical = movement, such as in wildlife monitoring, water monitoring, etc. You can = find a lot of examples of that. 

The key point of LLN is "low power", i.e., resource constrained. A = vehicle network is a MANET, but we won't say it's a LLN. 

Therefore, I would rather say LLN is resource constrained = MANET. 



[1] http= ://www.ietf.org/id/draft-baryun-manet-terminology-00.txt
[2] http:= //www.ietf.org/id/draft-baryun-manet-technology-00.txt

Best Regards

Abdussalam Baryun
University of glamorgan, UK

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D




Ronald

2012/7/31 Ulrich Herberg <ulrich@herberg.name>:
MANETs are not defined by mobility. It is = rather about very dynamic
topologies. Otherwise, community networks such as FunkFeuer would = also
not be qualified as MANETs.

Ulrich


On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal <mukul@uwm.edu> wrote:

The wireless network of "fixed" temperature monitoring sensors and
HVAC controllers in a building. This network is an LLN. Not sure if
it qualifies as a MANET (since nothing is mobile).

Thanks
Mukul

----- Original Message -----
From: "Henning Rogge" <hrogge@googlemail.com>
To: "Abdussalam Baryun" <abdussalambaryun@gmail.com&= gt;
Cc: "manet" <manet@ietf.org>
Sent: Tuesday, July 31, 2012 8:49:08 AM
Subject: Re: [manet] Discussing LOADng suggestions

On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun
<abdussalambaryun@gmail.com&= gt; wrote:
IMHO this protocol was intended as for ROLL WG = not for MANET WG,
but then changed its direction to MANET [3]. However, please note
that
*ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs.
That
said, LOADng SHOULD specfy where is its = limits. Then we can discuss
adoption.

Could you state an example what would be considered a LLN but not a
MANET. I normally consider LLNs a subset of what we call MANETs.

Henning Rogge

--
Steven Hawkings about cosmic inflation: "An increase of billions of
billions of percent in a tiny fraction of a second. Of course, that
was before the present government."
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet
This e-mail and its contents are subject to the DISCLAIMER at
http://www.tno.nl/emaildisclaim= er



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet


= --Apple-Mail=_BE612265-A1E8-4635-BB08-5D8F890B1387-- From c.chauvenet@watteco.com Wed Aug 1 13:48:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF0D11E828E for ; Wed, 1 Aug 2012 13:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZW+-acBadF5b for ; Wed, 1 Aug 2012 13:48:41 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id D2DBC11E8174 for ; Wed, 1 Aug 2012 13:48:40 -0700 (PDT) Received: from mail61-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 1 Aug 2012 20:48:39 +0000 Received: from mail61-va3 (localhost [127.0.0.1]) by mail61-va3-R.bigfish.com (Postfix) with ESMTP id DA6C81200B1; Wed, 1 Aug 2012 20:48:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT005.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI98dI9371Ic89bh542Mc85dh1418If10Izz1202hzz1033IL8275bh8275dh84d07hz2dh2a8h668h839hd25he5bhf0ah107ahbe3k) Received: from mail61-va3 (localhost.localdomain [127.0.0.1]) by mail61-va3 (MessageSwitch) id 1343854116280283_19247; Wed, 1 Aug 2012 20:48:36 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.244]) by mail61-va3.bigfish.com (Postfix) with ESMTP id 415C4300117; Wed, 1 Aug 2012 20:48:36 +0000 (UTC) Received: from DBXPRD0510HT005.eurprd05.prod.outlook.com (157.56.252.165) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 1 Aug 2012 20:48:34 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.6.25]) by DBXPRD0510HT005.eurprd05.prod.outlook.com ([10.255.67.168]) with mapi id 14.16.0175.005; Wed, 1 Aug 2012 20:48:33 +0000 From: C Chauvenet To: Jiazi YI Thread-Topic: [manet] Discussing LOADng suggestions Thread-Index: AQHNcBbmm+u1REK/lkKRZGyT6FVJyZdFX9QAgAAJZICAAASfgA== Date: Wed, 1 Aug 2012 20:48:32 +0000 Message-ID: References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> <2C6647B8-18F9-4039-B1E2-5371E4F27EF7@jiaziyi.com> <4F314E84-0E4A-47C0-A27B-19E40B634B0C@watteco.com> <943624B4-3678-483B-85EF-19ACD204180F@jiaziyi.com> In-Reply-To: <943624B4-3678-483B-85EF-19ACD204180F@jiaziyi.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.57.4] Content-Type: multipart/alternative; boundary="_000_E5E160CDFA8D452E9C7FD058E179F0BBwattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: MANET IETF Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 20:48:42 -0000 --_000_E5E160CDFA8D452E9C7FD058E179F0BBwattecocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Thank you for the clarification. LOADng is a MANET routing protocol, and therefore can be applied to LLN. Not sure that this statement is true, otherwise all MANET protocols can be = applied to LLN, and as we agreed before, they have different constraints. I agree that the LOADng draft would need some rewording regarding the appli= cability, but I think that changing such an important thing will impact th= e protocol itself. C=E9dric. Le 1 ao=FBt 2012 =E0 22:31, Jiazi YI a =E9crit : Hi, LOADng is a MANET routing protocol, and therefore can be applied to LLN. The authors are discussing about rephrasing some of the text in abstract/in= troduction/applicability statement based on the feedback from the WG. regards Jiazi On Aug 1, 2012, at 12:58 PM, C Chauvenet > wrote: Hi, The key point of LLN is "low power", i.e., resource constrained. Agree. I tried to make the difference clear in a previous mail when parsing= the constraints of LLN Vs MANET. A vehicle network is a MANET, but we won't say it's a LLN. Therefore, I would rather say LLN is resource constrained MANET. Agree. I think most of people on the list agree that LLN and MANET are not identic= al, and that, as you mentioned, LLN are more resource constrained. That's why IETF created ROLL in the routing area for these specific needs. http://tools.ietf.org/html/draft-clausen-lln-loadng-05#section-3 states tha= t it target LLN. So I'm a little bit surprised about this submission in MANET. Could you clarify the scope of LOADng regarding the MANET scope ? C=E9dric. Le 1 ao=FBt 2012 =E0 20:53, Jiazi YI a =E9crit : Hi, please check inline: On Aug 1, 2012, at 12:41 AM, Abdussalam Baryun > wrote: Hi Ulrich, comments in lines: According to MANET charter, The purpose of the MANET working group is to standardize IP routing protocol functionality suitable for wireless routing application within both static and dynamic topologies with increased dynamics due to node motion or other factors. Strange wording, in my opinion. It seems to me that if the network _topology_ is truly static, you do not need a routing protocol at all. I agree. I like the wording in the charter, but it MAY need to be more clear to distinguish between ROLL and MANET charters I think the AD can help us in this matter. (Note that just as the absence of movement does not imply a static topology, a static topology does not imply stationary nodes). So I don't think MANETs are defined by mobility, but by "increased dynamics",which can be due to motion, but also to lossy links. So why aren't they called ANETs? Or DANET ("dynamic"). It just did not sound as nice when the term was created. I like that *dynamic* word, I agree with it, but we don't forget that ROLL or LLNs are also DANETs so there SHOULD be differences when we read through their documents and also in MANET documents which I am trying to solve by my drafts [1] and [2]. I agree that Mobility is the Mostly the concern of MANET (use cases and applicability), so the *dynamic* is mostly caused by Mobility in MANET, but in LLNs the *dynamic* is Mostly caused by the Losses or Low power. I will put that in my terminology draft :) I don't think we can distinguish LLN and MANET by *mobility*. In LLNs, the = mobility can be not only caused by radio, but also physical movement, such = as in wildlife monitoring, water monitoring, etc. You can find a lot of exa= mples of that. The key point of LLN is "low power", i.e., resource constrained. A vehicle = network is a MANET, but we won't say it's a LLN. Therefore, I would rather say LLN is resource constrained MANET. [1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt [2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt Best Regards Abdussalam Baryun University of glamorgan, UK =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Ronald 2012/7/31 Ulrich Herberg >: MANETs are not defined by mobility. It is rather about very dynamic topologies. Otherwise, community networks such as FunkFeuer would also not be qualified as MANETs. Ulrich On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal > wrote: The wireless network of "fixed" temperature monitoring sensors and HVAC controllers in a building. This network is an LLN. Not sure if it qualifies as a MANET (since nothing is mobile). Thanks Mukul ----- Original Message ----- From: "Henning Rogge" > To: "Abdussalam Baryun" > Cc: "manet" > Sent: Tuesday, July 31, 2012 8:49:08 AM Subject: Re: [manet] Discussing LOADng suggestions On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun > wrote: IMHO this protocol was intended as for ROLL WG not for MANET WG, but then changed its direction to MANET [3]. However, please note that *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That said, LOADng SHOULD specfy where is its limits. Then we can discuss adoption. Could you state an example what would be considered a LLN but not a MANET. I normally consider LLNs a subset of what we call MANETs. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_E5E160CDFA8D452E9C7FD058E179F0BBwattecocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <90E92B91E262DD49900F63C45CED3DB5@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi, 

Thank you for the clarification.

LOADng is a MANET routing protocol, and = therefore can be applied to LLN. 

Not sure that this statement is true, otherwise all MANET protocols ca= n be applied to LLN, and as we agreed before, they have different constrain= ts.

I agree that the LOADng draft would need some rewording regarding the = applicability, but I think that changing such an important thing will  = ;impact the protocol itself.

C=E9dric.

Le 1 ao=FBt 2012 =E0 22:31, Jiazi YI a =E9crit :

Hi, 

LOADng is a MANET routing protocol, and = therefore can be applied to LLN. 
The authors are discussing about rephras= ing some of the text in abstract/introduction/applicability statement  = ;based on the feedback from the WG. 

regards

Jiazi


On Aug 1, 2012, at 12:58 PM, C Chauvenet <c.chauvenet@watteco.com> wrote:

Hi, 

The key point of LLN is "low power", i.e., resource constrai= ned.

Agree. I tried to make the difference clear in a previous mail when pa= rsing the constraints of LLN Vs MANET.

A vehicle network is a MANET, but we won't say it's a LLN. 

Therefore, I would rather say LLN is resource constrained MANET. =

Agree.

I think most of people on the list agree that LLN and MANET are not id= entical, and that, as you mentioned, LLN are more resource constrained.

That's why IETF created ROLL in the routing area for these specific ne= eds.


So I'm a little bit surprised about this submission in MANET.

Could you clarify the scope of LOADng regarding the MANET scope ?

C=E9dric.

Le 1 ao=FBt 2012 =E0 20:53, Jiazi YI a =E9crit :

Hi, 

please check inline:


On Aug 1, 2012, at 12:41 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Ulrich,

comments in lines:
According to MANET charter,

The purpose of the MANET working group is to standardize IP routing
protocol functionality suitable for wireless routing application
within
both static and dynamic topologies with increased dynamics due to node
motion or other factors.

Strange wording, in my opinion. It seems to me that if the network
_topology_ is truly static, you do not need a routing protocol at all.

I agree.


I like the wording in the charter, but it MAY need to be more clear to
distinguish between ROLL and MANET charters I think the AD can help us
in this matter.



(Note that just as the absence of movement does n= ot imply a static
topology, a static topology does not imply stationary nodes).


So I don't think MANETs are defined by mobility, but by "increased
dynamics",which can be due to motion, but also to lossy links.

So why aren't they called ANETs?

Or DANET ("dynamic"). It just did not sound as nice when the term= was
created.


I like that *dynamic* word, I agree with it, but we don't forget that
ROLL or LLNs are also DANETs so there SHOULD be differences when we
read through their documents and also in MANET documents which I am
trying to solve by my drafts [1] and [2].

I agree that Mobility is the Mostly the concern of MANET (use cases
and applicability), so the *dynamic* is mostly caused by Mobility in
MANET, but in LLNs the *dynamic* is Mostly caused by the Losses or Low
power. I will put that in my terminology draft :)


I don't think we can distinguish LLN and MANET by *mobility*. In LLNs,= the mobility can be not only caused by radio, but also physical movement, = such as in wildlife monitoring, water monitoring, etc. You can find a lot o= f examples of that. 

The key point of LLN is "low power", i.e., resource constrai= ned. A vehicle network is a MANET, but we won't say it's a LLN. 

Therefore, I would rather say LLN is resource constrained MANET. =



[1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt
[2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt

Best Regards

Abdussalam Baryun
University of glamorgan, UK

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D




Ronald

2012/7/31 Ulrich Herberg <ulrich@= herberg.name>:
MANETs are not defined by mobility. It is rather = about very dynamic
topologies. Otherwise, community networks such as FunkFeuer would also
not be qualified as MANETs.

Ulrich


On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal <mukul@uwm.edu> wrote:

The wireless network of "fixed" temperature monitoring sensors an= d
HVAC controllers in a building. This network is an LLN. Not sure if
it qualifies as a MANET (since nothing is mobile).

Thanks
Mukul

----- Original Message -----
From: "Henning Rogge" <hrogge@googlemail.com>
To: "Abdussalam Baryun" <abdussalambaryun@gmail.com>
Cc: "manet" <manet@ietf.org<= /a>>
Sent: Tuesday, July 31, 2012 8:49:08 AM
Subject: Re: [manet] Discussing LOADng suggestions

On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun
<abdussalambaryun@gmail.co= m> wrote:
IMHO this protocol was intended as for ROLL WG no= t for MANET WG,
but then changed its direction to MANET [3]. However, please note
that
*ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs.
That
said, LOADng SHOULD specfy where is its limits. T= hen we can discuss
adoption.

Could you state an example what would be considered a LLN but not a
MANET. I normally consider LLNs a subset of what we call MANETs.

Henning Rogge

--
Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that
was before the present government."
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet
This e-mail and its contents are subject to the DISCLAIMER at
http://www.tno.nl/emaildiscla= imer



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet



--_000_E5E160CDFA8D452E9C7FD058E179F0BBwattecocom_-- From antonin.bas@gmail.com Wed Aug 1 13:58:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DF911E82D1 for ; Wed, 1 Aug 2012 13:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXluGkkIE6Lc for ; Wed, 1 Aug 2012 13:58:12 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7138311E82CC for ; Wed, 1 Aug 2012 13:58:12 -0700 (PDT) Received: by qaea16 with SMTP id a16so764014qae.10 for ; Wed, 01 Aug 2012 13:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fe8rkwNbTIc36krx3mML/d+IYzZmTqJprGLxQZERPJU=; b=j95cnaeVhztD5P0kEB0O57+t/4VJvwAXPnLZqmitHLwfE222t7K5odPYAnMIVQr435 bUK+2/VVKoJp6DmltLTgNuCYkUpDukD9wDk5No5qguYRiDuoTz/8gygCBuBxZqaBNqJY giSpylZji70fTC4jK9PetPXrcSgg4e7iKauoiu4cdoLkT/RUgWgf27uwN9rnoZzM6Cmr SDHrTh0tVNIB3s9c4V3EQxSlyacZNrqzoBXP9se9j4P92KNy/NptrHQal2pp4MzJ/ZxT XZUiSG0z46G/9XHU/P2bFKFFGw23zfDIbbuV2g0nSvRtkAPrPyu7oFmtq4Nj1Ao5DbY0 +UUQ== MIME-Version: 1.0 Received: by 10.229.134.197 with SMTP id k5mr9915263qct.33.1343854691885; Wed, 01 Aug 2012 13:58:11 -0700 (PDT) Sender: antonin.bas@gmail.com Received: by 10.224.137.35 with HTTP; Wed, 1 Aug 2012 13:58:11 -0700 (PDT) In-Reply-To: References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> <2C6647B8-18F9-4039-B1E2-5371E4F27EF7@jiaziyi.com> <4F314E84-0E4A-47C0-A27B-19E40B634B0C@watteco.com> <943624B4-3678-483B-85EF-19ACD204180F@jiaziyi.com> Date: Wed, 1 Aug 2012 22:58:11 +0200 X-Google-Sender-Auth: z26buDAwFgSz7ij2PfRSUahLRS4 Message-ID: From: Antonin Bas To: C Chauvenet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: MANET IETF Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 20:58:13 -0000 Hi, The LOADng draft indeed need some rewording. And you are right, all MANET protocols cannot be applied to LLNs. LOADng is a MANET routing protocol which has been found to perform well even with LLNs. It is for instance more energy efficient than AODV, which make it more adapted for the resource constrained nature of LLNs. Antonin 2012/8/1 C Chauvenet : > Hi, > > Thank you for the clarification. > > LOADng is a MANET routing protocol, and therefore can be applied to LLN. > > > Not sure that this statement is true, otherwise all MANET protocols can b= e > applied to LLN, and as we agreed before, they have different constraints. > > I agree that the LOADng draft would need some rewording regarding the > applicability, but I think that changing such an important thing will > impact the protocol itself. > > C=E9dric. > > Le 1 ao=FBt 2012 =E0 22:31, Jiazi YI a =E9crit : > > Hi, > > LOADng is a MANET routing protocol, and therefore can be applied to LLN. > The authors are discussing about rephrasing some of the text in > abstract/introduction/applicability statement based on the feedback from > the WG. > > regards > > Jiazi > > > On Aug 1, 2012, at 12:58 PM, C Chauvenet wrote: > > Hi, > > The key point of LLN is "low power", i.e., resource constrained. > > > Agree. I tried to make the difference clear in a previous mail when parsi= ng > the constraints of LLN Vs MANET. > > A vehicle network is a MANET, but we won't say it's a LLN. > > Therefore, I would rather say LLN is resource constrained MANET. > > > Agree. > > I think most of people on the list agree that LLN and MANET are not > identical, and that, as you mentioned, LLN are more resource constrained. > > That's why IETF created ROLL in the routing area for these specific needs= . > > http://tools.ietf.org/html/draft-clausen-lln-loadng-05#section-3 states t= hat > it target LLN. > > So I'm a little bit surprised about this submission in MANET. > > Could you clarify the scope of LOADng regarding the MANET scope ? > > C=E9dric. > > Le 1 ao=FBt 2012 =E0 20:53, Jiazi YI a =E9crit : > > Hi, > > please check inline: > > > On Aug 1, 2012, at 12:41 AM, Abdussalam Baryun > wrote: > > Hi Ulrich, > > comments in lines: > > According to MANET charter, > > The purpose of the MANET working group is to standardize IP routing > protocol functionality suitable for wireless routing application > within > both static and dynamic topologies with increased dynamics due to node > motion or other factors. > > > Strange wording, in my opinion. It seems to me that if the network > _topology_ is truly static, you do not need a routing protocol at all. > > > I agree. > > > I like the wording in the charter, but it MAY need to be more clear to > distinguish between ROLL and MANET charters I think the AD can help us > in this matter. > > > > (Note that just as the absence of movement does not imply a static > topology, a static topology does not imply stationary nodes). > > > So I don't think MANETs are defined by mobility, but by "increased > dynamics",which can be due to motion, but also to lossy links. > > > So why aren't they called ANETs? > > > Or DANET ("dynamic"). It just did not sound as nice when the term was > created. > > > I like that *dynamic* word, I agree with it, but we don't forget that > ROLL or LLNs are also DANETs so there SHOULD be differences when we > read through their documents and also in MANET documents which I am > trying to solve by my drafts [1] and [2]. > > I agree that Mobility is the Mostly the concern of MANET (use cases > and applicability), so the *dynamic* is mostly caused by Mobility in > MANET, but in LLNs the *dynamic* is Mostly caused by the Losses or Low > power. I will put that in my terminology draft :) > > > > I don't think we can distinguish LLN and MANET by *mobility*. In LLNs, th= e > mobility can be not only caused by radio, but also physical movement, suc= h > as in wildlife monitoring, water monitoring, etc. You can find a lot of > examples of that. > > The key point of LLN is "low power", i.e., resource constrained. A vehicl= e > network is a MANET, but we won't say it's a LLN. > > Therefore, I would rather say LLN is resource constrained MANET. > > > > [1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt > [2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt > > Best Regards > > Abdussalam Baryun > University of glamorgan, UK > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > > > Ronald > > > 2012/7/31 Ulrich Herberg : > > MANETs are not defined by mobility. It is rather about very dynamic > topologies. Otherwise, community networks such as FunkFeuer would also > not be qualified as MANETs. > > Ulrich > > > On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal wrote: > > > The wireless network of "fixed" temperature monitoring sensors and > HVAC controllers in a building. This network is an LLN. Not sure if > it qualifies as a MANET (since nothing is mobile). > > Thanks > Mukul > > ----- Original Message ----- > From: "Henning Rogge" > To: "Abdussalam Baryun" > Cc: "manet" > Sent: Tuesday, July 31, 2012 8:49:08 AM > Subject: Re: [manet] Discussing LOADng suggestions > > On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun > wrote: > > IMHO this protocol was intended as for ROLL WG not for MANET WG, > but then changed its direction to MANET [3]. However, please note > that > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. > > That > > said, LOADng SHOULD specfy where is its limits. Then we can discuss > adoption. > > > Could you state an example what would be considered a LLN but not a > MANET. I normally consider LLNs a subset of what we call MANETs. > > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From c.chauvenet@watteco.com Wed Aug 1 14:18:24 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4291011E8314 for ; Wed, 1 Aug 2012 14:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.974 X-Spam-Level: X-Spam-Status: No, score=-3.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTJ+Ec7pSlqu for ; Wed, 1 Aug 2012 14:18:23 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id AEC3811E8295 for ; Wed, 1 Aug 2012 14:18:22 -0700 (PDT) Received: from mail6-db3-R.bigfish.com (10.3.81.246) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 1 Aug 2012 21:18:20 +0000 Received: from mail6-db3 (localhost [127.0.0.1]) by mail6-db3-R.bigfish.com (Postfix) with ESMTP id A561A800BD; Wed, 1 Aug 2012 21:18:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VPS-31(zzbb2dI98dI9371Ic89bh542M1432I1418If10Izz1202hzz1033IL8275bh8275dh84d07hz2dh2a8h668h839hd25he5bhf0ah107ah) Received: from mail6-db3 (localhost.localdomain [127.0.0.1]) by mail6-db3 (MessageSwitch) id 1343855897893661_29624; Wed, 1 Aug 2012 21:18:17 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.233]) by mail6-db3.bigfish.com (Postfix) with ESMTP id CE76C100048; Wed, 1 Aug 2012 21:18:17 +0000 (UTC) Received: from DBXPRD0510HT001.eurprd05.prod.outlook.com (157.56.252.165) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 1 Aug 2012 21:18:17 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.6.25]) by DBXPRD0510HT001.eurprd05.prod.outlook.com ([10.255.67.164]) with mapi id 14.16.0175.005; Wed, 1 Aug 2012 21:18:16 +0000 From: C Chauvenet To: Antonin Bas Thread-Topic: [manet] Discussing LOADng suggestions Thread-Index: AQHNcBbmm+u1REK/lkKRZGyT6FVJyZdFX9QAgAAJZICAAASfgIAAArOAgAAFmgA= Date: Wed, 1 Aug 2012 21:18:16 +0000 Message-ID: <2E2A2F97-A304-4DE1-A864-4083159DC019@watteco.com> References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> <2C6647B8-18F9-4039-B1E2-5371E4F27EF7@jiaziyi.com> <4F314E84-0E4A-47C0-A27B-19E40B634B0C@watteco.com> <943624B4-3678-483B-85EF-19ACD204180F@jiaziyi.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.57.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: MANET IETF Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 21:18:24 -0000 Hi,=20 In my view things are simple. According to the (new ?) LOADng scope (a MANET routing protocol applicable = to LLN), there are 2 places possible : - A place for a routing protocol in LLN, which is already taken by RPL, de= signed in ROLL. - A place for a reactive protocols in MANET, still to be attributed, and = I understood that it was the intend of DYMO. I'm simply wondering where is the place for LOADng ? C=E9dric. Le 1 ao=FBt 2012 =E0 22:58, Antonin Bas a =E9crit : > Hi, >=20 > The LOADng draft indeed need some rewording. > And you are right, all MANET protocols cannot be applied to LLNs. > LOADng is a MANET routing protocol which has been found to perform > well even with LLNs. It is for instance more energy efficient than > AODV, which make it more adapted for the resource constrained nature > of LLNs. >=20 > Antonin >=20 > 2012/8/1 C Chauvenet : >> Hi, >>=20 >> Thank you for the clarification. >>=20 >> LOADng is a MANET routing protocol, and therefore can be applied to LLN. >>=20 >>=20 >> Not sure that this statement is true, otherwise all MANET protocols can = be >> applied to LLN, and as we agreed before, they have different constraints= . >>=20 >> I agree that the LOADng draft would need some rewording regarding the >> applicability, but I think that changing such an important thing will >> impact the protocol itself. >>=20 >> C=E9dric. >>=20 >> Le 1 ao=FBt 2012 =E0 22:31, Jiazi YI a =E9crit : >>=20 >> Hi, >>=20 >> LOADng is a MANET routing protocol, and therefore can be applied to LLN. >> The authors are discussing about rephrasing some of the text in >> abstract/introduction/applicability statement based on the feedback fro= m >> the WG. >>=20 >> regards >>=20 >> Jiazi >>=20 >>=20 >> On Aug 1, 2012, at 12:58 PM, C Chauvenet wrote= : >>=20 >> Hi, >>=20 >> The key point of LLN is "low power", i.e., resource constrained. >>=20 >>=20 >> Agree. I tried to make the difference clear in a previous mail when pars= ing >> the constraints of LLN Vs MANET. >>=20 >> A vehicle network is a MANET, but we won't say it's a LLN. >>=20 >> Therefore, I would rather say LLN is resource constrained MANET. >>=20 >>=20 >> Agree. >>=20 >> I think most of people on the list agree that LLN and MANET are not >> identical, and that, as you mentioned, LLN are more resource constrained= . >>=20 >> That's why IETF created ROLL in the routing area for these specific need= s. >>=20 >> http://tools.ietf.org/html/draft-clausen-lln-loadng-05#section-3 states = that >> it target LLN. >>=20 >> So I'm a little bit surprised about this submission in MANET. >>=20 >> Could you clarify the scope of LOADng regarding the MANET scope ? >>=20 >> C=E9dric. >>=20 >> Le 1 ao=FBt 2012 =E0 20:53, Jiazi YI a =E9crit : >>=20 >> Hi, >>=20 >> please check inline: >>=20 >>=20 >> On Aug 1, 2012, at 12:41 AM, Abdussalam Baryun >> wrote: >>=20 >> Hi Ulrich, >>=20 >> comments in lines: >>=20 >> According to MANET charter, >>=20 >> The purpose of the MANET working group is to standardize IP routing >> protocol functionality suitable for wireless routing application >> within >> both static and dynamic topologies with increased dynamics due to node >> motion or other factors. >>=20 >>=20 >> Strange wording, in my opinion. It seems to me that if the network >> _topology_ is truly static, you do not need a routing protocol at all. >>=20 >>=20 >> I agree. >>=20 >>=20 >> I like the wording in the charter, but it MAY need to be more clear to >> distinguish between ROLL and MANET charters I think the AD can help us >> in this matter. >>=20 >>=20 >>=20 >> (Note that just as the absence of movement does not imply a static >> topology, a static topology does not imply stationary nodes). >>=20 >>=20 >> So I don't think MANETs are defined by mobility, but by "increased >> dynamics",which can be due to motion, but also to lossy links. >>=20 >>=20 >> So why aren't they called ANETs? >>=20 >>=20 >> Or DANET ("dynamic"). It just did not sound as nice when the term was >> created. >>=20 >>=20 >> I like that *dynamic* word, I agree with it, but we don't forget that >> ROLL or LLNs are also DANETs so there SHOULD be differences when we >> read through their documents and also in MANET documents which I am >> trying to solve by my drafts [1] and [2]. >>=20 >> I agree that Mobility is the Mostly the concern of MANET (use cases >> and applicability), so the *dynamic* is mostly caused by Mobility in >> MANET, but in LLNs the *dynamic* is Mostly caused by the Losses or Low >> power. I will put that in my terminology draft :) >>=20 >>=20 >>=20 >> I don't think we can distinguish LLN and MANET by *mobility*. In LLNs, t= he >> mobility can be not only caused by radio, but also physical movement, su= ch >> as in wildlife monitoring, water monitoring, etc. You can find a lot of >> examples of that. >>=20 >> The key point of LLN is "low power", i.e., resource constrained. A vehic= le >> network is a MANET, but we won't say it's a LLN. >>=20 >> Therefore, I would rather say LLN is resource constrained MANET. >>=20 >>=20 >>=20 >> [1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >> [2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >>=20 >> Best Regards >>=20 >> Abdussalam Baryun >> University of glamorgan, UK >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >>=20 >>=20 >>=20 >> Ronald >>=20 >>=20 >> 2012/7/31 Ulrich Herberg : >>=20 >> MANETs are not defined by mobility. It is rather about very dynamic >> topologies. Otherwise, community networks such as FunkFeuer would also >> not be qualified as MANETs. >>=20 >> Ulrich >>=20 >>=20 >> On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal wrote: >>=20 >>=20 >> The wireless network of "fixed" temperature monitoring sensors and >> HVAC controllers in a building. This network is an LLN. Not sure if >> it qualifies as a MANET (since nothing is mobile). >>=20 >> Thanks >> Mukul >>=20 >> ----- Original Message ----- >> From: "Henning Rogge" >> To: "Abdussalam Baryun" >> Cc: "manet" >> Sent: Tuesday, July 31, 2012 8:49:08 AM >> Subject: Re: [manet] Discussing LOADng suggestions >>=20 >> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >> wrote: >>=20 >> IMHO this protocol was intended as for ROLL WG not for MANET WG, >> but then changed its direction to MANET [3]. However, please note >> that >> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. >>=20 >> That >>=20 >> said, LOADng SHOULD specfy where is its limits. Then we can discuss >> adoption. >>=20 >>=20 >> Could you state an example what would be considered a LLN but not a >> MANET. I normally consider LLNs a subset of what we call MANETs. >>=20 >> Henning Rogge >>=20 >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >> This e-mail and its contents are subject to the DISCLAIMER at >> http://www.tno.nl/emaildisclaimer >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 From yi.jiazi@gmail.com Wed Aug 1 14:49:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B40411E8193 for ; Wed, 1 Aug 2012 14:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AozrVP1czLiv for ; Wed, 1 Aug 2012 14:48:58 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 396F511E811A for ; Wed, 1 Aug 2012 14:48:58 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so1743077pbb.31 for ; Wed, 01 Aug 2012 14:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=UN9v7ctQamg84y5MokjkQpnxA42CJRYX9Wv04fIex1s=; b=qEjfZiOO7NbwW4rAkpTFboTtVqUdAod0aKYkiyGdGCEggQpChFRRBcAfe1R4dkJIY5 BekB4il0sBseGUvKbg7n8eTodr3/AZYbst8fQD00kPNGjQbz3m0d1OnGrFWdRmGty1nV j8S65r/H/L7MDDQ4YjZCCESwW+UlQZ0x9QPjGSDVgJ9iEbS/50xj5h1Ci2S7tZTUnrPE qW0+eG56W4bf+IewSl7CpggNQ5QOyVUq1+7xPu7t+hw4uOjfzu7D3zX0ZcmNd4g7PXWo 4zOL17GBBlX6RnhCIqf3DRS66G7mdOovSOoPIWQKJq09w9BFlwimus6mQxQIk1E/bUwg iFcQ== Received: by 10.68.235.236 with SMTP id up12mr55017913pbc.79.1343857737858; Wed, 01 Aug 2012 14:48:57 -0700 (PDT) Received: from dhcp-3210.meeting.ietf.org (dhcp-3210.meeting.ietf.org. [130.129.50.16]) by mx.google.com with ESMTPS id pe8sm3322831pbc.76.2012.08.01.14.48.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 14:48:57 -0700 (PDT) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_BE74323F-4154-46E2-BC39-9A159E51CB45" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Jiazi YI In-Reply-To: <2E2A2F97-A304-4DE1-A864-4083159DC019@watteco.com> Date: Wed, 1 Aug 2012 14:48:57 -0700 Message-Id: <61955055-5B25-495D-B941-E60CFA666D23@jiaziyi.com> References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> <2C6647B8-18F9-4039-B1E2-5371E4F27EF7@jiaziyi.com> <4F314E84-0E4A-47C0-A27B-19E40B634B0C@watteco.com> <943624B4-3678-483B-85EF-19ACD204180F@jiaziyi.com> <2E2A2F97-A304-4DE1-A864-4083159DC019@watteco.com> To: C Chauvenet X-Mailer: Apple Mail (2.1485) Cc: MANET IETF Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 21:49:00 -0000 --Apple-Mail=_BE74323F-4154-46E2-BC39-9A159E51CB45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, > I agree that the LOADng draft would need some rewording regarding the = applicability, but I think that changing such an important thing will = impact the protocol itself. I don't think so. LOADng doesn't assume any specified traffic pattern, = so it can be applied in general MANET scenarios.=20 On Aug 1, 2012, at 2:18 PM, C Chauvenet wrote: > Hi,=20 >=20 > In my view things are simple. >=20 > According to the (new ?) LOADng scope (a MANET routing protocol = applicable to LLN), there are 2 places possible : >=20 > - A place for a routing protocol in LLN, which is already taken = by RPL, designed in ROLL. > - A place for a reactive protocols in MANET, still to be = attributed, and I understood that it was the intend of DYMO. >=20 > I'm simply wondering where is the place for LOADng ? >=20 > C=E9dric. You are right that MANET is charted to have a reactive routing protocol, = and my understanding is that IETF believes in running code.=20 best Jiazi >=20 > Le 1 ao=FBt 2012 =E0 22:58, Antonin Bas a =E9crit : >=20 >> Hi, >>=20 >> The LOADng draft indeed need some rewording. >> And you are right, all MANET protocols cannot be applied to LLNs. >> LOADng is a MANET routing protocol which has been found to perform >> well even with LLNs. It is for instance more energy efficient than >> AODV, which make it more adapted for the resource constrained nature >> of LLNs. >>=20 >> Antonin >>=20 >> 2012/8/1 C Chauvenet : >>> Hi, >>>=20 >>> Thank you for the clarification. >>>=20 >>> LOADng is a MANET routing protocol, and therefore can be applied to = LLN. >>>=20 >>>=20 >>> Not sure that this statement is true, otherwise all MANET protocols = can be >>> applied to LLN, and as we agreed before, they have different = constraints. >>>=20 >>> I agree that the LOADng draft would need some rewording regarding = the >>> applicability, but I think that changing such an important thing = will >>> impact the protocol itself. >>>=20 >>> C=E9dric. >>>=20 >>> Le 1 ao=FBt 2012 =E0 22:31, Jiazi YI a =E9crit : >>>=20 >>> Hi, >>>=20 >>> LOADng is a MANET routing protocol, and therefore can be applied to = LLN. >>> The authors are discussing about rephrasing some of the text in >>> abstract/introduction/applicability statement based on the feedback = from >>> the WG. >>>=20 >>> regards >>>=20 >>> Jiazi >>>=20 >>>=20 >>> On Aug 1, 2012, at 12:58 PM, C Chauvenet = wrote: >>>=20 >>> Hi, >>>=20 >>> The key point of LLN is "low power", i.e., resource constrained. >>>=20 >>>=20 >>> Agree. I tried to make the difference clear in a previous mail when = parsing >>> the constraints of LLN Vs MANET. >>>=20 >>> A vehicle network is a MANET, but we won't say it's a LLN. >>>=20 >>> Therefore, I would rather say LLN is resource constrained MANET. >>>=20 >>>=20 >>> Agree. >>>=20 >>> I think most of people on the list agree that LLN and MANET are not >>> identical, and that, as you mentioned, LLN are more resource = constrained. >>>=20 >>> That's why IETF created ROLL in the routing area for these specific = needs. >>>=20 >>> http://tools.ietf.org/html/draft-clausen-lln-loadng-05#section-3 = states that >>> it target LLN. >>>=20 >>> So I'm a little bit surprised about this submission in MANET. >>>=20 >>> Could you clarify the scope of LOADng regarding the MANET scope ? >>>=20 >>> C=E9dric. >>>=20 >>> Le 1 ao=FBt 2012 =E0 20:53, Jiazi YI a =E9crit : >>>=20 >>> Hi, >>>=20 >>> please check inline: >>>=20 >>>=20 >>> On Aug 1, 2012, at 12:41 AM, Abdussalam Baryun = >>> wrote: >>>=20 >>> Hi Ulrich, >>>=20 >>> comments in lines: >>>=20 >>> According to MANET charter, >>>=20 >>> The purpose of the MANET working group is to standardize IP routing >>> protocol functionality suitable for wireless routing application >>> within >>> both static and dynamic topologies with increased dynamics due to = node >>> motion or other factors. >>>=20 >>>=20 >>> Strange wording, in my opinion. It seems to me that if the network >>> _topology_ is truly static, you do not need a routing protocol at = all. >>>=20 >>>=20 >>> I agree. >>>=20 >>>=20 >>> I like the wording in the charter, but it MAY need to be more clear = to >>> distinguish between ROLL and MANET charters I think the AD can help = us >>> in this matter. >>>=20 >>>=20 >>>=20 >>> (Note that just as the absence of movement does not imply a static >>> topology, a static topology does not imply stationary nodes). >>>=20 >>>=20 >>> So I don't think MANETs are defined by mobility, but by "increased >>> dynamics",which can be due to motion, but also to lossy links. >>>=20 >>>=20 >>> So why aren't they called ANETs? >>>=20 >>>=20 >>> Or DANET ("dynamic"). It just did not sound as nice when the term = was >>> created. >>>=20 >>>=20 >>> I like that *dynamic* word, I agree with it, but we don't forget = that >>> ROLL or LLNs are also DANETs so there SHOULD be differences when we >>> read through their documents and also in MANET documents which I am >>> trying to solve by my drafts [1] and [2]. >>>=20 >>> I agree that Mobility is the Mostly the concern of MANET (use cases >>> and applicability), so the *dynamic* is mostly caused by Mobility in >>> MANET, but in LLNs the *dynamic* is Mostly caused by the Losses or = Low >>> power. I will put that in my terminology draft :) >>>=20 >>>=20 >>>=20 >>> I don't think we can distinguish LLN and MANET by *mobility*. In = LLNs, the >>> mobility can be not only caused by radio, but also physical = movement, such >>> as in wildlife monitoring, water monitoring, etc. You can find a lot = of >>> examples of that. >>>=20 >>> The key point of LLN is "low power", i.e., resource constrained. A = vehicle >>> network is a MANET, but we won't say it's a LLN. >>>=20 >>> Therefore, I would rather say LLN is resource constrained MANET. >>>=20 >>>=20 >>>=20 >>> [1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >>> [2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >>>=20 >>> Best Regards >>>=20 >>> Abdussalam Baryun >>> University of glamorgan, UK >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Ronald >>>=20 >>>=20 >>> 2012/7/31 Ulrich Herberg : >>>=20 >>> MANETs are not defined by mobility. It is rather about very dynamic >>> topologies. Otherwise, community networks such as FunkFeuer would = also >>> not be qualified as MANETs. >>>=20 >>> Ulrich >>>=20 >>>=20 >>> On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal wrote: >>>=20 >>>=20 >>> The wireless network of "fixed" temperature monitoring sensors and >>> HVAC controllers in a building. This network is an LLN. Not sure if >>> it qualifies as a MANET (since nothing is mobile). >>>=20 >>> Thanks >>> Mukul >>>=20 >>> ----- Original Message ----- >>> From: "Henning Rogge" >>> To: "Abdussalam Baryun" >>> Cc: "manet" >>> Sent: Tuesday, July 31, 2012 8:49:08 AM >>> Subject: Re: [manet] Discussing LOADng suggestions >>>=20 >>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>> wrote: >>>=20 >>> IMHO this protocol was intended as for ROLL WG not for MANET WG, >>> but then changed its direction to MANET [3]. However, please note >>> that >>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. >>>=20 >>> That >>>=20 >>> said, LOADng SHOULD specfy where is its limits. Then we can discuss >>> adoption. >>>=20 >>>=20 >>> Could you state an example what would be considered a LLN but not a >>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>=20 >>> Henning Rogge >>>=20 >>> -- >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>> billions of percent in a tiny fraction of a second. Of course, that >>> was before the present government." >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> This e-mail and its contents are subject to the DISCLAIMER at >>> http://www.tno.nl/emaildisclaimer >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >=20 >=20 --Apple-Mail=_BE74323F-4154-46E2-BC39-9A159E51CB45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi,

I agree that the LOADng draft would need some rewording = regarding the applicability, but I think that changing such an important = thing will  impact the protocol itself.

I don't think so. LOADng doesn't assume = any specified traffic pattern, so it can be applied in general MANET = scenarios. 

=
On Aug 1, 2012, at 2:18 PM, C Chauvenet <c.chauvenet@watteco.com> = wrote:

Hi,

In my view things are simple.

According = to the (new ?) LOADng scope (a MANET routing protocol applicable to = LLN), there are 2 places possible :

- A place for a routing protocol = in LLN, which is already taken by RPL, designed in ROLL.
- A place = for a reactive protocols in MANET, still to be attributed, and I = understood that it was the intend of DYMO.

I'm simply wondering = where is the place for LOADng = ?

C=E9dric.


You = are right that MANET is charted to have a reactive routing protocol, and = my understanding is that IETF believes in running = code. 

best

Jiazi



Le 1 ao=FBt 2012 =E0 = 22:58, Antonin Bas a =E9crit :

Hi,

The LOADng draft indeed need some = rewording.
And you are right, all MANET protocols cannot be applied = to LLNs.
LOADng is a MANET routing protocol which has been found to = perform
well even with LLNs. It is for instance more energy efficient = than
AODV, which make it more adapted for the resource constrained = nature
of LLNs.

Antonin

2012/8/1 C Chauvenet <c.chauvenet@watteco.com>:
Hi,

Thank you for the = clarification.

LOADng is a MANET routing protocol, and therefore = can be applied to LLN.


Not sure that this statement is true, = otherwise all MANET protocols can be
applied to LLN, and as we agreed = before, they have different constraints.

I agree that the LOADng = draft would need some rewording regarding the
applicability, but I = think that changing such an important thing will
impact the protocol = itself.

C=E9dric.

Le 1 ao=FBt 2012 =E0 22:31, Jiazi YI a = =E9crit :

Hi,

LOADng is a MANET routing protocol, and = therefore can be applied to LLN.
The authors are discussing about = rephrasing some of the text in
abstract/introduction/applicability = statement  based on the feedback from
the = WG.

regards

Jiazi


On Aug 1, 2012, at 12:58 PM, = C Chauvenet <c.chauvenet@watteco.com> = wrote:

Hi,

The key point of LLN is "low power", i.e., = resource constrained.


Agree. I tried to make the difference = clear in a previous mail when parsing
the constraints of LLN Vs = MANET.

A vehicle network is a MANET, but we won't say it's a = LLN.

Therefore, I would rather say LLN is resource constrained = MANET.


Agree.

I think most of people on the list agree = that LLN and MANET are not
identical, and that, as you mentioned, LLN = are more resource constrained.

That's why IETF created ROLL in = the routing area for these specific needs.

= http://tools.ietf.org/html/draft-clausen-lln-loadng-05#section-3 = states that
it target LLN.

So I'm a little bit surprised about = this submission in MANET.

Could you clarify the scope of LOADng = regarding the MANET scope ?

C=E9dric.

Le 1 ao=FBt 2012 =E0 = 20:53, Jiazi YI a =E9crit :

Hi,

please check = inline:


On Aug 1, 2012, at 12:41 AM, Abdussalam Baryun <abdussalambaryun@gmail.com&= gt;
wrote:

Hi Ulrich,

comments in = lines:

According to MANET charter,

The purpose of the = MANET working group is to standardize IP routing
protocol = functionality suitable for wireless routing = application
within
both static and dynamic topologies with = increased dynamics due to node
motion or other = factors.


Strange wording, in my opinion. It seems to me that = if the network
_topology_ is truly static, you do not need a routing = protocol at all.


I agree.


I like the wording in = the charter, but it MAY need to be more clear to
distinguish between = ROLL and MANET charters I think the AD can help us
in this = matter.



(Note that just as the absence of movement does = not imply a static
topology, a static topology does not imply = stationary nodes).


So I don't think MANETs are defined by = mobility, but by "increased
dynamics",which can be due to motion, but = also to lossy links.


So why aren't they called = ANETs?


Or DANET ("dynamic"). It just did not sound as nice = when the term was
created.


I like that *dynamic* word, I = agree with it, but we don't forget that
ROLL or LLNs are also DANETs = so there SHOULD be differences when we
read through their documents = and also in MANET documents which I am
trying to solve by my drafts = [1] and [2].

I agree that Mobility is the Mostly the concern of = MANET (use cases
and applicability), so the *dynamic* is mostly = caused by Mobility in
MANET, but in LLNs the *dynamic* is Mostly = caused by the Losses or Low
power. I will put that in my terminology = draft :)



I don't think we can distinguish LLN and MANET = by *mobility*. In LLNs, the
mobility can be not only caused by radio, = but also physical movement, such
as in wildlife monitoring, water = monitoring, etc. You can find a lot of
examples of that.

The = key point of LLN is "low power", i.e., resource constrained. A = vehicle
network is a MANET, but we won't say it's a = LLN.

Therefore, I would rather say LLN is resource constrained = MANET.



[1] http= ://www.ietf.org/id/draft-baryun-manet-terminology-00.txt
[2] http:= //www.ietf.org/id/draft-baryun-manet-technology-00.txt

Best = Regards

Abdussalam Baryun
University of glamorgan, = UK

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D





Ronald


2012/= 7/31 Ulrich Herberg <ulrich@herberg.name>:

MA= NETs are not defined by mobility. It is rather about very = dynamic
topologies. Otherwise, community networks such as FunkFeuer = would also
not be qualified as MANETs.

Ulrich


On = Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal <mukul@uwm.edu> = wrote:


The wireless network of "fixed" temperature monitoring = sensors and
HVAC controllers in a building. This network is an LLN. = Not sure if
it qualifies as a MANET (since nothing is = mobile).

Thanks
Mukul

----- Original Message = -----
From: "Henning Rogge" <hrogge@googlemail.com>
To:= "Abdussalam Baryun" <abdussalambaryun@gmail.com&= gt;
Cc: "manet" <manet@ietf.org>
Sent: Tuesday, = July 31, 2012 8:49:08 AM
Subject: Re: [manet] Discussing LOADng = suggestions

On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam = Baryun
<abdussalambaryun@gmail.com&= gt; wrote:

IMHO this protocol was intended as for ROLL WG not for = MANET WG,
but then changed its direction to MANET [3]. However, = please note
that
*ONLY* some LLNs are MANETs, and *ONLY* some = MANETs are LLNs.

That

said, LOADng SHOULD specfy where is = its limits. Then we can discuss
adoption.


Could you state = an example what would be considered a LLN but not a
MANET. I normally = consider LLNs a subset of what we call MANETs.

Henning = Rogge

--
Steven Hawkings about cosmic inflation: "An increase = of billions of
billions of percent in a tiny fraction of a second. Of = course, that
was before the present = government."
_______________________________________________
manet = mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet
_______________________________________________<= br>manet mailing = list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
<= br>


_______________________________________________
manet = mailing = list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
<= br>_______________________________________________
manet mailing = list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
<= br>This e-mail and its contents are subject to the DISCLAIMER = at
http://www.tno.nl/emaildisclaimer



___________________= ____________________________
manet mailing = list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
<= br>
_______________________________________________
manet mailing = list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
<= br>



_______________________________________________
mane= t mailing = list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
<= br>




= --Apple-Mail=_BE74323F-4154-46E2-BC39-9A159E51CB45-- From abdussalambaryun@gmail.com Thu Aug 2 00:40:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DBF21F8D3B for ; Thu, 2 Aug 2012 00:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN1seO2iGDrT for ; Thu, 2 Aug 2012 00:40:05 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A426421F860B for ; Thu, 2 Aug 2012 00:39:58 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so8539837vcb.31 for ; Thu, 02 Aug 2012 00:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Tbnmd0d4SIrtA7HZ9gM1Lcua9kKyZ7PjEjHMkxerGiw=; b=TxAH8MN7O2w1h/YlfmnttLgbEjGHDyS95Z6r7SlFFtEbCBlNrl3POMcmHPzfo00QJb HuigtOR82WqOWMwaJtMjFEqziandracstlqEAZosIlNgLZbBR5vPz19d3ONXiw0Jarzs nF83EktLRu5LHgA0GURKD87WPkWu6g1RefihV6+mPU0xQoo7iEUCGpr2/rCMjxNC4S0d rtdtRRvEUqAYV5WMi85oUmzJP8LZB0Wb8jVBLC0zk/v3ZDu/+qtg78EN4wYX/jVqqvtu cdxNqy4Zld0QbbeemHK+TPj+3MGB4OyjnBrMZpn+FIKuFtB4pqZr98mlLGdTYsNq0exF ia4A== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr3279133vds.117.1343893198007; Thu, 02 Aug 2012 00:39:58 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Thu, 2 Aug 2012 00:39:57 -0700 (PDT) In-Reply-To: <2C6647B8-18F9-4039-B1E2-5371E4F27EF7@jiaziyi.com> References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> <2C6647B8-18F9-4039-B1E2-5371E4F27EF7@jiaziyi.com> Date: Thu, 2 Aug 2012 09:39:57 +0200 Message-ID: From: Abdussalam Baryun To: Jiazi YI Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 07:40:07 -0000 Hi Jiazi please check inline: > > > I don't think we can distinguish LLN and MANET by *mobility*. In LLNs, the > mobility can be not only caused by radio, but also physical movement, such > as in wildlife monitoring, water monitoring, etc. You can find a lot of > examples of that. The Low power is in the LLN abbreviation, and Mobile is in MANET. so it is simple for many, but what you understand from the word mobile attached to MANET, please explain, is it like some say its dynamic as DANET, > > The key point of LLN is "low power", i.e., resource constrained. A vehicle > network is a MANET, but we won't say it's a LLN. I think the key point is low power and lossy node as simply mentioned and its a DANET also. But I can add that not all LLN are Ad-Hoc ( is the "A" in MANET). > > Therefore, I would rather say LLN is resource constrained MANET. LLN is not only about resources it may have situations like MANET, so I hope that IETF solves this issue before its solved else where. AB > > >> >> [1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >> [2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >> >> Best Regards >> >> Abdussalam Baryun >> University of glamorgan, UK >> >> =============================== >>> >>> >>> >>>> >>>> Ronald >>>>> >>>>> 2012/7/31 Ulrich Herberg : >>>>>> MANETs are not defined by mobility. It is rather about very dynamic >>>>>> topologies. Otherwise, community networks such as FunkFeuer would >>>>>> also >>>>>> not be qualified as MANETs. >>>>>> >>>>>> Ulrich >>>>>> >>>>>> >>>>>> On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal wrote: >>>>>>> >>>>>>> The wireless network of "fixed" temperature monitoring sensors and >>>>>>> HVAC controllers in a building. This network is an LLN. Not sure if >>>>>>> it qualifies as a MANET (since nothing is mobile). >>>>>>> >>>>>>> Thanks >>>>>>> Mukul >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Henning Rogge" >>>>>>> To: "Abdussalam Baryun" >>>>>>> Cc: "manet" >>>>>>> Sent: Tuesday, July 31, 2012 8:49:08 AM >>>>>>> Subject: Re: [manet] Discussing LOADng suggestions >>>>>>> >>>>>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>>>>>> wrote: >>>>>>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, >>>>>>>> but then changed its direction to MANET [3]. However, please note >>>>>>>> that >>>>>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. >>>>> That >>>>>>>> said, LOADng SHOULD specfy where is its limits. Then we can discuss >>>>>>>> adoption. >>>>>>> >>>>>>> Could you state an example what would be considered a LLN but not a >>>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>>> >>>>>>> Henning Rogge >>>>>>> >>>>>>> -- >>>>>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>>>>> billions of percent in a tiny fraction of a second. Of course, that >>>>>>> was before the present government." >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>> >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>> This e-mail and its contents are subject to the DISCLAIMER at >>>> http://www.tno.nl/emaildisclaimer >>>> >>>> >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From Chris.Dearlove@baesystems.com Thu Aug 2 02:12:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA48E21F8E49 for ; Thu, 2 Aug 2012 02:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.986 X-Spam-Level: X-Spam-Status: No, score=-9.986 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suk2OaOJful7 for ; Thu, 2 Aug 2012 02:12:57 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 9408021F8E47 for ; Thu, 2 Aug 2012 02:12:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,699,1336345200"; d="scan'208";a="260761774" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 02 Aug 2012 10:12:48 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q729Clvv004059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 10:12:48 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.170]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Thu, 2 Aug 2012 10:12:48 +0100 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" Thread-Topic: [manet] Some LLNs are NOT MANETs Thread-Index: AQHNb+izbH1tyYFgl06MELNnv/B9tZdFE3cg////qYCAASeJoA== Date: Thu, 2 Aug 2012 09:12:47 +0000 Message-ID: References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , Abdussalam Baryun Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 09:12:59 -0000 I would subtly differently emphasise your point. (I think we are basically = in agreement.) I would view ad hoc networks (I'm going to avoid the MANET t= erm as it's overloaded here) as a broad area. LLNs are a specialist sub-are= a within that area. The MANET WG in principle covers the whole of the area,= and most of its work has created protocols that can cover most of that are= a. However where there are specialised, and in particular more limited requ= irement, sub-areas, specialised protocols may make a better trade-off (typi= cally be simpler). And you have emphasised one of the key differences, the = differing traffic pattern, and in particular the dominant role of an egress= (or ingress, but egress is often more important) gateway rather than peer= to peer communications (which in an LLN are typically either absent, or ra= re enough that the otherwise inefficient go via gateway, possibly optimised= to clip off reused links, is acceptable). (This bit may or may not be in agreement with Stan.) Note that I'm not sayi= ng that you can't use e.g. OLSRv2 in an LLN, but that if you have more limi= ted/specialised requirements you may be able to do better. Nor am I saying = RPL or LOADng is (or is not) that better solution, I've studied neither in = enough detail to have a view. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: 01 August 2012 17:23 To: Dearlove, Christopher (UK) Cc: Abdussalam Baryun; C Chauvenet; manet Subject: Re: [manet] Some LLNs are NOT MANETs ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Precisely, Chris.=20 I've come to view MANETs more and more in the terms of an "opportunistic ne= twork". By that, I mean a network with a fairly large amount of dynamism, a= nd also a network that contains heterogeneity of links (e.g., different rad= io types, and/or some wired portions). The challenge of these networks is t= o opportunistically (and maximally) use the resources available to it at an= y point in time.=20 And at least for me (and I know this will draw some fire in return), anothe= r distinction in MANET as opposed to LLN is a greater requirement for peer-= to-peer (node-to-node) communication, From what I've seen of LLN deployment= s (and I'm no expert), they tend to have more of a "multiple source/single = sink" model for the data flow. Again, just one opinion.=20 Regards, Stan On Aug 1, 2012, at 11:26 AM, Dearlove, Christopher (UK) wrote: > The statement that MANETs refers only to networks with physical mobility = is simply false. While the expansion of the acronym might suggest that, in = fact MANET has become a term of art, and that art includes many networks wi= th some or all nodes that are not physically moving. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Abdussalam Baryun > Sent: 01 August 2012 14:21 > To: C Chauvenet > Cc: manet > Subject: Re: [manet] Some LLNs are NOT MANETs >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Hi C=E9dric, >=20 > Ok we can discuss efficiently when we read the documents (production > of such WG)as you agreed. >=20 >> When you say "IMHO, as long we have a ROLL WG in IETF we need to forward >> work to it which has no mobility behavior", do you mean that the differe= nce >> between ROLL and MANET is limited to mobility considerations ? >=20 > *Mobility* It is the mostly difference clearly spoted between the > documents produced by the both WGs, also the name MANET starts with > Mobile, the word mobile is not equal to change/dynamic. So MANET > refers to mobile node or mobile network, which means location change > *NOT* topology change/dynamic. In the old days there was no ROLL WG so > MANET WG was doing the job. >=20 >>=20 >> Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC586= 7 >> all include the usual IoT constraints : Memory, Processing, Power, Batte= ry, >> Cost and Size of device. >> RFC5673 does not mention explicitly processing and size constraints, but >> mention all the others. >>=20 >=20 > Ok, >=20 >> RFC 2501 speak about energy and power, as you previously mentioned, but = does >> not say something on the following constraints : Memory, Processing, Co= st >> and Size. >=20 > Yes your right, but be careful RFC2501 does not exclude thoes > constraints either. However, if the MANET network has some nodes with > constraints but clearly mobility is the main constraint. >=20 >>=20 >> Do you think that these constraints are in the MANET scope ? >> I guess that they may be (obviously for Cost), but not in the same order= of >> magnitude as the type of devices described in the requirements RFC of RO= LL. >=20 > Really don't mind either way for MANET WG, and will think that the WG > community wants it in between In-Scope and Out-Scope, that may be > strange but seems that is what is happening as I read documents. Out > of IETF, MANET is mostly understood as mobile nodes connecting, not > LLNs. >=20 > Overall, IMHO, in the end it is the decision of the IETF community to > decide of any new idea or any I-D acceptance/adoption, but for the WG > it MAY take over a WORK as an IETF I-D, but it may not be successful > to convince the IETF community to continue the work or make it become > a RFC, we always have to see through to make the work efforts flow > successfully. We do not forget that many participants work in both > WGs. >=20 > Regards > Abdussalam > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > On 8/1/12, C Chauvenet wrote: >> Hi, >>=20 >> Thank you for your answer, >>=20 >> See inline. >>=20 >> Le 1 ao=FBt 2012 =E0 13:41, Abdussalam Baryun a =E9crit : >>=20 >>> Hi C=E9dric, >>>=20 >>> I think the RFC2501 is more important than the WG charter, because the >>> charter MAY change but RFCs never changes (only can be updated, >>> obsoleted or replaced). >>=20 >> Good Point, 100% agree. >>=20 >>> So far now all MANET-protocols are refering to >>> RFC2501 which is good and SHOULD continue, and I like this referencing >>> to documents (even if they are old or expired) not referencing to >>> charters, because for example, if in a journal paper we reference to >>> the charter of MANET WG or ROLL WG the information is not solid like >>> if you reference a published document (publisher date), but still we >>> can reference the charter as web reference sited date. >>>=20 >>> I read some paper that reference sited web documents but they may be >>> not valid and cannot be read for some reason. Therefore, IMHO, we need >>> to stick to the following document to make a right decision in >>> definitions: >>>=20 >>> 1) [RFC2501] for MANETs. (published in 1999) >>> 2) [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] for LLNs. >>> (published in 2009) >>=20 >> I think they are good references to build some arguments into this >> discussion. >>=20 >>>=20 >>> Low power was indicated in RFC2501 in section 5.1 as >> constraints> and also the word *sink*, in page 7 you read >> for energy conservation>. IMHO, as long we have a ROLL WG in IETF we >>> need to forward work to it which has no mobility behavior. Delegation >>> will help make work flowing and more focused. >>=20 >> When you say "IMHO, as long we have a ROLL WG in IETF we need to forward >> work to it which has no mobility behavior", do you mean that the differe= nce >> between ROLL and MANET is limited to mobility considerations ? >>=20 >> Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC586= 7 >> all include the usual IoT constraints : Memory, Processing, Power, Batte= ry, >> Cost and Size of device. >> RFC5673 does not mention explicitly processing and size constraints, but >> mention all the others. >>=20 >> RFC 2501 speak about energy and power, as you previously mentioned, but = does >> not say something on the following constraints : Memory, Processing, Co= st >> and Size. >>=20 >> Do you think that these constraints are in the MANET scope ? >> I guess that they may be (obviously for Cost), but not in the same order= of >> magnitude as the type of devices described in the requirements RFC of RO= LL. >>=20 >> Regards, >>=20 >> C=E9dric. >>=20 >>>=20 >>> Regards >>> AB >>> =3D=3D=3D=3D=3D=3D=3D >>>=20 >>> On 8/1/12, C Chauvenet wrote: >>>> Hi, >>>>=20 >>>> This is an interesting discussion. >>>>=20 >>>> My understanding is that both MANET and ROLL considers lossy/dynamic >>>> links >>>> in the way described in the MANET charter : "static and dynamic >>>> topologies >>>> with increased dynamics due to node motion or other factors." I also >>>> agree >>>> that dynamicity of links is not hard wired to node mobility. >>>>=20 >>>> So, in the LLN Vs MANET debate, I think they share the "N" for Network= s, >>>> and >>>> the 2nd "L" for Lossy. >>>> So the remaining point is the first L, meaning Low Power. >>>>=20 >>>> Low Power requirements is explicit in the ROLL charter and not mention= ed >>>> at >>>> all in the MANET charter. >>>> Is the power efficiency consideration the big difference between ROLL >>>> and >>>> MANET ? >>>>=20 >>>> C=E9dric. >>>>=20 >>>> -----Message d'origine----- >>>> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part d= e >>>> Abdussalam Baryun >>>> Envoy=E9 : mercredi 1 ao=FBt 2012 09:22 >>>> =C0 : Henning Rogge >>>> Cc : roll; manet >>>> Objet : [Roll] Some LLNs are NOT MANETs >>>>=20 >>>> Hi Henning, >>>>=20 >>>> I am about to say many LLNs are NOT MANETs but it seems like the marke= t >>>> or >>>> community will decide the outcome, but surly that some LLNs are NOT >>>> MANETs. >>>>=20 >>>>> Could you state an example what would be considered a LLN but not a >>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>=20 >>>> I not totally agree with that, because we need to be considering both >>>> NETs >>>> use case and applicability in the vision of the different WGs (MANET a= nd >>>> ROLL). There are many examples we can find them in the [RFC2501] for >>>> MANETs >>>> characteristics and applicability, and for LLNs characteristics in >>>> [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs >>>> requirements. That is why I suggested before that >>>> OLSRv2 and AODVv2 should mention their applicability to LLN if they do= . >>>> They >>>> just refer to RFC2501, but RFC2501 is OLD and does not mention LLN but >>>> describes the meaning. The authors of RFC2501 still not responded to m= y >>>> update suggestions. >>>>=20 >>>> I understood from one discussion in MANET WG that few don't have time = to >>>> read many pages of documents, so that is why I suggested to have >>>> terminology >>>> I-D [1] as we have ROLL terminology [ROLL] . I also taken initiative t= o >>>> make >>>> new draft of MANET subnet technologies which include only related LLN= s >>>> [AB2]. >>>>=20 >>>> Therefore, I will add the definition for MANET and LLN into my >>>> manet-terminology draft [AB1] (propose that authors of [ROLL] define L= LN >>>> more details) to assist discussions as it is proved now in the list th= at >>>> there still is problems in definitions in MANET WG or in some I-D >>>> editorial >>>> content. >>>>=20 >>>> [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >>>> [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >>>> [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt >>>>=20 >>>> Best Wishes >>>>=20 >>>> Abdussalam Baryun >>>> University of Glamorgan, UK >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>> On 7/31/12, Henning Rogge wrote: >>>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>>>> subject: Re: [manet] Discussing LOADng suggestions >>>>> wrote: >>>>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, but >>>>>> then changed its direction to MANET [3]. However, please note that >>>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >>>>>> said, LOADng SHOULD specfy where is its limits. Then we can discuss >>>>>> adoption. >>>>>=20 >>>>> Could you state an example what would be considered a LLN but not a >>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>=20 >>>>> Henning Rogge >>>>>=20 >>>>> -- >>>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>>> billions of percent in a tiny fraction of a second. Of course, that >>>>> was before the present government." >>>>>=20 >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Thu Aug 2 08:54:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1295D21F86A7 for ; Thu, 2 Aug 2012 08:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u96dZzmtymnz for ; Thu, 2 Aug 2012 08:54:04 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE8D21F869A for ; Thu, 2 Aug 2012 08:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=17027; q=dns/txt; s=iport; t=1343922844; x=1345132444; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MBrJpIktTerGVlwmbVAXU7q9j0ahawi2V5AHpD+2qoY=; b=LDPXi6Zkt3RGcLbztCR9WWhg5W2w3RlY1g0RxoLB2Ud4OS63DrURMOZC j6pRDjyWD5zQt3qgLF1G1C1VSrcFj54U8nsLmVirgxsdtmsPxebTNJgSs Njd2hhzy2xA0KCXnjPs/AdCUKw/9anj1LxZtIhG7tLnQqlRu6nyG1Uo6a Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANChGlCtJV2c/2dsb2JhbABFuQyBB4IgAQEBAwEBAQEPAUIWAwMIBQcEAgEIEQQBAQEnByEGCxQJCAIEDgUJCwcHh1wDBgYLnGCWdQ2JTopiZwUFCgcHhgJgA5N0gVOBFIl2gx2BZoJfgVYJ X-IronPort-AV: E=Sophos;i="4.77,701,1336348800"; d="scan'208";a="107903488" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 02 Aug 2012 15:54:03 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q72Fs3iQ001909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 15:54:03 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.180]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 10:51:44 -0500 From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] Some LLNs are NOT MANETs Thread-Index: AQHNb+i2NIMVZDkBeEWaaQkwSTqYtJdFaAmAgAAPqoCAARpEgIAAcBqA Date: Thu, 2 Aug 2012 15:54:02 +0000 Message-ID: <8BA2751C-A4A5-46E8-9027-22A94045C3FE@cisco.com> References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.237.184] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.006 x-tm-as-result: No--57.433200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , Abdussalam Baryun Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 15:54:06 -0000 Chris,=20 On Aug 2, 2012, at 5:12 AM, Dearlove, Christopher (UK) wrote: > I would subtly differently emphasise your point. (I think we are basicall= y in agreement.) I would view ad hoc networks (I'm going to avoid the MANET= term as it's overloaded here) as a broad area. LLNs are a specialist sub-a= rea within that area. The MANET WG in principle covers the whole of the are= a, and most of its work has created protocols that can cover most of that a= rea. However where there are specialised, and in particular more limited re= quirement, sub-areas, specialised protocols may make a better trade-off (ty= pically be simpler). And you have emphasised one of the key differences, th= e differing traffic pattern, and in particular the dominant role of an egre= ss (or ingress, but egress is often more important) gateway rather than pe= er to peer communications (which in an LLN are typically either absent, or = rare enough that the otherwise inefficient go via gateway, possibly optimis= ed to clip off reused links, is acceptable). >=20 > (This bit may or may not be in agreement with Stan.) Note that I'm not sa= ying that you can't use e.g. OLSRv2 in an LLN, but that if you have more li= mited/specialised requirements you may be able to do better. Nor am I sayin= g RPL or LOADng is (or is not) that better solution, I've studied neither i= n enough detail to have a view. >=20 No, we agree=85 As a mentor of mine once said, "You can do anything you're = big enough to try"=85 ;-) ;-) The definitions we're using (MANET and LLN) a= re somewhat vague, and somewhat overlapping. And any specific network's env= ironment could well lead to multiple choices for a routing protocol.=20 On another note, and more to the list at-large (instead of just replying to= Chris), we can argue this for days, or even weeks. But the truth of the ma= tter is that our charter references MANET networks, while the charter for R= OLL references LLN's. It's pretty much just that simple.=20 Regards, Stan > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 > Sent: 01 August 2012 17:23 > To: Dearlove, Christopher (UK) > Cc: Abdussalam Baryun; C Chauvenet; manet > Subject: Re: [manet] Some LLNs are NOT MANETs >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Precisely, Chris.=20 >=20 > I've come to view MANETs more and more in the terms of an "opportunistic = network". By that, I mean a network with a fairly large amount of dynamism,= and also a network that contains heterogeneity of links (e.g., different r= adio types, and/or some wired portions). The challenge of these networks is= to opportunistically (and maximally) use the resources available to it at = any point in time.=20 >=20 > And at least for me (and I know this will draw some fire in return), anot= her distinction in MANET as opposed to LLN is a greater requirement for pee= r-to-peer (node-to-node) communication, From what I've seen of LLN deployme= nts (and I'm no expert), they tend to have more of a "multiple source/singl= e sink" model for the data flow. >=20 > Again, just one opinion.=20 >=20 > Regards, > Stan >=20 > On Aug 1, 2012, at 11:26 AM, Dearlove, Christopher (UK) wrote: >=20 >> The statement that MANETs refers only to networks with physical mobility= is simply false. While the expansion of the acronym might suggest that, in= fact MANET has become a term of art, and that art includes many networks w= ith some or all nodes that are not physically moving. >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f Abdussalam Baryun >> Sent: 01 August 2012 14:21 >> To: C Chauvenet >> Cc: manet >> Subject: Re: [manet] Some LLNs are NOT MANETs >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> Hi C=E9dric, >>=20 >> Ok we can discuss efficiently when we read the documents (production >> of such WG)as you agreed. >>=20 >>> When you say "IMHO, as long we have a ROLL WG in IETF we need to forwar= d >>> work to it which has no mobility behavior", do you mean that the differ= ence >>> between ROLL and MANET is limited to mobility considerations ? >>=20 >> *Mobility* It is the mostly difference clearly spoted between the >> documents produced by the both WGs, also the name MANET starts with >> Mobile, the word mobile is not equal to change/dynamic. So MANET >> refers to mobile node or mobile network, which means location change >> *NOT* topology change/dynamic. In the old days there was no ROLL WG so >> MANET WG was doing the job. >>=20 >>>=20 >>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC58= 67 >>> all include the usual IoT constraints : Memory, Processing, Power, Batt= ery, >>> Cost and Size of device. >>> RFC5673 does not mention explicitly processing and size constraints, bu= t >>> mention all the others. >>>=20 >>=20 >> Ok, >>=20 >>> RFC 2501 speak about energy and power, as you previously mentioned, but= does >>> not say something on the following constraints : Memory, Processing, C= ost >>> and Size. >>=20 >> Yes your right, but be careful RFC2501 does not exclude thoes >> constraints either. However, if the MANET network has some nodes with >> constraints but clearly mobility is the main constraint. >>=20 >>>=20 >>> Do you think that these constraints are in the MANET scope ? >>> I guess that they may be (obviously for Cost), but not in the same orde= r of >>> magnitude as the type of devices described in the requirements RFC of R= OLL. >>=20 >> Really don't mind either way for MANET WG, and will think that the WG >> community wants it in between In-Scope and Out-Scope, that may be >> strange but seems that is what is happening as I read documents. Out >> of IETF, MANET is mostly understood as mobile nodes connecting, not >> LLNs. >>=20 >> Overall, IMHO, in the end it is the decision of the IETF community to >> decide of any new idea or any I-D acceptance/adoption, but for the WG >> it MAY take over a WORK as an IETF I-D, but it may not be successful >> to convince the IETF community to continue the work or make it become >> a RFC, we always have to see through to make the work efforts flow >> successfully. We do not forget that many participants work in both >> WGs. >>=20 >> Regards >> Abdussalam >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> On 8/1/12, C Chauvenet wrote: >>> Hi, >>>=20 >>> Thank you for your answer, >>>=20 >>> See inline. >>>=20 >>> Le 1 ao=FBt 2012 =E0 13:41, Abdussalam Baryun a =E9crit : >>>=20 >>>> Hi C=E9dric, >>>>=20 >>>> I think the RFC2501 is more important than the WG charter, because the >>>> charter MAY change but RFCs never changes (only can be updated, >>>> obsoleted or replaced). >>>=20 >>> Good Point, 100% agree. >>>=20 >>>> So far now all MANET-protocols are refering to >>>> RFC2501 which is good and SHOULD continue, and I like this referencing >>>> to documents (even if they are old or expired) not referencing to >>>> charters, because for example, if in a journal paper we reference to >>>> the charter of MANET WG or ROLL WG the information is not solid like >>>> if you reference a published document (publisher date), but still we >>>> can reference the charter as web reference sited date. >>>>=20 >>>> I read some paper that reference sited web documents but they may be >>>> not valid and cannot be read for some reason. Therefore, IMHO, we need >>>> to stick to the following document to make a right decision in >>>> definitions: >>>>=20 >>>> 1) [RFC2501] for MANETs. (published in 1999) >>>> 2) [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] for LLNs. >>>> (published in 2009) >>>=20 >>> I think they are good references to build some arguments into this >>> discussion. >>>=20 >>>>=20 >>>> Low power was indicated in RFC2501 in section 5.1 as >>> constraints> and also the word *sink*, in page 7 you read >>> for energy conservation>. IMHO, as long we have a ROLL WG in IETF we >>>> need to forward work to it which has no mobility behavior. Delegation >>>> will help make work flowing and more focused. >>>=20 >>> When you say "IMHO, as long we have a ROLL WG in IETF we need to forwar= d >>> work to it which has no mobility behavior", do you mean that the differ= ence >>> between ROLL and MANET is limited to mobility considerations ? >>>=20 >>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC58= 67 >>> all include the usual IoT constraints : Memory, Processing, Power, Batt= ery, >>> Cost and Size of device. >>> RFC5673 does not mention explicitly processing and size constraints, bu= t >>> mention all the others. >>>=20 >>> RFC 2501 speak about energy and power, as you previously mentioned, but= does >>> not say something on the following constraints : Memory, Processing, C= ost >>> and Size. >>>=20 >>> Do you think that these constraints are in the MANET scope ? >>> I guess that they may be (obviously for Cost), but not in the same orde= r of >>> magnitude as the type of devices described in the requirements RFC of R= OLL. >>>=20 >>> Regards, >>>=20 >>> C=E9dric. >>>=20 >>>>=20 >>>> Regards >>>> AB >>>> =3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> On 8/1/12, C Chauvenet wrote: >>>>> Hi, >>>>>=20 >>>>> This is an interesting discussion. >>>>>=20 >>>>> My understanding is that both MANET and ROLL considers lossy/dynamic >>>>> links >>>>> in the way described in the MANET charter : "static and dynamic >>>>> topologies >>>>> with increased dynamics due to node motion or other factors." I also >>>>> agree >>>>> that dynamicity of links is not hard wired to node mobility. >>>>>=20 >>>>> So, in the LLN Vs MANET debate, I think they share the "N" for Networ= ks, >>>>> and >>>>> the 2nd "L" for Lossy. >>>>> So the remaining point is the first L, meaning Low Power. >>>>>=20 >>>>> Low Power requirements is explicit in the ROLL charter and not mentio= ned >>>>> at >>>>> all in the MANET charter. >>>>> Is the power efficiency consideration the big difference between ROLL >>>>> and >>>>> MANET ? >>>>>=20 >>>>> C=E9dric. >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part = de >>>>> Abdussalam Baryun >>>>> Envoy=E9 : mercredi 1 ao=FBt 2012 09:22 >>>>> =C0 : Henning Rogge >>>>> Cc : roll; manet >>>>> Objet : [Roll] Some LLNs are NOT MANETs >>>>>=20 >>>>> Hi Henning, >>>>>=20 >>>>> I am about to say many LLNs are NOT MANETs but it seems like the mark= et >>>>> or >>>>> community will decide the outcome, but surly that some LLNs are NOT >>>>> MANETs. >>>>>=20 >>>>>> Could you state an example what would be considered a LLN but not a >>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>=20 >>>>> I not totally agree with that, because we need to be considering both >>>>> NETs >>>>> use case and applicability in the vision of the different WGs (MANET = and >>>>> ROLL). There are many examples we can find them in the [RFC2501] for >>>>> MANETs >>>>> characteristics and applicability, and for LLNs characteristics in >>>>> [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs >>>>> requirements. That is why I suggested before that >>>>> OLSRv2 and AODVv2 should mention their applicability to LLN if they d= o. >>>>> They >>>>> just refer to RFC2501, but RFC2501 is OLD and does not mention LLN bu= t >>>>> describes the meaning. The authors of RFC2501 still not responded to = my >>>>> update suggestions. >>>>>=20 >>>>> I understood from one discussion in MANET WG that few don't have time= to >>>>> read many pages of documents, so that is why I suggested to have >>>>> terminology >>>>> I-D [1] as we have ROLL terminology [ROLL] . I also taken initiative = to >>>>> make >>>>> new draft of MANET subnet technologies which include only related LL= Ns >>>>> [AB2]. >>>>>=20 >>>>> Therefore, I will add the definition for MANET and LLN into my >>>>> manet-terminology draft [AB1] (propose that authors of [ROLL] define = LLN >>>>> more details) to assist discussions as it is proved now in the list t= hat >>>>> there still is problems in definitions in MANET WG or in some I-D >>>>> editorial >>>>> content. >>>>>=20 >>>>> [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >>>>> [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >>>>> [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt >>>>>=20 >>>>> Best Wishes >>>>>=20 >>>>> Abdussalam Baryun >>>>> University of Glamorgan, UK >>>>>=20 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>>> On 7/31/12, Henning Rogge wrote: >>>>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>>>>> subject: Re: [manet] Discussing LOADng suggestions >>>>>> wrote: >>>>>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, bu= t >>>>>>> then changed its direction to MANET [3]. However, please note that >>>>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >>>>>>> said, LOADng SHOULD specfy where is its limits. Then we can discuss >>>>>>> adoption. >>>>>>=20 >>>>>> Could you state an example what would be considered a LLN but not a >>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>>=20 >>>>>> Henning Rogge >>>>>>=20 >>>>>> -- >>>>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>>>> billions of percent in a tiny fraction of a second. Of course, that >>>>>> was before the present government." >>>>>>=20 >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 From abdussalambaryun@gmail.com Thu Aug 2 09:24:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FD621E803D for ; Thu, 2 Aug 2012 09:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.184 X-Spam-Level: X-Spam-Status: No, score=-3.184 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UC2Ph6tsWwG for ; Thu, 2 Aug 2012 09:24:02 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 82C6211E808E for ; Thu, 2 Aug 2012 09:24:02 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so9095098vcb.31 for ; Thu, 02 Aug 2012 09:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5WBb9asYX20acKRIX9LFq2S706O5OlgiFzbYQSnlDvk=; b=J2qhYfZfdiY3OqLKXZ39XToexaTu4n1jZmw3Gna4N0KXhzOmId5+B5rYyyZTekT4U1 LCONIvWIps+RVbPJNkg+tN0g6urlTfvkMwnSqAQMuXnhfs8Glj4UeeHzak0ezYVZnj4j XS1WfQJvzBgpkb2nlylIMovq+P1arfIqTrb9i6TdOGCH/t+vSwKxZ9lNCDzSNJTspuw2 vy+Op0iU8MvH9nBJ75sskoTf+KWnVNOPW7Huo2pjdSwu4Aj5PsTWNQAKciOLtvJVr5PX SbKRZeULwEyjh21n+jLjDPK7nk6I4tadAfwAw8QJa/Q/Zj+WR9EYNoMR8m2+ReFP21VJ sbCw== MIME-Version: 1.0 Received: by 10.52.32.67 with SMTP id g3mr764607vdi.129.1343924641867; Thu, 02 Aug 2012 09:24:01 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Thu, 2 Aug 2012 09:24:01 -0700 (PDT) In-Reply-To: <8BA2751C-A4A5-46E8-9027-22A94045C3FE@cisco.com> References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> <8BA2751C-A4A5-46E8-9027-22A94045C3FE@cisco.com> Date: Thu, 2 Aug 2012 18:24:01 +0200 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: manet Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:24:04 -0000 Hi Stan, We don't argue because we like it, but because we want to solve misunderstanding, if LOADng mentions LLNs without MANET, and some started to argue in meetings about that. LOAD is a protocol for LLN and MANET. > On another note, and more to the list at-large (instead of just replying = to > Chris), we can argue this for days, or even weeks. But the truth of the > matter is that our charter references MANET networks, while the charter f= or > ROLL references LLN's. It's pretty much just that simple. To be more simple the Routing Area Charters should have clear definitions (so if MANET includes all LLNs so just mention that, if it doesn't then it may not include all), on the other hand our I-Ds and RFCs should specify applicability, no protocol can solve ALL problems of MANET, that is why we have reactive and proactive, but still if you read RFC3626, RFC3561, OLSRv2, AODVv2, they don't mention the different where reactive or proactive is better nor do they specify where their performance change is the large MANET scenarios. We have to go out of IETF publications and read IEEE publication to understand "Applicability", am I missing some thing, I agree that the argument may take weeks, not because people like it, but simply because RFC2501 is not updated to include LLNs and other issues, AB =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 8/2/12, Stan Ratliff (sratliff) wrote: > Chris, > > On Aug 2, 2012, at 5:12 AM, Dearlove, Christopher (UK) wrote: > >> I would subtly differently emphasise your point. (I think we are basical= ly >> in agreement.) I would view ad hoc networks (I'm going to avoid the MANE= T >> term as it's overloaded here) as a broad area. LLNs are a specialist >> sub-area within that area. The MANET WG in principle covers the whole of >> the area, and most of its work has created protocols that can cover most >> of that area. However where there are specialised, and in particular mor= e >> limited requirement, sub-areas, specialised protocols may make a better >> trade-off (typically be simpler). And you have emphasised one of the key >> differences, the differing traffic pattern, and in particular the domina= nt >> role of an egress (or ingress, but egress is often more important) >> gateway rather than peer to peer communications (which in an LLN are >> typically either absent, or rare enough that the otherwise inefficient g= o >> via gateway, possibly optimised to clip off reused links, is acceptable)= . >> >> (This bit may or may not be in agreement with Stan.) Note that I'm not >> saying that you can't use e.g. OLSRv2 in an LLN, but that if you have mo= re >> limited/specialised requirements you may be able to do better. Nor am I >> saying RPL or LOADng is (or is not) that better solution, I've studied >> neither in enough detail to have a view. >> > > No, we agree=85 As a mentor of mine once said, "You can do anything you'r= e big > enough to try"=85 ;-) ;-) The definitions we're using (MANET and LLN) are > somewhat vague, and somewhat overlapping. And any specific network's > environment could well lead to multiple choices for a routing protocol. > > On another note, and more to the list at-large (instead of just replying = to > Chris), we can argue this for days, or even weeks. But the truth of the > matter is that our charter references MANET networks, while the charter f= or > ROLL references LLN's. It's pretty much just that simple. > > Regards, > Stan > > >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, >> Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] >> Sent: 01 August 2012 17:23 >> To: Dearlove, Christopher (UK) >> Cc: Abdussalam Baryun; C Chauvenet; manet >> Subject: Re: [manet] Some LLNs are NOT MANETs >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> Precisely, Chris. >> >> I've come to view MANETs more and more in the terms of an "opportunistic >> network". By that, I mean a network with a fairly large amount of >> dynamism, and also a network that contains heterogeneity of links (e.g., >> different radio types, and/or some wired portions). The challenge of the= se >> networks is to opportunistically (and maximally) use the resources >> available to it at any point in time. >> >> And at least for me (and I know this will draw some fire in return), >> another distinction in MANET as opposed to LLN is a greater requirement >> for peer-to-peer (node-to-node) communication, From what I've seen of LL= N >> deployments (and I'm no expert), they tend to have more of a "multiple >> source/single sink" model for the data flow. >> >> Again, just one opinion. >> >> Regards, >> Stan >> >> On Aug 1, 2012, at 11:26 AM, Dearlove, Christopher (UK) wrote: >> >>> The statement that MANETs refers only to networks with physical mobilit= y >>> is simply false. While the expansion of the acronym might suggest that, >>> in fact MANET has become a term of art, and that art includes many >>> networks with some or all nodes that are not physically moving. >>> >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>> Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>> >>> >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of >>> Abdussalam Baryun >>> Sent: 01 August 2012 14:21 >>> To: C Chauvenet >>> Cc: manet >>> Subject: Re: [manet] Some LLNs are NOT MANETs >>> >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>> >>> Hi C=E9dric, >>> >>> Ok we can discuss efficiently when we read the documents (production >>> of such WG)as you agreed. >>> >>>> When you say "IMHO, as long we have a ROLL WG in IETF we need to >>>> forward >>>> work to it which has no mobility behavior", do you mean that the >>>> difference >>>> between ROLL and MANET is limited to mobility considerations ? >>> >>> *Mobility* It is the mostly difference clearly spoted between the >>> documents produced by the both WGs, also the name MANET starts with >>> Mobile, the word mobile is not equal to change/dynamic. So MANET >>> refers to mobile node or mobile network, which means location change >>> *NOT* topology change/dynamic. In the old days there was no ROLL WG so >>> MANET WG was doing the job. >>> >>>> >>>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and >>>> RFC5867 >>>> all include the usual IoT constraints : Memory, Processing, Power, >>>> Battery, >>>> Cost and Size of device. >>>> RFC5673 does not mention explicitly processing and size constraints, >>>> but >>>> mention all the others. >>>> >>> >>> Ok, >>> >>>> RFC 2501 speak about energy and power, as you previously mentioned, bu= t >>>> does >>>> not say something on the following constraints : Memory, Processing, >>>> Cost >>>> and Size. >>> >>> Yes your right, but be careful RFC2501 does not exclude thoes >>> constraints either. However, if the MANET network has some nodes with >>> constraints but clearly mobility is the main constraint. >>> >>>> >>>> Do you think that these constraints are in the MANET scope ? >>>> I guess that they may be (obviously for Cost), but not in the same ord= er >>>> of >>>> magnitude as the type of devices described in the requirements RFC of >>>> ROLL. >>> >>> Really don't mind either way for MANET WG, and will think that the WG >>> community wants it in between In-Scope and Out-Scope, that may be >>> strange but seems that is what is happening as I read documents. Out >>> of IETF, MANET is mostly understood as mobile nodes connecting, not >>> LLNs. >>> >>> Overall, IMHO, in the end it is the decision of the IETF community to >>> decide of any new idea or any I-D acceptance/adoption, but for the WG >>> it MAY take over a WORK as an IETF I-D, but it may not be successful >>> to convince the IETF community to continue the work or make it become >>> a RFC, we always have to see through to make the work efforts flow >>> successfully. We do not forget that many participants work in both >>> WGs. >>> >>> Regards >>> Abdussalam >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> On 8/1/12, C Chauvenet wrote: >>>> Hi, >>>> >>>> Thank you for your answer, >>>> >>>> See inline. >>>> >>>> Le 1 ao=FBt 2012 =E0 13:41, Abdussalam Baryun a =E9crit : >>>> >>>>> Hi C=E9dric, >>>>> >>>>> I think the RFC2501 is more important than the WG charter, because th= e >>>>> charter MAY change but RFCs never changes (only can be updated, >>>>> obsoleted or replaced). >>>> >>>> Good Point, 100% agree. >>>> >>>>> So far now all MANET-protocols are refering to >>>>> RFC2501 which is good and SHOULD continue, and I like this referencin= g >>>>> to documents (even if they are old or expired) not referencing to >>>>> charters, because for example, if in a journal paper we reference to >>>>> the charter of MANET WG or ROLL WG the information is not solid like >>>>> if you reference a published document (publisher date), but still we >>>>> can reference the charter as web reference sited date. >>>>> >>>>> I read some paper that reference sited web documents but they may be >>>>> not valid and cannot be read for some reason. Therefore, IMHO, we nee= d >>>>> to stick to the following document to make a right decision in >>>>> definitions: >>>>> >>>>> 1) [RFC2501] for MANETs. (published in 1999) >>>>> 2) [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] for LLNs. >>>>> (published in 2009) >>>> >>>> I think they are good references to build some arguments into this >>>> discussion. >>>> >>>>> >>>>> Low power was indicated in RFC2501 in section 5.1 as >>>> constraints> and also the word *sink*, in page 7 you read >>>> for energy conservation>. IMHO, as long we have a ROLL WG in IETF we >>>>> need to forward work to it which has no mobility behavior. Delegation >>>>> will help make work flowing and more focused. >>>> >>>> When you say "IMHO, as long we have a ROLL WG in IETF we need to >>>> forward >>>> work to it which has no mobility behavior", do you mean that the >>>> difference >>>> between ROLL and MANET is limited to mobility considerations ? >>>> >>>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and >>>> RFC5867 >>>> all include the usual IoT constraints : Memory, Processing, Power, >>>> Battery, >>>> Cost and Size of device. >>>> RFC5673 does not mention explicitly processing and size constraints, >>>> but >>>> mention all the others. >>>> >>>> RFC 2501 speak about energy and power, as you previously mentioned, bu= t >>>> does >>>> not say something on the following constraints : Memory, Processing, >>>> Cost >>>> and Size. >>>> >>>> Do you think that these constraints are in the MANET scope ? >>>> I guess that they may be (obviously for Cost), but not in the same ord= er >>>> of >>>> magnitude as the type of devices described in the requirements RFC of >>>> ROLL. >>>> >>>> Regards, >>>> >>>> C=E9dric. >>>> >>>>> >>>>> Regards >>>>> AB >>>>> =3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> On 8/1/12, C Chauvenet wrote: >>>>>> Hi, >>>>>> >>>>>> This is an interesting discussion. >>>>>> >>>>>> My understanding is that both MANET and ROLL considers lossy/dynamic >>>>>> links >>>>>> in the way described in the MANET charter : "static and dynamic >>>>>> topologies >>>>>> with increased dynamics due to node motion or other factors." I also >>>>>> agree >>>>>> that dynamicity of links is not hard wired to node mobility. >>>>>> >>>>>> So, in the LLN Vs MANET debate, I think they share the "N" for >>>>>> Networks, >>>>>> and >>>>>> the 2nd "L" for Lossy. >>>>>> So the remaining point is the first L, meaning Low Power. >>>>>> >>>>>> Low Power requirements is explicit in the ROLL charter and not >>>>>> mentioned >>>>>> at >>>>>> all in the MANET charter. >>>>>> Is the power efficiency consideration the big difference between ROL= L >>>>>> and >>>>>> MANET ? >>>>>> >>>>>> C=E9dric. >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part >>>>>> de >>>>>> Abdussalam Baryun >>>>>> Envoy=E9 : mercredi 1 ao=FBt 2012 09:22 >>>>>> =C0 : Henning Rogge >>>>>> Cc : roll; manet >>>>>> Objet : [Roll] Some LLNs are NOT MANETs >>>>>> >>>>>> Hi Henning, >>>>>> >>>>>> I am about to say many LLNs are NOT MANETs but it seems like the >>>>>> market >>>>>> or >>>>>> community will decide the outcome, but surly that some LLNs are NOT >>>>>> MANETs. >>>>>> >>>>>>> Could you state an example what would be considered a LLN but not a >>>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>> >>>>>> I not totally agree with that, because we need to be considering bot= h >>>>>> NETs >>>>>> use case and applicability in the vision of the different WGs (MANET >>>>>> and >>>>>> ROLL). There are many examples we can find them in the [RFC2501] for >>>>>> MANETs >>>>>> characteristics and applicability, and for LLNs characteristics in >>>>>> [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs >>>>>> requirements. That is why I suggested before that >>>>>> OLSRv2 and AODVv2 should mention their applicability to LLN if they >>>>>> do. >>>>>> They >>>>>> just refer to RFC2501, but RFC2501 is OLD and does not mention LLN >>>>>> but >>>>>> describes the meaning. The authors of RFC2501 still not responded to >>>>>> my >>>>>> update suggestions. >>>>>> >>>>>> I understood from one discussion in MANET WG that few don't have tim= e >>>>>> to >>>>>> read many pages of documents, so that is why I suggested to have >>>>>> terminology >>>>>> I-D [1] as we have ROLL terminology [ROLL] . I also taken initiative >>>>>> to >>>>>> make >>>>>> new draft of MANET subnet technologies which include only related >>>>>> LLNs >>>>>> [AB2]. >>>>>> >>>>>> Therefore, I will add the definition for MANET and LLN into my >>>>>> manet-terminology draft [AB1] (propose that authors of [ROLL] define >>>>>> LLN >>>>>> more details) to assist discussions as it is proved now in the list >>>>>> that >>>>>> there still is problems in definitions in MANET WG or in some I-D >>>>>> editorial >>>>>> content. >>>>>> >>>>>> [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >>>>>> [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >>>>>> [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt >>>>>> >>>>>> Best Wishes >>>>>> >>>>>> Abdussalam Baryun >>>>>> University of Glamorgan, UK >>>>>> >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>> On 7/31/12, Henning Rogge wrote: >>>>>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>>>>>> subject: Re: [manet] Discussing LOADng suggestions >>>>>>> wrote: >>>>>>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, >>>>>>>> but >>>>>>>> then changed its direction to MANET [3]. However, please note that >>>>>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >>>>>>>> said, LOADng SHOULD specfy where is its limits. Then we can discus= s >>>>>>>> adoption. >>>>>>> >>>>>>> Could you state an example what would be considered a LLN but not a >>>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>>> >>>>>>> Henning Rogge >>>>>>> >>>>>>> -- >>>>>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>>>>> billions of percent in a tiny fraction of a second. Of course, that >>>>>>> was before the present government." >>>>>>> >>>>>> _______________________________________________ >>>>>> Roll mailing list >>>>>> Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ******************************************************************** >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> > > From Chris.Dearlove@baesystems.com Thu Aug 2 09:29:27 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4673911E80F0 for ; Thu, 2 Aug 2012 09:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.986 X-Spam-Level: X-Spam-Status: No, score=-9.986 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKWB-Nk1SWwC for ; Thu, 2 Aug 2012 09:29:25 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA0011E80EF for ; Thu, 2 Aug 2012 09:29:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,702,1336345200"; d="scan'208";a="260934011" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 02 Aug 2012 17:29:23 +0100 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q72GTMnp013881 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 17:29:23 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.170]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Thu, 2 Aug 2012 17:29:22 +0100 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" Thread-Topic: [manet] Some LLNs are NOT MANETs Thread-Index: AQHNb+izbH1tyYFgl06MELNnv/B9tZdFE3cg////qYCAASeJoIAAYtQAgAAYV3A= Date: Thu, 2 Aug 2012 16:29:22 +0000 Message-ID: References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> <8BA2751C-A4A5-46E8-9027-22A94045C3FE@cisco.com> In-Reply-To: <8BA2751C-A4A5-46E8-9027-22A94045C3FE@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:29:27 -0000 Taking your last point on what charters say, I would interpret that as: - A solution just intended for LLNs, or which that is the dominant case for= , belongs to ROLL (unless they don't want it). - A wide ranging solution (which could include LLNs as a special case) belo= ngs in MANET. - A specialist solution that is not an LLN specialist solution is permissib= le in MANET, though a specialised WG could be created for it. But all subject to the overriding condition there has to be a reason to do = it, not just a protocol with no user base looking for a home. And of course= I'm just talking about ad hoc routing protocols (by which I mean, roughly = speaking, decentralised multi-hop routing in dynamic or otherwise unknown c= haracteristic networks) or closely related things here. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: 02 August 2012 16:54 To: Dearlove, Christopher (UK) Cc: Abdussalam Baryun; C Chauvenet; manet Subject: Re: [manet] Some LLNs are NOT MANETs ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Chris,=20 On Aug 2, 2012, at 5:12 AM, Dearlove, Christopher (UK) wrote: > I would subtly differently emphasise your point. (I think we are basicall= y in agreement.) I would view ad hoc networks (I'm going to avoid the MANET= term as it's overloaded here) as a broad area. LLNs are a specialist sub-a= rea within that area. The MANET WG in principle covers the whole of the are= a, and most of its work has created protocols that can cover most of that a= rea. However where there are specialised, and in particular more limited re= quirement, sub-areas, specialised protocols may make a better trade-off (ty= pically be simpler). And you have emphasised one of the key differences, th= e differing traffic pattern, and in particular the dominant role of an egre= ss (or ingress, but egress is often more important) gateway rather than pe= er to peer communications (which in an LLN are typically either absent, or = rare enough that the otherwise inefficient go via gateway, possibly optimis= ed to clip off reused links, is acceptable). >=20 > (This bit may or may not be in agreement with Stan.) Note that I'm not sa= ying that you can't use e.g. OLSRv2 in an LLN, but that if you have more li= mited/specialised requirements you may be able to do better. Nor am I sayin= g RPL or LOADng is (or is not) that better solution, I've studied neither i= n enough detail to have a view. >=20 No, we agree. As a mentor of mine once said, "You can do anything you're bi= g enough to try". ;-) ;-) The definitions we're using (MANET and LLN) are s= omewhat vague, and somewhat overlapping. And any specific network's environ= ment could well lead to multiple choices for a routing protocol.=20 On another note, and more to the list at-large (instead of just replying to= Chris), we can argue this for days, or even weeks. But the truth of the ma= tter is that our charter references MANET networks, while the charter for R= OLL references LLN's. It's pretty much just that simple.=20 Regards, Stan > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 > Sent: 01 August 2012 17:23 > To: Dearlove, Christopher (UK) > Cc: Abdussalam Baryun; C Chauvenet; manet > Subject: Re: [manet] Some LLNs are NOT MANETs >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Precisely, Chris.=20 >=20 > I've come to view MANETs more and more in the terms of an "opportunistic = network". By that, I mean a network with a fairly large amount of dynamism,= and also a network that contains heterogeneity of links (e.g., different r= adio types, and/or some wired portions). The challenge of these networks is= to opportunistically (and maximally) use the resources available to it at = any point in time.=20 >=20 > And at least for me (and I know this will draw some fire in return), anot= her distinction in MANET as opposed to LLN is a greater requirement for pee= r-to-peer (node-to-node) communication, From what I've seen of LLN deployme= nts (and I'm no expert), they tend to have more of a "multiple source/singl= e sink" model for the data flow. >=20 > Again, just one opinion.=20 >=20 > Regards, > Stan >=20 > On Aug 1, 2012, at 11:26 AM, Dearlove, Christopher (UK) wrote: >=20 >> The statement that MANETs refers only to networks with physical mobility= is simply false. While the expansion of the acronym might suggest that, in= fact MANET has become a term of art, and that art includes many networks w= ith some or all nodes that are not physically moving. >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f Abdussalam Baryun >> Sent: 01 August 2012 14:21 >> To: C Chauvenet >> Cc: manet >> Subject: Re: [manet] Some LLNs are NOT MANETs >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> Hi C=E9dric, >>=20 >> Ok we can discuss efficiently when we read the documents (production >> of such WG)as you agreed. >>=20 >>> When you say "IMHO, as long we have a ROLL WG in IETF we need to forwar= d >>> work to it which has no mobility behavior", do you mean that the differ= ence >>> between ROLL and MANET is limited to mobility considerations ? >>=20 >> *Mobility* It is the mostly difference clearly spoted between the >> documents produced by the both WGs, also the name MANET starts with >> Mobile, the word mobile is not equal to change/dynamic. So MANET >> refers to mobile node or mobile network, which means location change >> *NOT* topology change/dynamic. In the old days there was no ROLL WG so >> MANET WG was doing the job. >>=20 >>>=20 >>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC58= 67 >>> all include the usual IoT constraints : Memory, Processing, Power, Batt= ery, >>> Cost and Size of device. >>> RFC5673 does not mention explicitly processing and size constraints, bu= t >>> mention all the others. >>>=20 >>=20 >> Ok, >>=20 >>> RFC 2501 speak about energy and power, as you previously mentioned, but= does >>> not say something on the following constraints : Memory, Processing, C= ost >>> and Size. >>=20 >> Yes your right, but be careful RFC2501 does not exclude thoes >> constraints either. However, if the MANET network has some nodes with >> constraints but clearly mobility is the main constraint. >>=20 >>>=20 >>> Do you think that these constraints are in the MANET scope ? >>> I guess that they may be (obviously for Cost), but not in the same orde= r of >>> magnitude as the type of devices described in the requirements RFC of R= OLL. >>=20 >> Really don't mind either way for MANET WG, and will think that the WG >> community wants it in between In-Scope and Out-Scope, that may be >> strange but seems that is what is happening as I read documents. Out >> of IETF, MANET is mostly understood as mobile nodes connecting, not >> LLNs. >>=20 >> Overall, IMHO, in the end it is the decision of the IETF community to >> decide of any new idea or any I-D acceptance/adoption, but for the WG >> it MAY take over a WORK as an IETF I-D, but it may not be successful >> to convince the IETF community to continue the work or make it become >> a RFC, we always have to see through to make the work efforts flow >> successfully. We do not forget that many participants work in both >> WGs. >>=20 >> Regards >> Abdussalam >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> On 8/1/12, C Chauvenet wrote: >>> Hi, >>>=20 >>> Thank you for your answer, >>>=20 >>> See inline. >>>=20 >>> Le 1 ao=FBt 2012 =E0 13:41, Abdussalam Baryun a =E9crit : >>>=20 >>>> Hi C=E9dric, >>>>=20 >>>> I think the RFC2501 is more important than the WG charter, because the >>>> charter MAY change but RFCs never changes (only can be updated, >>>> obsoleted or replaced). >>>=20 >>> Good Point, 100% agree. >>>=20 >>>> So far now all MANET-protocols are refering to >>>> RFC2501 which is good and SHOULD continue, and I like this referencing >>>> to documents (even if they are old or expired) not referencing to >>>> charters, because for example, if in a journal paper we reference to >>>> the charter of MANET WG or ROLL WG the information is not solid like >>>> if you reference a published document (publisher date), but still we >>>> can reference the charter as web reference sited date. >>>>=20 >>>> I read some paper that reference sited web documents but they may be >>>> not valid and cannot be read for some reason. Therefore, IMHO, we need >>>> to stick to the following document to make a right decision in >>>> definitions: >>>>=20 >>>> 1) [RFC2501] for MANETs. (published in 1999) >>>> 2) [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] for LLNs. >>>> (published in 2009) >>>=20 >>> I think they are good references to build some arguments into this >>> discussion. >>>=20 >>>>=20 >>>> Low power was indicated in RFC2501 in section 5.1 as >>> constraints> and also the word *sink*, in page 7 you read >>> for energy conservation>. IMHO, as long we have a ROLL WG in IETF we >>>> need to forward work to it which has no mobility behavior. Delegation >>>> will help make work flowing and more focused. >>>=20 >>> When you say "IMHO, as long we have a ROLL WG in IETF we need to forwar= d >>> work to it which has no mobility behavior", do you mean that the differ= ence >>> between ROLL and MANET is limited to mobility considerations ? >>>=20 >>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC58= 67 >>> all include the usual IoT constraints : Memory, Processing, Power, Batt= ery, >>> Cost and Size of device. >>> RFC5673 does not mention explicitly processing and size constraints, bu= t >>> mention all the others. >>>=20 >>> RFC 2501 speak about energy and power, as you previously mentioned, but= does >>> not say something on the following constraints : Memory, Processing, C= ost >>> and Size. >>>=20 >>> Do you think that these constraints are in the MANET scope ? >>> I guess that they may be (obviously for Cost), but not in the same orde= r of >>> magnitude as the type of devices described in the requirements RFC of R= OLL. >>>=20 >>> Regards, >>>=20 >>> C=E9dric. >>>=20 >>>>=20 >>>> Regards >>>> AB >>>> =3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> On 8/1/12, C Chauvenet wrote: >>>>> Hi, >>>>>=20 >>>>> This is an interesting discussion. >>>>>=20 >>>>> My understanding is that both MANET and ROLL considers lossy/dynamic >>>>> links >>>>> in the way described in the MANET charter : "static and dynamic >>>>> topologies >>>>> with increased dynamics due to node motion or other factors." I also >>>>> agree >>>>> that dynamicity of links is not hard wired to node mobility. >>>>>=20 >>>>> So, in the LLN Vs MANET debate, I think they share the "N" for Networ= ks, >>>>> and >>>>> the 2nd "L" for Lossy. >>>>> So the remaining point is the first L, meaning Low Power. >>>>>=20 >>>>> Low Power requirements is explicit in the ROLL charter and not mentio= ned >>>>> at >>>>> all in the MANET charter. >>>>> Is the power efficiency consideration the big difference between ROLL >>>>> and >>>>> MANET ? >>>>>=20 >>>>> C=E9dric. >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part = de >>>>> Abdussalam Baryun >>>>> Envoy=E9 : mercredi 1 ao=FBt 2012 09:22 >>>>> =C0 : Henning Rogge >>>>> Cc : roll; manet >>>>> Objet : [Roll] Some LLNs are NOT MANETs >>>>>=20 >>>>> Hi Henning, >>>>>=20 >>>>> I am about to say many LLNs are NOT MANETs but it seems like the mark= et >>>>> or >>>>> community will decide the outcome, but surly that some LLNs are NOT >>>>> MANETs. >>>>>=20 >>>>>> Could you state an example what would be considered a LLN but not a >>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>=20 >>>>> I not totally agree with that, because we need to be considering both >>>>> NETs >>>>> use case and applicability in the vision of the different WGs (MANET = and >>>>> ROLL). There are many examples we can find them in the [RFC2501] for >>>>> MANETs >>>>> characteristics and applicability, and for LLNs characteristics in >>>>> [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs >>>>> requirements. That is why I suggested before that >>>>> OLSRv2 and AODVv2 should mention their applicability to LLN if they d= o. >>>>> They >>>>> just refer to RFC2501, but RFC2501 is OLD and does not mention LLN bu= t >>>>> describes the meaning. The authors of RFC2501 still not responded to = my >>>>> update suggestions. >>>>>=20 >>>>> I understood from one discussion in MANET WG that few don't have time= to >>>>> read many pages of documents, so that is why I suggested to have >>>>> terminology >>>>> I-D [1] as we have ROLL terminology [ROLL] . I also taken initiative = to >>>>> make >>>>> new draft of MANET subnet technologies which include only related LL= Ns >>>>> [AB2]. >>>>>=20 >>>>> Therefore, I will add the definition for MANET and LLN into my >>>>> manet-terminology draft [AB1] (propose that authors of [ROLL] define = LLN >>>>> more details) to assist discussions as it is proved now in the list t= hat >>>>> there still is problems in definitions in MANET WG or in some I-D >>>>> editorial >>>>> content. >>>>>=20 >>>>> [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >>>>> [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >>>>> [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt >>>>>=20 >>>>> Best Wishes >>>>>=20 >>>>> Abdussalam Baryun >>>>> University of Glamorgan, UK >>>>>=20 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>>> On 7/31/12, Henning Rogge wrote: >>>>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>>>>> subject: Re: [manet] Discussing LOADng suggestions >>>>>> wrote: >>>>>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, bu= t >>>>>>> then changed its direction to MANET [3]. However, please note that >>>>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >>>>>>> said, LOADng SHOULD specfy where is its limits. Then we can discuss >>>>>>> adoption. >>>>>>=20 >>>>>> Could you state an example what would be considered a LLN but not a >>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>>=20 >>>>>> Henning Rogge >>>>>>=20 >>>>>> -- >>>>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>>>> billions of percent in a tiny fraction of a second. Of course, that >>>>>> was before the present government." >>>>>>=20 >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 From Chris.Dearlove@baesystems.com Thu Aug 2 09:41:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4489411E812D for ; Thu, 2 Aug 2012 09:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.987 X-Spam-Level: X-Spam-Status: No, score=-9.987 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI6-GAjMv3o7 for ; Thu, 2 Aug 2012 09:41:11 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC8D21F8516 for ; Thu, 2 Aug 2012 09:41:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,702,1336345200"; d="scan'208";a="260936444" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 02 Aug 2012 17:41:09 +0100 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q72Gf9UM020466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 17:41:09 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.170]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Thu, 2 Aug 2012 17:41:09 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , "Stan Ratliff (sratliff)" Thread-Topic: [manet] Some LLNs are NOT MANETs Thread-Index: AQHNb+izbH1tyYFgl06MELNnv/B9tZdFE3cg////qYCAASeJoIAAYtQAgAAIYYCAABLJgA== Date: Thu, 2 Aug 2012 16:41:08 +0000 Message-ID: References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> <8BA2751C-A4A5-46E8-9027-22A94045C3FE@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:41:13 -0000 I'm just going to comment that the authors of the OLSRv2-related set of spe= cifications would love to have the time (and funding) to sit down and write= various pieces of rationale for why things are as they are, and how to use= them, including some less obvious options that are there but may not be ob= vious. Given that absence, the best that's possible is that things come out= in pieces. There's the narrowly focussed metrics rationale. There's a pape= r I wrote for a NATO conference on what's new in OLSRv2 and why, and I'm su= re Thomas and Ulrich (and some others) can point to various papers (and a t= hesis) they have written that may also provide pieces. Give us a (paid) yea= r off each and we could even write a book. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= bdussalam Baryun Sent: 02 August 2012 17:24 To: Stan Ratliff (sratliff) Cc: manet Subject: Re: [manet] Some LLNs are NOT MANETs ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Stan, We don't argue because we like it, but because we want to solve misunderstanding, if LOADng mentions LLNs without MANET, and some started to argue in meetings about that. LOAD is a protocol for LLN and MANET. > On another note, and more to the list at-large (instead of just replying = to > Chris), we can argue this for days, or even weeks. But the truth of the > matter is that our charter references MANET networks, while the charter f= or > ROLL references LLN's. It's pretty much just that simple. To be more simple the Routing Area Charters should have clear definitions (so if MANET includes all LLNs so just mention that, if it doesn't then it may not include all), on the other hand our I-Ds and RFCs should specify applicability, no protocol can solve ALL problems of MANET, that is why we have reactive and proactive, but still if you read RFC3626, RFC3561, OLSRv2, AODVv2, they don't mention the different where reactive or proactive is better nor do they specify where their performance change is the large MANET scenarios. We have to go out of IETF publications and read IEEE publication to understand "Applicability", am I missing some thing, I agree that the argument may take weeks, not because people like it, but simply because RFC2501 is not updated to include LLNs and other issues, AB =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 8/2/12, Stan Ratliff (sratliff) wrote: > Chris, > > On Aug 2, 2012, at 5:12 AM, Dearlove, Christopher (UK) wrote: > >> I would subtly differently emphasise your point. (I think we are basical= ly >> in agreement.) I would view ad hoc networks (I'm going to avoid the MANE= T >> term as it's overloaded here) as a broad area. LLNs are a specialist >> sub-area within that area. The MANET WG in principle covers the whole of >> the area, and most of its work has created protocols that can cover most >> of that area. However where there are specialised, and in particular mor= e >> limited requirement, sub-areas, specialised protocols may make a better >> trade-off (typically be simpler). And you have emphasised one of the key >> differences, the differing traffic pattern, and in particular the domina= nt >> role of an egress (or ingress, but egress is often more important) >> gateway rather than peer to peer communications (which in an LLN are >> typically either absent, or rare enough that the otherwise inefficient g= o >> via gateway, possibly optimised to clip off reused links, is acceptable)= . >> >> (This bit may or may not be in agreement with Stan.) Note that I'm not >> saying that you can't use e.g. OLSRv2 in an LLN, but that if you have mo= re >> limited/specialised requirements you may be able to do better. Nor am I >> saying RPL or LOADng is (or is not) that better solution, I've studied >> neither in enough detail to have a view. >> > > No, we agree. As a mentor of mine once said, "You can do anything you're = big > enough to try". ;-) ;-) The definitions we're using (MANET and LLN) are > somewhat vague, and somewhat overlapping. And any specific network's > environment could well lead to multiple choices for a routing protocol. > > On another note, and more to the list at-large (instead of just replying = to > Chris), we can argue this for days, or even weeks. But the truth of the > matter is that our charter references MANET networks, while the charter f= or > ROLL references LLN's. It's pretty much just that simple. > > Regards, > Stan > > >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, >> Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] >> Sent: 01 August 2012 17:23 >> To: Dearlove, Christopher (UK) >> Cc: Abdussalam Baryun; C Chauvenet; manet >> Subject: Re: [manet] Some LLNs are NOT MANETs >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> Precisely, Chris. >> >> I've come to view MANETs more and more in the terms of an "opportunistic >> network". By that, I mean a network with a fairly large amount of >> dynamism, and also a network that contains heterogeneity of links (e.g., >> different radio types, and/or some wired portions). The challenge of the= se >> networks is to opportunistically (and maximally) use the resources >> available to it at any point in time. >> >> And at least for me (and I know this will draw some fire in return), >> another distinction in MANET as opposed to LLN is a greater requirement >> for peer-to-peer (node-to-node) communication, From what I've seen of LL= N >> deployments (and I'm no expert), they tend to have more of a "multiple >> source/single sink" model for the data flow. >> >> Again, just one opinion. >> >> Regards, >> Stan >> >> On Aug 1, 2012, at 11:26 AM, Dearlove, Christopher (UK) wrote: >> >>> The statement that MANETs refers only to networks with physical mobilit= y >>> is simply false. While the expansion of the acronym might suggest that, >>> in fact MANET has become a term of art, and that art includes many >>> networks with some or all nodes that are not physically moving. >>> >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>> Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>> >>> >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of >>> Abdussalam Baryun >>> Sent: 01 August 2012 14:21 >>> To: C Chauvenet >>> Cc: manet >>> Subject: Re: [manet] Some LLNs are NOT MANETs >>> >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>> >>> Hi C=E9dric, >>> >>> Ok we can discuss efficiently when we read the documents (production >>> of such WG)as you agreed. >>> >>>> When you say "IMHO, as long we have a ROLL WG in IETF we need to >>>> forward >>>> work to it which has no mobility behavior", do you mean that the >>>> difference >>>> between ROLL and MANET is limited to mobility considerations ? >>> >>> *Mobility* It is the mostly difference clearly spoted between the >>> documents produced by the both WGs, also the name MANET starts with >>> Mobile, the word mobile is not equal to change/dynamic. So MANET >>> refers to mobile node or mobile network, which means location change >>> *NOT* topology change/dynamic. In the old days there was no ROLL WG so >>> MANET WG was doing the job. >>> >>>> >>>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and >>>> RFC5867 >>>> all include the usual IoT constraints : Memory, Processing, Power, >>>> Battery, >>>> Cost and Size of device. >>>> RFC5673 does not mention explicitly processing and size constraints, >>>> but >>>> mention all the others. >>>> >>> >>> Ok, >>> >>>> RFC 2501 speak about energy and power, as you previously mentioned, bu= t >>>> does >>>> not say something on the following constraints : Memory, Processing, >>>> Cost >>>> and Size. >>> >>> Yes your right, but be careful RFC2501 does not exclude thoes >>> constraints either. However, if the MANET network has some nodes with >>> constraints but clearly mobility is the main constraint. >>> >>>> >>>> Do you think that these constraints are in the MANET scope ? >>>> I guess that they may be (obviously for Cost), but not in the same ord= er >>>> of >>>> magnitude as the type of devices described in the requirements RFC of >>>> ROLL. >>> >>> Really don't mind either way for MANET WG, and will think that the WG >>> community wants it in between In-Scope and Out-Scope, that may be >>> strange but seems that is what is happening as I read documents. Out >>> of IETF, MANET is mostly understood as mobile nodes connecting, not >>> LLNs. >>> >>> Overall, IMHO, in the end it is the decision of the IETF community to >>> decide of any new idea or any I-D acceptance/adoption, but for the WG >>> it MAY take over a WORK as an IETF I-D, but it may not be successful >>> to convince the IETF community to continue the work or make it become >>> a RFC, we always have to see through to make the work efforts flow >>> successfully. We do not forget that many participants work in both >>> WGs. >>> >>> Regards >>> Abdussalam >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> On 8/1/12, C Chauvenet wrote: >>>> Hi, >>>> >>>> Thank you for your answer, >>>> >>>> See inline. >>>> >>>> Le 1 ao=FBt 2012 =E0 13:41, Abdussalam Baryun a =E9crit : >>>> >>>>> Hi C=E9dric, >>>>> >>>>> I think the RFC2501 is more important than the WG charter, because th= e >>>>> charter MAY change but RFCs never changes (only can be updated, >>>>> obsoleted or replaced). >>>> >>>> Good Point, 100% agree. >>>> >>>>> So far now all MANET-protocols are refering to >>>>> RFC2501 which is good and SHOULD continue, and I like this referencin= g >>>>> to documents (even if they are old or expired) not referencing to >>>>> charters, because for example, if in a journal paper we reference to >>>>> the charter of MANET WG or ROLL WG the information is not solid like >>>>> if you reference a published document (publisher date), but still we >>>>> can reference the charter as web reference sited date. >>>>> >>>>> I read some paper that reference sited web documents but they may be >>>>> not valid and cannot be read for some reason. Therefore, IMHO, we nee= d >>>>> to stick to the following document to make a right decision in >>>>> definitions: >>>>> >>>>> 1) [RFC2501] for MANETs. (published in 1999) >>>>> 2) [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] for LLNs. >>>>> (published in 2009) >>>> >>>> I think they are good references to build some arguments into this >>>> discussion. >>>> >>>>> >>>>> Low power was indicated in RFC2501 in section 5.1 as >>>> constraints> and also the word *sink*, in page 7 you read >>>> for energy conservation>. IMHO, as long we have a ROLL WG in IETF we >>>>> need to forward work to it which has no mobility behavior. Delegation >>>>> will help make work flowing and more focused. >>>> >>>> When you say "IMHO, as long we have a ROLL WG in IETF we need to >>>> forward >>>> work to it which has no mobility behavior", do you mean that the >>>> difference >>>> between ROLL and MANET is limited to mobility considerations ? >>>> >>>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and >>>> RFC5867 >>>> all include the usual IoT constraints : Memory, Processing, Power, >>>> Battery, >>>> Cost and Size of device. >>>> RFC5673 does not mention explicitly processing and size constraints, >>>> but >>>> mention all the others. >>>> >>>> RFC 2501 speak about energy and power, as you previously mentioned, bu= t >>>> does >>>> not say something on the following constraints : Memory, Processing, >>>> Cost >>>> and Size. >>>> >>>> Do you think that these constraints are in the MANET scope ? >>>> I guess that they may be (obviously for Cost), but not in the same ord= er >>>> of >>>> magnitude as the type of devices described in the requirements RFC of >>>> ROLL. >>>> >>>> Regards, >>>> >>>> C=E9dric. >>>> >>>>> >>>>> Regards >>>>> AB >>>>> =3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> On 8/1/12, C Chauvenet wrote: >>>>>> Hi, >>>>>> >>>>>> This is an interesting discussion. >>>>>> >>>>>> My understanding is that both MANET and ROLL considers lossy/dynamic >>>>>> links >>>>>> in the way described in the MANET charter : "static and dynamic >>>>>> topologies >>>>>> with increased dynamics due to node motion or other factors." I also >>>>>> agree >>>>>> that dynamicity of links is not hard wired to node mobility. >>>>>> >>>>>> So, in the LLN Vs MANET debate, I think they share the "N" for >>>>>> Networks, >>>>>> and >>>>>> the 2nd "L" for Lossy. >>>>>> So the remaining point is the first L, meaning Low Power. >>>>>> >>>>>> Low Power requirements is explicit in the ROLL charter and not >>>>>> mentioned >>>>>> at >>>>>> all in the MANET charter. >>>>>> Is the power efficiency consideration the big difference between ROL= L >>>>>> and >>>>>> MANET ? >>>>>> >>>>>> C=E9dric. >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part >>>>>> de >>>>>> Abdussalam Baryun >>>>>> Envoy=E9 : mercredi 1 ao=FBt 2012 09:22 >>>>>> =C0 : Henning Rogge >>>>>> Cc : roll; manet >>>>>> Objet : [Roll] Some LLNs are NOT MANETs >>>>>> >>>>>> Hi Henning, >>>>>> >>>>>> I am about to say many LLNs are NOT MANETs but it seems like the >>>>>> market >>>>>> or >>>>>> community will decide the outcome, but surly that some LLNs are NOT >>>>>> MANETs. >>>>>> >>>>>>> Could you state an example what would be considered a LLN but not a >>>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>> >>>>>> I not totally agree with that, because we need to be considering bot= h >>>>>> NETs >>>>>> use case and applicability in the vision of the different WGs (MANET >>>>>> and >>>>>> ROLL). There are many examples we can find them in the [RFC2501] for >>>>>> MANETs >>>>>> characteristics and applicability, and for LLNs characteristics in >>>>>> [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs >>>>>> requirements. That is why I suggested before that >>>>>> OLSRv2 and AODVv2 should mention their applicability to LLN if they >>>>>> do. >>>>>> They >>>>>> just refer to RFC2501, but RFC2501 is OLD and does not mention LLN >>>>>> but >>>>>> describes the meaning. The authors of RFC2501 still not responded to >>>>>> my >>>>>> update suggestions. >>>>>> >>>>>> I understood from one discussion in MANET WG that few don't have tim= e >>>>>> to >>>>>> read many pages of documents, so that is why I suggested to have >>>>>> terminology >>>>>> I-D [1] as we have ROLL terminology [ROLL] . I also taken initiative >>>>>> to >>>>>> make >>>>>> new draft of MANET subnet technologies which include only related >>>>>> LLNs >>>>>> [AB2]. >>>>>> >>>>>> Therefore, I will add the definition for MANET and LLN into my >>>>>> manet-terminology draft [AB1] (propose that authors of [ROLL] define >>>>>> LLN >>>>>> more details) to assist discussions as it is proved now in the list >>>>>> that >>>>>> there still is problems in definitions in MANET WG or in some I-D >>>>>> editorial >>>>>> content. >>>>>> >>>>>> [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >>>>>> [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >>>>>> [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt >>>>>> >>>>>> Best Wishes >>>>>> >>>>>> Abdussalam Baryun >>>>>> University of Glamorgan, UK >>>>>> >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>> On 7/31/12, Henning Rogge wrote: >>>>>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>>>>>> subject: Re: [manet] Discussing LOADng suggestions >>>>>>> wrote: >>>>>>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, >>>>>>>> but >>>>>>>> then changed its direction to MANET [3]. However, please note that >>>>>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >>>>>>>> said, LOADng SHOULD specfy where is its limits. Then we can discus= s >>>>>>>> adoption. >>>>>>> >>>>>>> Could you state an example what would be considered a LLN but not a >>>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>>> >>>>>>> Henning Rogge >>>>>>> >>>>>>> -- >>>>>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>>>>> billions of percent in a tiny fraction of a second. Of course, that >>>>>>> was before the present government." >>>>>>> >>>>>> _______________________________________________ >>>>>> Roll mailing list >>>>>> Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ******************************************************************** >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> > > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Thu Aug 2 09:42:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CB911E813A for ; Thu, 2 Aug 2012 09:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGCG9BDQb7Dp for ; Thu, 2 Aug 2012 09:42:41 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 43DB311E8114 for ; Thu, 2 Aug 2012 09:42:31 -0700 (PDT) Received: from [130.129.17.186] by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SwyTA-000672-9e; Thu, 02 Aug 2012 12:41:52 -0400 Message-ID: <501AADB9.80102@computer.org> Date: Thu, 02 Aug 2012 09:41:29 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: manet References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> <8BA2751C-A4A5-46E8-9027-22A94045C3FE@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad867ebdc8455a890fe58e4cd158f8e05fa8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.17.186 Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:42:42 -0000 Hello folks, I was going to write with my opinion, but then I found that Chris had already stated my opinion. +1 Regards, Charlie P. On 8/2/2012 9:29 AM, Dearlove, Christopher (UK) wrote: > Taking your last point on what charters say, I would interpret that as: > - A solution just intended for LLNs, or which that is the dominant case for, belongs to ROLL (unless they don't want it). > - A wide ranging solution (which could include LLNs as a special case) belongs in MANET. > - A specialist solution that is not an LLN specialist solution is permissible in MANET, though a specialised WG could be created for it. > > But all subject to the overriding condition there has to be a reason to do it, not just a protocol with no user base looking for a home. And of course I'm just talking about ad hoc routing protocols (by which I mean, roughly speaking, decentralised multi-hop routing in dynamic or otherwise unknown characteristic networks) or closely related things here. > -- Regards, Charlie P. From ulrich@herberg.name Thu Aug 2 09:43:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99F011E8122 for ; Thu, 2 Aug 2012 09:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onQTiEBylnoD for ; Thu, 2 Aug 2012 09:43:52 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 008E921E804B for ; Thu, 2 Aug 2012 09:43:51 -0700 (PDT) Received: by ghbg16 with SMTP id g16so9622829ghb.31 for ; Thu, 02 Aug 2012 09:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=N6keGzm9igLHaMlDsX0phv5D49ITIbN+gibPelJa5HE=; b=Pn1cWgAaBLzzfg+Q17cFEnucVtRTvHvy/L2JWY00/dbfXFQGHUHEY4V0PxlkV8KwOA epiex4BE8FpfGPI4gf9X2v6QeqETeWUrSsi2BUYP4Oeon/2jDb+KZgqqNAq5Qxa7lbdB 96+HT1yK7K1TUfcwTg9l8koDkryH1UAp7Z3AU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=N6keGzm9igLHaMlDsX0phv5D49ITIbN+gibPelJa5HE=; b=epH4+grtcJUEdukmbDe9usEQrVS8P5oHohxy/tFHbIofqqJFprHHlEmfTkECV9fQWg boBL233QCde2eWDUFEgdymlBLF+k+PCeYD6vqSiKWbLEOOGqpLvcnLN2XYsi5qHOU54w nWozfLQDFlIxZ9A8B75S+OGBPapzEsJn1GXK+5YeRKY3KYQrxTT2P8Oj4eBzYcuq5dEm pNVA2y3dSsh+RMIPMqjtdS99recm2y9b0H+rmp526qPbOf2vw8OyJeHQIW2KvRjH92oj oCh5SRMr16XSt7jbztSqAH2ZXgwQzMk8AdDp1Hyo1Z2hEFiVc2JeGOTms/ndNx2dtt0T sb8Q== Received: by 10.50.100.199 with SMTP id fa7mr4555008igb.67.1343925828550; Thu, 02 Aug 2012 09:43:48 -0700 (PDT) Received: from ?IPv6:2001:df8::64:7403:6e75:959f:6c84? ([2001:df8:0:64:7403:6e75:959f:6c84]) by mx.google.com with ESMTPS id ud8sm14415445igb.4.2012.08.02.09.43.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 09:43:47 -0700 (PDT) References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> <8BA2751C-A4A5-46E8-9027-22A94045C3FE@cisco.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <36AD64C4-44DC-42CF-9CA6-09792BE218D2@herberg.name> X-Mailer: iPad Mail (9B206) From: Ulrich Herberg Date: Thu, 2 Aug 2012 09:43:46 -0700 To: Abdussalam Baryun X-Gm-Message-State: ALoCoQnmE3JpZ6CuPHIpKcezIz1ycnNVjBNqNnG9fZ9S1xYIy2PJL94PxCi6UIY6maVWdckERN/J Cc: manet , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:43:57 -0000 Please wait until the next revision of LOADng. We will update the introducti= on. Stay tuned! Ulrich On Aug 2, 2012, at 9:24, Abdussalam Baryun wrot= e: > Hi Stan, >=20 > We don't argue because we like it, but because we want to solve > misunderstanding, if LOADng mentions LLNs without MANET, and some > started to argue in meetings about that. LOAD is a protocol for LLN > and MANET. >=20 >> On another note, and more to the list at-large (instead of just replying t= o >> Chris), we can argue this for days, or even weeks. But the truth of the >> matter is that our charter references MANET networks, while the charter f= or >> ROLL references LLN's. It's pretty much just that simple. >=20 > To be more simple the Routing Area Charters should have clear > definitions (so if MANET includes all LLNs so just mention that, if it > doesn't then it may not include all), on the other hand our I-Ds and > RFCs should specify applicability, no protocol can solve ALL problems > of MANET, that is why we have reactive and proactive, but still if you > read RFC3626, RFC3561, OLSRv2, AODVv2, they don't mention the > different where reactive or proactive is better nor do they specify > where their performance change is the large MANET scenarios. We have > to go out of IETF publications and read IEEE publication to understand > "Applicability", am I missing some thing, >=20 > I agree that the argument may take weeks, not because people like it, > but simply because RFC2501 is not updated to include LLNs and other > issues, >=20 > AB > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > On 8/2/12, Stan Ratliff (sratliff) wrote: >> Chris, >>=20 >> On Aug 2, 2012, at 5:12 AM, Dearlove, Christopher (UK) wrote: >>=20 >>> I would subtly differently emphasise your point. (I think we are basical= ly >>> in agreement.) I would view ad hoc networks (I'm going to avoid the MANE= T >>> term as it's overloaded here) as a broad area. LLNs are a specialist >>> sub-area within that area. The MANET WG in principle covers the whole of= >>> the area, and most of its work has created protocols that can cover most= >>> of that area. However where there are specialised, and in particular mor= e >>> limited requirement, sub-areas, specialised protocols may make a better >>> trade-off (typically be simpler). And you have emphasised one of the key= >>> differences, the differing traffic pattern, and in particular the domina= nt >>> role of an egress (or ingress, but egress is often more important) >>> gateway rather than peer to peer communications (which in an LLN are >>> typically either absent, or rare enough that the otherwise inefficient g= o >>> via gateway, possibly optimised to clip off reused links, is acceptable)= . >>>=20 >>> (This bit may or may not be in agreement with Stan.) Note that I'm not >>> saying that you can't use e.g. OLSRv2 in an LLN, but that if you have mo= re >>> limited/specialised requirements you may be able to do better. Nor am I >>> saying RPL or LOADng is (or is not) that better solution, I've studied >>> neither in enough detail to have a view. >>>=20 >>=20 >> No, we agree=E2=80=A6 As a mentor of mine once said, "You can do anything= you're big >> enough to try"=E2=80=A6 ;-) ;-) The definitions we're using (MANET and LL= N) are >> somewhat vague, and somewhat overlapping. And any specific network's >> environment could well lead to multiple choices for a routing protocol. >>=20 >> On another note, and more to the list at-large (instead of just replying t= o >> Chris), we can argue this for days, or even weeks. But the truth of the >> matter is that our charter references MANET networks, while the charter f= or >> ROLL references LLN's. It's pretty much just that simple. >>=20 >> Regards, >> Stan >>=20 >>=20 >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, >>> Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] >>> Sent: 01 August 2012 17:23 >>> To: Dearlove, Christopher (UK) >>> Cc: Abdussalam Baryun; C Chauvenet; manet >>> Subject: Re: [manet] Some LLNs are NOT MANETs >>>=20 >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>>=20 >>> Precisely, Chris. >>>=20 >>> I've come to view MANETs more and more in the terms of an "opportunistic= >>> network". By that, I mean a network with a fairly large amount of >>> dynamism, and also a network that contains heterogeneity of links (e.g.,= >>> different radio types, and/or some wired portions). The challenge of the= se >>> networks is to opportunistically (and maximally) use the resources >>> available to it at any point in time. >>>=20 >>> And at least for me (and I know this will draw some fire in return), >>> another distinction in MANET as opposed to LLN is a greater requirement >>> for peer-to-peer (node-to-node) communication, =46rom what I've seen of L= LN >>> deployments (and I'm no expert), they tend to have more of a "multiple >>> source/single sink" model for the data flow. >>>=20 >>> Again, just one opinion. >>>=20 >>> Regards, >>> Stan >>>=20 >>> On Aug 1, 2012, at 11:26 AM, Dearlove, Christopher (UK) wrote: >>>=20 >>>> The statement that MANETs refers only to networks with physical mobilit= y >>>> is simply false. While the expansion of the acronym might suggest that,= >>>> in fact MANET has become a term of art, and that art includes many >>>> networks with some or all nodes that are not physically moving. >>>>=20 >>>> -- >>>> Christopher Dearlove >>>> Senior Principal Engineer, Communications Group >>>> Communications, Networks and Image Analysis Capability >>>> BAE Systems Advanced Technology Centre >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>=20 >>>> BAE Systems (Operations) Limited >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>>> Centre, Farnborough, Hants, GU14 6YU, UK >>>> Registered in England & Wales No: 1996687 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f >>>> Abdussalam Baryun >>>> Sent: 01 August 2012 14:21 >>>> To: C Chauvenet >>>> Cc: manet >>>> Subject: Re: [manet] Some LLNs are NOT MANETs >>>>=20 >>>> ----------------------! WARNING ! ---------------------- >>>> This message originates from outside our organisation, >>>> either from an external partner or from the internet. >>>> Keep this in mind if you answer this message. >>>> Follow the 'Report Suspicious Emails' link on IT matters >>>> for instructions on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>>=20 >>>> Hi C=C3=A9dric, >>>>=20 >>>> Ok we can discuss efficiently when we read the documents (production >>>> of such WG)as you agreed. >>>>=20 >>>>> When you say "IMHO, as long we have a ROLL WG in IETF we need to >>>>> forward >>>>> work to it which has no mobility behavior", do you mean that the >>>>> difference >>>>> between ROLL and MANET is limited to mobility considerations ? >>>>=20 >>>> *Mobility* It is the mostly difference clearly spoted between the >>>> documents produced by the both WGs, also the name MANET starts with >>>> Mobile, the word mobile is not equal to change/dynamic. So MANET >>>> refers to mobile node or mobile network, which means location change >>>> *NOT* topology change/dynamic. In the old days there was no ROLL WG so >>>> MANET WG was doing the job. >>>>=20 >>>>>=20 >>>>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and >>>>> RFC5867 >>>>> all include the usual IoT constraints : Memory, Processing, Power, >>>>> Battery, >>>>> Cost and Size of device. >>>>> RFC5673 does not mention explicitly processing and size constraints, >>>>> but >>>>> mention all the others. >>>>>=20 >>>>=20 >>>> Ok, >>>>=20 >>>>> RFC 2501 speak about energy and power, as you previously mentioned, bu= t >>>>> does >>>>> not say something on the following constraints : Memory, Processing, >>>>> Cost >>>>> and Size. >>>>=20 >>>> Yes your right, but be careful RFC2501 does not exclude thoes >>>> constraints either. However, if the MANET network has some nodes with >>>> constraints but clearly mobility is the main constraint. >>>>=20 >>>>>=20 >>>>> Do you think that these constraints are in the MANET scope ? >>>>> I guess that they may be (obviously for Cost), but not in the same ord= er >>>>> of >>>>> magnitude as the type of devices described in the requirements RFC of >>>>> ROLL. >>>>=20 >>>> Really don't mind either way for MANET WG, and will think that the WG >>>> community wants it in between In-Scope and Out-Scope, that may be >>>> strange but seems that is what is happening as I read documents. Out >>>> of IETF, MANET is mostly understood as mobile nodes connecting, not >>>> LLNs. >>>>=20 >>>> Overall, IMHO, in the end it is the decision of the IETF community to >>>> decide of any new idea or any I-D acceptance/adoption, but for the WG >>>> it MAY take over a WORK as an IETF I-D, but it may not be successful >>>> to convince the IETF community to continue the work or make it become >>>> a RFC, we always have to see through to make the work efforts flow >>>> successfully. We do not forget that many participants work in both >>>> WGs. >>>>=20 >>>> Regards >>>> Abdussalam >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>> On 8/1/12, C Chauvenet wrote: >>>>> Hi, >>>>>=20 >>>>> Thank you for your answer, >>>>>=20 >>>>> See inline. >>>>>=20 >>>>> Le 1 ao=C3=BBt 2012 =C3=A0 13:41, Abdussalam Baryun a =C3=A9crit : >>>>>=20 >>>>>> Hi C=C3=A9dric, >>>>>>=20 >>>>>> I think the RFC2501 is more important than the WG charter, because th= e >>>>>> charter MAY change but RFCs never changes (only can be updated, >>>>>> obsoleted or replaced). >>>>>=20 >>>>> Good Point, 100% agree. >>>>>=20 >>>>>> So far now all MANET-protocols are refering to >>>>>> RFC2501 which is good and SHOULD continue, and I like this referencin= g >>>>>> to documents (even if they are old or expired) not referencing to >>>>>> charters, because for example, if in a journal paper we reference to >>>>>> the charter of MANET WG or ROLL WG the information is not solid like >>>>>> if you reference a published document (publisher date), but still we >>>>>> can reference the charter as web reference sited date. >>>>>>=20 >>>>>> I read some paper that reference sited web documents but they may be >>>>>> not valid and cannot be read for some reason. Therefore, IMHO, we nee= d >>>>>> to stick to the following document to make a right decision in >>>>>> definitions: >>>>>>=20 >>>>>> 1) [RFC2501] for MANETs. (published in 1999) >>>>>> 2) [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] for LLNs. >>>>>> (published in 2009) >>>>>=20 >>>>> I think they are good references to build some arguments into this >>>>> discussion. >>>>>=20 >>>>>>=20 >>>>>> Low power was indicated in RFC2501 in section 5.1 as >>>>> constraints> and also the word *sink*, in page 7 you read >>>>> for energy conservation>. IMHO, as long we have a ROLL WG in IETF we >>>>>> need to forward work to it which has no mobility behavior. Delegation= >>>>>> will help make work flowing and more focused. >>>>>=20 >>>>> When you say "IMHO, as long we have a ROLL WG in IETF we need to >>>>> forward >>>>> work to it which has no mobility behavior", do you mean that the >>>>> difference >>>>> between ROLL and MANET is limited to mobility considerations ? >>>>>=20 >>>>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and >>>>> RFC5867 >>>>> all include the usual IoT constraints : Memory, Processing, Power, >>>>> Battery, >>>>> Cost and Size of device. >>>>> RFC5673 does not mention explicitly processing and size constraints, >>>>> but >>>>> mention all the others. >>>>>=20 >>>>> RFC 2501 speak about energy and power, as you previously mentioned, bu= t >>>>> does >>>>> not say something on the following constraints : Memory, Processing, >>>>> Cost >>>>> and Size. >>>>>=20 >>>>> Do you think that these constraints are in the MANET scope ? >>>>> I guess that they may be (obviously for Cost), but not in the same ord= er >>>>> of >>>>> magnitude as the type of devices described in the requirements RFC of >>>>> ROLL. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> C=C3=A9dric. >>>>>=20 >>>>>>=20 >>>>>> Regards >>>>>> AB >>>>>> =3D=3D=3D=3D=3D=3D=3D >>>>>>=20 >>>>>> On 8/1/12, C Chauvenet wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> This is an interesting discussion. >>>>>>>=20 >>>>>>> My understanding is that both MANET and ROLL considers lossy/dynamic= >>>>>>> links >>>>>>> in the way described in the MANET charter : "static and dynamic >>>>>>> topologies >>>>>>> with increased dynamics due to node motion or other factors." I also= >>>>>>> agree >>>>>>> that dynamicity of links is not hard wired to node mobility. >>>>>>>=20 >>>>>>> So, in the LLN Vs MANET debate, I think they share the "N" for >>>>>>> Networks, >>>>>>> and >>>>>>> the 2nd "L" for Lossy. >>>>>>> So the remaining point is the first L, meaning Low Power. >>>>>>>=20 >>>>>>> Low Power requirements is explicit in the ROLL charter and not >>>>>>> mentioned >>>>>>> at >>>>>>> all in the MANET charter. >>>>>>> Is the power efficiency consideration the big difference between ROL= L >>>>>>> and >>>>>>> MANET ? >>>>>>>=20 >>>>>>> C=C3=A9dric. >>>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part= >>>>>>> de >>>>>>> Abdussalam Baryun >>>>>>> Envoy=C3=A9 : mercredi 1 ao=C3=BBt 2012 09:22 >>>>>>> =C3=80 : Henning Rogge >>>>>>> Cc : roll; manet >>>>>>> Objet : [Roll] Some LLNs are NOT MANETs >>>>>>>=20 >>>>>>> Hi Henning, >>>>>>>=20 >>>>>>> I am about to say many LLNs are NOT MANETs but it seems like the >>>>>>> market >>>>>>> or >>>>>>> community will decide the outcome, but surly that some LLNs are NOT >>>>>>> MANETs. >>>>>>>=20 >>>>>>>> Could you state an example what would be considered a LLN but not a= >>>>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>>>=20 >>>>>>> I not totally agree with that, because we need to be considering bot= h >>>>>>> NETs >>>>>>> use case and applicability in the vision of the different WGs (MANET= >>>>>>> and >>>>>>> ROLL). There are many examples we can find them in the [RFC2501] for= >>>>>>> MANETs >>>>>>> characteristics and applicability, and for LLNs characteristics in >>>>>>> [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs >>>>>>> requirements. That is why I suggested before that >>>>>>> OLSRv2 and AODVv2 should mention their applicability to LLN if they >>>>>>> do. >>>>>>> They >>>>>>> just refer to RFC2501, but RFC2501 is OLD and does not mention LLN >>>>>>> but >>>>>>> describes the meaning. The authors of RFC2501 still not responded to= >>>>>>> my >>>>>>> update suggestions. >>>>>>>=20 >>>>>>> I understood from one discussion in MANET WG that few don't have tim= e >>>>>>> to >>>>>>> read many pages of documents, so that is why I suggested to have >>>>>>> terminology >>>>>>> I-D [1] as we have ROLL terminology [ROLL] . I also taken initiative= >>>>>>> to >>>>>>> make >>>>>>> new draft of MANET subnet technologies which include only related >>>>>>> LLNs >>>>>>> [AB2]. >>>>>>>=20 >>>>>>> Therefore, I will add the definition for MANET and LLN into my >>>>>>> manet-terminology draft [AB1] (propose that authors of [ROLL] define= >>>>>>> LLN >>>>>>> more details) to assist discussions as it is proved now in the list >>>>>>> that >>>>>>> there still is problems in definitions in MANET WG or in some I-D >>>>>>> editorial >>>>>>> content. >>>>>>>=20 >>>>>>> [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >>>>>>> [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >>>>>>> [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt >>>>>>>=20 >>>>>>> Best Wishes >>>>>>>=20 >>>>>>> Abdussalam Baryun >>>>>>> University of Glamorgan, UK >>>>>>>=20 >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>>>> On 7/31/12, Henning Rogge wrote: >>>>>>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>>>>>>> subject: Re: [manet] Discussing LOADng suggestions >>>>>>>> wrote: >>>>>>>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, >>>>>>>>> but >>>>>>>>> then changed its direction to MANET [3]. However, please note that= >>>>>>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That= >>>>>>>>> said, LOADng SHOULD specfy where is its limits. Then we can discus= s >>>>>>>>> adoption. >>>>>>>>=20 >>>>>>>> Could you state an example what would be considered a LLN but not a= >>>>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>>>>=20 >>>>>>>> Henning Rogge >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Steven Hawkings about cosmic inflation: "An increase of billions of= >>>>>>>> billions of percent in a tiny fraction of a second. Of course, that= >>>>>>>> was before the present government." >>>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Roll mailing list >>>>>>> Roll@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>> ******************************************************************** >>>> This email and any attachments are confidential to the intended >>>> recipient and may also be privileged. If you are not the intended >>>> recipient please delete it from your system and notify the sender. >>>> You should not copy it or use it for any purpose nor disclose or >>>> distribute its contents to any other person. >>>> ******************************************************************** >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Thu Aug 2 09:49:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C843F21E8082 for ; Thu, 2 Aug 2012 09:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKpQql-KzbgO for ; Thu, 2 Aug 2012 09:49:26 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BBA7421E809D for ; Thu, 2 Aug 2012 09:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=211; q=dns/txt; s=iport; t=1343926165; x=1345135765; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=OA2qKWJu3C+ciSYJ1abHP9IjEjQDY5Urt4Aw1HPsH9M=; b=DM/+2e+b1JX9gSfgzry30b+ibxfEHJyHrAD3XJpx9g6oFZ8rLbhHJIVz srmZXF/S3juxgn/76FahpMK9SKWM89WLLkNyPtt0JCYnhB+lRS9cYz9Bt 0wz22e+nfW/kp2bUyOx7bu2uxvpNkOEjdV181Ga9fgL3G5ZDXnJ/9puQe s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGOuGlCtJV2Y/2dsb2JhbABFuRiBB4InEgEnPxIBCDZCJgEEDieHa5xqoFORbmADlUeOJ4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,702,1336348800"; d="scan'208";a="107893945" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 02 Aug 2012 16:49:25 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q72GnP11018585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 16:49:25 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.113]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 11:49:24 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] Some LLNs are NOT MANETs Thread-Index: Ac1wzsWCNIMVZDkBeEWaaQkwSTqYtA== Date: Thu, 2 Aug 2012 16:49:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.006 x-tm-as-result: No--29.391600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , "Stan Ratliff \(sratliff\)" , Abdussalam Baryun Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:49:27 -0000 Thanks looking forward to the next revision or dump or load and clear text = on the use cases, avoiding charters conflicts according to IESG's guidance= =20 JP Vasseur Cisco Fellow Sent from my iPhone From jvasseur@cisco.com Thu Aug 2 09:49:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A294421E80A0 for ; Thu, 2 Aug 2012 09:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.239 X-Spam-Level: X-Spam-Status: No, score=-10.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeuPM2DoY8Xe for ; Thu, 2 Aug 2012 09:49:43 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B6E9021E809F for ; Thu, 2 Aug 2012 09:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=23418; q=dns/txt; s=iport; t=1343926183; x=1345135783; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9cPF10ksnpNyAsT/R+7RmYuBuCkgioLKbK9fSD7JsEE=; b=Ikme16rlN+xIWciOWhROFwJ7nFJZv9AtCR9oZ82sZcqZxkPhhKpQijQO g5oVW5oMT4aqsD3ZM7EtBqp28tnpho/+fmJlrZ/at7L++aCXLn8Czm0RV IV7Q1UCFwwgK9fH0WAg33k7QRXXdNydMITZdN4fI9ySKFcqguDZJbstO8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFKvGlCtJV2Y/2dsb2JhbABFhXuyKnOBB4IgAQEBAwEBAQEPARARIRYDAwgFBwQCAQgRBAEBAQICIwMCAgIfBgsUAQgIAgQOBQkLBweHXAMGBgucYY0ZiV8NiU6BIYlCZwUFCgcHhVAyYAOTdIFTgRSJdoMdgWaCX4FWCQ X-IronPort-AV: E=Sophos;i="4.77,702,1336348800"; d="scan'208";a="107893676" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 02 Aug 2012 16:49:31 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q72GnVje018641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 16:49:31 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.113]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 11:49:30 -0500 From: "JP Vasseur (jvasseur)" To: "Stan Ratliff (sratliff)" Thread-Topic: [manet] Some LLNs are NOT MANETs Thread-Index: AQHNb+i2NIMVZDkBeEWaaQkwSTqYtJdFaAmAgAAPqoCAARpEgIAAcBqAgAAOhAA= Date: Thu, 2 Aug 2012 16:49:30 +0000 Message-ID: <2AC25167-538E-4BBB-A93D-215F68EEA74A@cisco.com> References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> <8BA2751C-A4A5-46E8-9027-22A94045C3FE@cisco.com> In-Reply-To: <8BA2751C-A4A5-46E8-9027-22A94045C3FE@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.006 x-tm-as-result: No--61.732000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , manet , Abdussalam Baryun Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:49:44 -0000 SSBjb21wbGV0ZWx5IGFncmVlIHdpdGggU3RhbidzIGNvbmNsdXNpb25zLCBST0xMIGNvIGNoYWly IGhhdCBvbiwgY2hhcnRlcnMgYXJlIHF1aXRlIGNsZWFyLg0KDQpKUCBWYXNzZXVyDQpDaXNjbyBG ZWxsb3cNCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQpPbiAyIGFvw7t0IDIwMTIsIGF0IDA4OjU0 LCAiU3RhbiBSYXRsaWZmIChzcmF0bGlmZikiIDxzcmF0bGlmZkBjaXNjby5jb20+IHdyb3RlOg0K DQo+IENocmlzLCANCj4gDQo+IE9uIEF1ZyAyLCAyMDEyLCBhdCA1OjEyIEFNLCBEZWFybG92ZSwg Q2hyaXN0b3BoZXIgKFVLKSB3cm90ZToNCj4gDQo+PiBJIHdvdWxkIHN1YnRseSBkaWZmZXJlbnRs eSBlbXBoYXNpc2UgeW91ciBwb2ludC4gKEkgdGhpbmsgd2UgYXJlIGJhc2ljYWxseSBpbiBhZ3Jl ZW1lbnQuKSBJIHdvdWxkIHZpZXcgYWQgaG9jIG5ldHdvcmtzIChJJ20gZ29pbmcgdG8gYXZvaWQg dGhlIE1BTkVUIHRlcm0gYXMgaXQncyBvdmVybG9hZGVkIGhlcmUpIGFzIGEgYnJvYWQgYXJlYS4g TExOcyBhcmUgYSBzcGVjaWFsaXN0IHN1Yi1hcmVhIHdpdGhpbiB0aGF0IGFyZWEuIFRoZSBNQU5F VCBXRyBpbiBwcmluY2lwbGUgY292ZXJzIHRoZSB3aG9sZSBvZiB0aGUgYXJlYSwgYW5kIG1vc3Qg b2YgaXRzIHdvcmsgaGFzIGNyZWF0ZWQgcHJvdG9jb2xzIHRoYXQgY2FuIGNvdmVyIG1vc3Qgb2Yg dGhhdCBhcmVhLiBIb3dldmVyIHdoZXJlIHRoZXJlIGFyZSBzcGVjaWFsaXNlZCwgYW5kIGluIHBh cnRpY3VsYXIgbW9yZSBsaW1pdGVkIHJlcXVpcmVtZW50LCBzdWItYXJlYXMsIHNwZWNpYWxpc2Vk IHByb3RvY29scyBtYXkgbWFrZSBhIGJldHRlciB0cmFkZS1vZmYgKHR5cGljYWxseSBiZSBzaW1w bGVyKS4gQW5kIHlvdSBoYXZlIGVtcGhhc2lzZWQgb25lIG9mIHRoZSBrZXkgZGlmZmVyZW5jZXMs IHRoZSBkaWZmZXJpbmcgdHJhZmZpYyBwYXR0ZXJuLCBhbmQgaW4gcGFydGljdWxhciB0aGUgZG9t aW5hbnQgcm9sZSBvZiBhbiBlZ3Jlc3MgKG9yIGluZ3Jlc3MsIGJ1dCBlZ3Jlc3MgaXMgb2Z0ZW4g bW9yZSBpbXBvcnRhbnQpICBnYXRld2F5IHJhdGhlciB0aGFuIHBlZXIgdG8gcGVlciBjb21tdW5p Y2F0aW9ucyAod2hpY2ggaW4gYW4gTExOIGFyZSB0eXBpY2FsbHkgZWl0aGVyIGFic2VudCwgb3Ig cmFyZSBlbm91Z2ggdGhhdCB0aGUgb3RoZXJ3aXNlIGluZWZmaWNpZW50IGdvIHZpYSBnYXRld2F5 LCBwb3NzaWJseSBvcHRpbWlzZWQgdG8gY2xpcCBvZmYgcmV1c2VkIGxpbmtzLCBpcyBhY2NlcHRh YmxlKS4NCj4+IA0KPj4gKFRoaXMgYml0IG1heSBvciBtYXkgbm90IGJlIGluIGFncmVlbWVudCB3 aXRoIFN0YW4uKSBOb3RlIHRoYXQgSSdtIG5vdCBzYXlpbmcgdGhhdCB5b3UgY2FuJ3QgdXNlIGUu Zy4gT0xTUnYyIGluIGFuIExMTiwgYnV0IHRoYXQgaWYgeW91IGhhdmUgbW9yZSBsaW1pdGVkL3Nw ZWNpYWxpc2VkIHJlcXVpcmVtZW50cyB5b3UgbWF5IGJlIGFibGUgdG8gZG8gYmV0dGVyLiBOb3Ig YW0gSSBzYXlpbmcgUlBMIG9yIExPQURuZyBpcyAob3IgaXMgbm90KSB0aGF0IGJldHRlciBzb2x1 dGlvbiwgSSd2ZSBzdHVkaWVkIG5laXRoZXIgaW4gZW5vdWdoIGRldGFpbCB0byBoYXZlIGEgdmll dy4NCj4+IA0KPiANCj4gTm8sIHdlIGFncmVl4oCmIEFzIGEgbWVudG9yIG9mIG1pbmUgb25jZSBz YWlkLCAiWW91IGNhbiBkbyBhbnl0aGluZyB5b3UncmUgYmlnIGVub3VnaCB0byB0cnki4oCmIDst KSA7LSkgVGhlIGRlZmluaXRpb25zIHdlJ3JlIHVzaW5nIChNQU5FVCBhbmQgTExOKSBhcmUgc29t ZXdoYXQgdmFndWUsIGFuZCBzb21ld2hhdCBvdmVybGFwcGluZy4gQW5kIGFueSBzcGVjaWZpYyBu ZXR3b3JrJ3MgZW52aXJvbm1lbnQgY291bGQgd2VsbCBsZWFkIHRvIG11bHRpcGxlIGNob2ljZXMg Zm9yIGEgcm91dGluZyBwcm90b2NvbC4gDQo+IA0KPiBPbiBhbm90aGVyIG5vdGUsIGFuZCBtb3Jl IHRvIHRoZSBsaXN0IGF0LWxhcmdlIChpbnN0ZWFkIG9mIGp1c3QgcmVwbHlpbmcgdG8gQ2hyaXMp LCB3ZSBjYW4gYXJndWUgdGhpcyBmb3IgZGF5cywgb3IgZXZlbiB3ZWVrcy4gQnV0IHRoZSB0cnV0 aCBvZiB0aGUgbWF0dGVyIGlzIHRoYXQgb3VyIGNoYXJ0ZXIgcmVmZXJlbmNlcyBNQU5FVCBuZXR3 b3Jrcywgd2hpbGUgdGhlIGNoYXJ0ZXIgZm9yIFJPTEwgcmVmZXJlbmNlcyBMTE4ncy4gSXQncyBw cmV0dHkgbXVjaCBqdXN0IHRoYXQgc2ltcGxlLiANCj4gDQo+IFJlZ2FyZHMsDQo+IFN0YW4NCj4g DQo+IA0KPj4gLS0gDQo+PiBDaHJpc3RvcGhlciBEZWFybG92ZQ0KPj4gU2VuaW9yIFByaW5jaXBh bCBFbmdpbmVlciwgQ29tbXVuaWNhdGlvbnMgR3JvdXANCj4+IENvbW11bmljYXRpb25zLCBOZXR3 b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eQ0KPj4gQkFFIFN5c3RlbXMgQWR2YW5j ZWQgVGVjaG5vbG9neSBDZW50cmUNCj4+IFdlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJh ZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsNCj4+IFRlbDogKzQ0IDEyNDUgMjQyMTk0IHwg IEZheDogKzQ0IDEyNDUgMjQyMTI0DQo+PiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSB8 IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20NCj4+IA0KPj4gQkFFIFN5c3RlbXMgKE9wZXJhdGlv bnMpIExpbWl0ZWQNCj4+IFJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3gg ODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywgR1Ux NCA2WVUsIFVLDQo+PiBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5NjY4Nw0K Pj4gDQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBTdGFuIFJh dGxpZmYgKHNyYXRsaWZmKSBbbWFpbHRvOnNyYXRsaWZmQGNpc2NvLmNvbV0gDQo+PiBTZW50OiAw MSBBdWd1c3QgMjAxMiAxNzoyMw0KPj4gVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQo+ PiBDYzogQWJkdXNzYWxhbSBCYXJ5dW47IEMgQ2hhdXZlbmV0OyBtYW5ldA0KPj4gU3ViamVjdDog UmU6IFttYW5ldF0gU29tZSBMTE5zIGFyZSBOT1QgTUFORVRzDQo+PiANCj4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBUaGlzIG1l c3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwNCj4+IGVpdGhl ciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuDQo+PiBLZWVw IHRoaXMgaW4gbWluZCBpZiB5b3UgYW5zd2VyIHRoaXMgbWVzc2FnZS4NCj4+IEZvbGxvdyB0aGUg J1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzDQo+PiBmb3IgaW5z dHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLg0KPj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ IA0KPj4gUHJlY2lzZWx5LCBDaHJpcy4gDQo+PiANCj4+IEkndmUgY29tZSB0byB2aWV3IE1BTkVU cyBtb3JlIGFuZCBtb3JlIGluIHRoZSB0ZXJtcyBvZiBhbiAib3Bwb3J0dW5pc3RpYyBuZXR3b3Jr Ii4gQnkgdGhhdCwgSSBtZWFuIGEgbmV0d29yayB3aXRoIGEgZmFpcmx5IGxhcmdlIGFtb3VudCBv ZiBkeW5hbWlzbSwgYW5kIGFsc28gYSBuZXR3b3JrIHRoYXQgY29udGFpbnMgaGV0ZXJvZ2VuZWl0 eSBvZiBsaW5rcyAoZS5nLiwgZGlmZmVyZW50IHJhZGlvIHR5cGVzLCBhbmQvb3Igc29tZSB3aXJl ZCBwb3J0aW9ucykuIFRoZSBjaGFsbGVuZ2Ugb2YgdGhlc2UgbmV0d29ya3MgaXMgdG8gb3Bwb3J0 dW5pc3RpY2FsbHkgKGFuZCBtYXhpbWFsbHkpIHVzZSB0aGUgcmVzb3VyY2VzIGF2YWlsYWJsZSB0 byBpdCBhdCBhbnkgcG9pbnQgaW4gdGltZS4gDQo+PiANCj4+IEFuZCBhdCBsZWFzdCBmb3IgbWUg KGFuZCBJIGtub3cgdGhpcyB3aWxsIGRyYXcgc29tZSBmaXJlIGluIHJldHVybiksIGFub3RoZXIg ZGlzdGluY3Rpb24gaW4gTUFORVQgYXMgb3Bwb3NlZCB0byBMTE4gaXMgYSBncmVhdGVyIHJlcXVp cmVtZW50IGZvciBwZWVyLXRvLXBlZXIgKG5vZGUtdG8tbm9kZSkgY29tbXVuaWNhdGlvbiwgRnJv bSB3aGF0IEkndmUgc2VlbiBvZiBMTE4gZGVwbG95bWVudHMgKGFuZCBJJ20gbm8gZXhwZXJ0KSwg dGhleSB0ZW5kIHRvIGhhdmUgbW9yZSBvZiBhICJtdWx0aXBsZSBzb3VyY2Uvc2luZ2xlIHNpbmsi IG1vZGVsIGZvciB0aGUgZGF0YSBmbG93Lg0KPj4gDQo+PiBBZ2FpbiwganVzdCBvbmUgb3Bpbmlv bi4gDQo+PiANCj4+IFJlZ2FyZHMsDQo+PiBTdGFuDQo+PiANCj4+IE9uIEF1ZyAxLCAyMDEyLCBh dCAxMToyNiBBTSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgd3JvdGU6DQo+PiANCj4+PiBU aGUgc3RhdGVtZW50IHRoYXQgTUFORVRzIHJlZmVycyBvbmx5IHRvIG5ldHdvcmtzIHdpdGggcGh5 c2ljYWwgbW9iaWxpdHkgaXMgc2ltcGx5IGZhbHNlLiBXaGlsZSB0aGUgZXhwYW5zaW9uIG9mIHRo ZSBhY3JvbnltIG1pZ2h0IHN1Z2dlc3QgdGhhdCwgaW4gZmFjdCBNQU5FVCBoYXMgYmVjb21lIGEg dGVybSBvZiBhcnQsIGFuZCB0aGF0IGFydCBpbmNsdWRlcyBtYW55IG5ldHdvcmtzIHdpdGggc29t ZSBvciBhbGwgbm9kZXMgdGhhdCBhcmUgbm90IHBoeXNpY2FsbHkgbW92aW5nLg0KPj4+IA0KPj4+ IC0tIA0KPj4+IENocmlzdG9waGVyIERlYXJsb3ZlDQo+Pj4gU2VuaW9yIFByaW5jaXBhbCBFbmdp bmVlciwgQ29tbXVuaWNhdGlvbnMgR3JvdXANCj4+PiBDb21tdW5pY2F0aW9ucywgTmV0d29ya3Mg YW5kIEltYWdlIEFuYWx5c2lzIENhcGFiaWxpdHkNCj4+PiBCQUUgU3lzdGVtcyBBZHZhbmNlZCBU ZWNobm9sb2d5IENlbnRyZQ0KPj4+IFdlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRv dywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsNCj4+PiBUZWw6ICs0NCAxMjQ1IDI0MjE5NCB8ICBG YXg6ICs0NCAxMjQ1IDI0MjEyNA0KPj4+IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIHwg aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbQ0KPj4+IA0KPj4+IEJBRSBTeXN0ZW1zIChPcGVyYXRp b25zKSBMaW1pdGVkDQo+Pj4gUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJv eCA4NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBH VTE0IDZZVSwgVUsNCj4+PiBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5NjY4 Nw0KPj4+IA0KPj4+IA0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTog bWFuZXQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBBYmR1c3NhbGFtIEJhcnl1bg0KPj4+IFNlbnQ6IDAxIEF1Z3VzdCAyMDEyIDE0 OjIxDQo+Pj4gVG86IEMgQ2hhdXZlbmV0DQo+Pj4gQ2M6IG1hbmV0DQo+Pj4gU3ViamVjdDogUmU6 IFttYW5ldF0gU29tZSBMTE5zIGFyZSBOT1QgTUFORVRzDQo+Pj4gDQo+Pj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiBUaGlzIG1l c3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwNCj4+PiBlaXRo ZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20gdGhlIGludGVybmV0Lg0KPj4+IEtl ZXAgdGhpcyBpbiBtaW5kIGlmIHlvdSBhbnN3ZXIgdGhpcyBtZXNzYWdlLg0KPj4+IEZvbGxvdyB0 aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzDQo+Pj4gZm9y IGluc3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4NCj4+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPj4+IA0KPj4+IEhpIEPDqWRyaWMsDQo+Pj4gDQo+Pj4gT2sgd2UgY2FuIGRpc2N1c3MgZWZm aWNpZW50bHkgd2hlbiB3ZSByZWFkIHRoZSBkb2N1bWVudHMgKHByb2R1Y3Rpb24NCj4+PiBvZiBz dWNoIFdHKWFzIHlvdSBhZ3JlZWQuDQo+Pj4gDQo+Pj4+IFdoZW4geW91IHNheSAiSU1ITywgYXMg bG9uZyB3ZSBoYXZlIGEgUk9MTCBXRyBpbiBJRVRGIHdlIG5lZWQgdG8gZm9yd2FyZA0KPj4+PiB3 b3JrIHRvIGl0IHdoaWNoIGhhcyBubyBtb2JpbGl0eSBiZWhhdmlvciIsIGRvIHlvdSBtZWFuIHRo YXQgdGhlIGRpZmZlcmVuY2UNCj4+Pj4gYmV0d2VlbiBST0xMIGFuZCBNQU5FVCBpcyBsaW1pdGVk IHRvIG1vYmlsaXR5IGNvbnNpZGVyYXRpb25zID8NCj4+PiANCj4+PiAqTW9iaWxpdHkqIEl0IGlz IHRoZSBtb3N0bHkgZGlmZmVyZW5jZSBjbGVhcmx5IHNwb3RlZCBiZXR3ZWVuIHRoZQ0KPj4+IGRv Y3VtZW50cyBwcm9kdWNlZCBieSB0aGUgYm90aCBXR3MsIGFsc28gdGhlIG5hbWUgTUFORVQgc3Rh cnRzIHdpdGgNCj4+PiBNb2JpbGUsIHRoZSB3b3JkIG1vYmlsZSBpcyBub3QgZXF1YWwgdG8gY2hh bmdlL2R5bmFtaWMuIFNvIE1BTkVUDQo+Pj4gcmVmZXJzIHRvIG1vYmlsZSBub2RlIG9yIG1vYmls ZSBuZXR3b3JrLCB3aGljaCBtZWFucyBsb2NhdGlvbiBjaGFuZ2UNCj4+PiAqTk9UKiB0b3BvbG9n eSBjaGFuZ2UvZHluYW1pYy4gSW4gdGhlIG9sZCBkYXlzIHRoZXJlIHdhcyBubyBST0xMIFdHIHNv DQo+Pj4gTUFORVQgV0cgd2FzIGRvaW5nIHRoZSBqb2IuDQo+Pj4gDQo+Pj4+IA0KPj4+PiBCYXNl ZCBvbiB0aGUgZG9jcyB5b3UgbWVudGlvbmVkLCBJIHNlZSB0aGF0IFJGQzU1NDgsIFJGQzU4MjYs IGFuZCBSRkM1ODY3DQo+Pj4+IGFsbCBpbmNsdWRlIHRoZSB1c3VhbCBJb1QgY29uc3RyYWludHMg OiBNZW1vcnksIFByb2Nlc3NpbmcsIFBvd2VyLCBCYXR0ZXJ5LA0KPj4+PiBDb3N0IGFuZCBTaXpl IG9mIGRldmljZS4NCj4+Pj4gUkZDNTY3MyBkb2VzIG5vdCBtZW50aW9uIGV4cGxpY2l0bHkgcHJv Y2Vzc2luZyBhbmQgc2l6ZSBjb25zdHJhaW50cywgYnV0DQo+Pj4+IG1lbnRpb24gYWxsIHRoZSBv dGhlcnMuDQo+Pj4+IA0KPj4+IA0KPj4+IE9rLA0KPj4+IA0KPj4+PiBSRkMgMjUwMSBzcGVhayBh Ym91dCBlbmVyZ3kgYW5kIHBvd2VyLCBhcyB5b3UgcHJldmlvdXNseSBtZW50aW9uZWQsIGJ1dCBk b2VzDQo+Pj4+IG5vdCBzYXkgc29tZXRoaW5nIG9uIHRoZSBmb2xsb3dpbmcgY29uc3RyYWludHMg OiAgTWVtb3J5LCBQcm9jZXNzaW5nLCBDb3N0DQo+Pj4+IGFuZCBTaXplLg0KPj4+IA0KPj4+IFll cyB5b3VyIHJpZ2h0LCBidXQgYmUgY2FyZWZ1bCBSRkMyNTAxIGRvZXMgbm90IGV4Y2x1ZGUgdGhv ZXMNCj4+PiBjb25zdHJhaW50cyBlaXRoZXIuIEhvd2V2ZXIsIGlmIHRoZSBNQU5FVCBuZXR3b3Jr IGhhcyBzb21lIG5vZGVzIHdpdGgNCj4+PiBjb25zdHJhaW50cyBidXQgY2xlYXJseSBtb2JpbGl0 eSBpcyB0aGUgbWFpbiBjb25zdHJhaW50Lg0KPj4+IA0KPj4+PiANCj4+Pj4gRG8geW91IHRoaW5r IHRoYXQgdGhlc2UgY29uc3RyYWludHMgYXJlIGluIHRoZSBNQU5FVCBzY29wZSA/DQo+Pj4+IEkg Z3Vlc3MgdGhhdCB0aGV5IG1heSBiZSAob2J2aW91c2x5IGZvciBDb3N0KSwgYnV0IG5vdCBpbiB0 aGUgc2FtZSBvcmRlciBvZg0KPj4+PiBtYWduaXR1ZGUgYXMgdGhlIHR5cGUgb2YgZGV2aWNlcyBk ZXNjcmliZWQgaW4gdGhlIHJlcXVpcmVtZW50cyBSRkMgb2YgUk9MTC4NCj4+PiANCj4+PiBSZWFs bHkgZG9uJ3QgbWluZCBlaXRoZXIgd2F5IGZvciBNQU5FVCBXRywgYW5kIHdpbGwgdGhpbmsgdGhh dCB0aGUgV0cNCj4+PiBjb21tdW5pdHkgd2FudHMgaXQgaW4gYmV0d2VlbiBJbi1TY29wZSBhbmQg T3V0LVNjb3BlLCB0aGF0IG1heSBiZQ0KPj4+IHN0cmFuZ2UgYnV0IHNlZW1zIHRoYXQgaXMgd2hh dCBpcyBoYXBwZW5pbmcgYXMgSSByZWFkIGRvY3VtZW50cy4gT3V0DQo+Pj4gb2YgSUVURiwgTUFO RVQgaXMgbW9zdGx5IHVuZGVyc3Rvb2QgYXMgbW9iaWxlIG5vZGVzIGNvbm5lY3RpbmcsIG5vdA0K Pj4+IExMTnMuDQo+Pj4gDQo+Pj4gT3ZlcmFsbCwgSU1ITywgaW4gdGhlIGVuZCBpdCBpcyB0aGUg ZGVjaXNpb24gb2YgdGhlIElFVEYgY29tbXVuaXR5IHRvDQo+Pj4gZGVjaWRlIG9mIGFueSBuZXcg aWRlYSBvciBhbnkgSS1EIGFjY2VwdGFuY2UvYWRvcHRpb24sIGJ1dCBmb3IgdGhlIFdHDQo+Pj4g aXQgTUFZIHRha2Ugb3ZlciBhIFdPUksgYXMgYW4gSUVURiBJLUQsIGJ1dCBpdCBtYXkgbm90IGJl IHN1Y2Nlc3NmdWwNCj4+PiB0byBjb252aW5jZSB0aGUgSUVURiBjb21tdW5pdHkgdG8gY29udGlu dWUgdGhlIHdvcmsgb3IgbWFrZSBpdCBiZWNvbWUNCj4+PiBhIFJGQywgd2UgYWx3YXlzIGhhdmUg dG8gc2VlIHRocm91Z2ggdG8gbWFrZSB0aGUgd29yayBlZmZvcnRzIGZsb3cNCj4+PiBzdWNjZXNz ZnVsbHkuIFdlIGRvIG5vdCBmb3JnZXQgdGhhdCBtYW55IHBhcnRpY2lwYW50cyB3b3JrIGluIGJv dGgNCj4+PiBXR3MuDQo+Pj4gDQo+Pj4gUmVnYXJkcw0KPj4+IEFiZHVzc2FsYW0NCj4+PiA9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ Pj4gT24gOC8xLzEyLCBDIENoYXV2ZW5ldCA8Yy5jaGF1dmVuZXRAd2F0dGVjby5jb20+IHdyb3Rl Og0KPj4+PiBIaSwNCj4+Pj4gDQo+Pj4+IFRoYW5rIHlvdSBmb3IgeW91ciBhbnN3ZXIsDQo+Pj4+ IA0KPj4+PiBTZWUgaW5saW5lLg0KPj4+PiANCj4+Pj4gTGUgMSBhb8O7dCAyMDEyIMOgIDEzOjQx LCBBYmR1c3NhbGFtIEJhcnl1biBhIMOpY3JpdCA6DQo+Pj4+IA0KPj4+Pj4gSGkgQ8OpZHJpYywN Cj4+Pj4+IA0KPj4+Pj4gSSB0aGluayB0aGUgUkZDMjUwMSBpcyBtb3JlIGltcG9ydGFudCB0aGFu IHRoZSBXRyBjaGFydGVyLCBiZWNhdXNlIHRoZQ0KPj4+Pj4gY2hhcnRlciBNQVkgY2hhbmdlIGJ1 dCBSRkNzIG5ldmVyIGNoYW5nZXMgKG9ubHkgY2FuIGJlIHVwZGF0ZWQsDQo+Pj4+PiBvYnNvbGV0 ZWQgb3IgcmVwbGFjZWQpLg0KPj4+PiANCj4+Pj4gR29vZCBQb2ludCwgMTAwJSBhZ3JlZS4NCj4+ Pj4gDQo+Pj4+PiBTbyBmYXIgbm93IGFsbCBNQU5FVC1wcm90b2NvbHMgYXJlIHJlZmVyaW5nIHRv DQo+Pj4+PiBSRkMyNTAxIHdoaWNoIGlzIGdvb2QgYW5kIFNIT1VMRCBjb250aW51ZSwgYW5kIEkg bGlrZSB0aGlzIHJlZmVyZW5jaW5nDQo+Pj4+PiB0byBkb2N1bWVudHMgKGV2ZW4gaWYgdGhleSBh cmUgb2xkIG9yIGV4cGlyZWQpIG5vdCByZWZlcmVuY2luZyB0bw0KPj4+Pj4gY2hhcnRlcnMsIGJl Y2F1c2UgZm9yIGV4YW1wbGUsIGlmIGluIGEgam91cm5hbCBwYXBlciB3ZSByZWZlcmVuY2UgdG8N Cj4+Pj4+IHRoZSBjaGFydGVyIG9mIE1BTkVUIFdHIG9yIFJPTEwgV0cgdGhlIGluZm9ybWF0aW9u IGlzIG5vdCBzb2xpZCBsaWtlDQo+Pj4+PiBpZiB5b3UgcmVmZXJlbmNlIGEgcHVibGlzaGVkIGRv Y3VtZW50IChwdWJsaXNoZXIgZGF0ZSksIGJ1dCBzdGlsbCB3ZQ0KPj4+Pj4gY2FuIHJlZmVyZW5j ZSB0aGUgY2hhcnRlciBhcyB3ZWIgcmVmZXJlbmNlIHNpdGVkIGRhdGUuDQo+Pj4+PiANCj4+Pj4+ IEkgcmVhZCBzb21lIHBhcGVyIHRoYXQgcmVmZXJlbmNlIHNpdGVkIHdlYiBkb2N1bWVudHMgYnV0 IHRoZXkgbWF5IGJlDQo+Pj4+PiBub3QgdmFsaWQgYW5kIGNhbm5vdCBiZSByZWFkIGZvciBzb21l IHJlYXNvbi4gVGhlcmVmb3JlLCBJTUhPLCB3ZSBuZWVkDQo+Pj4+PiB0byBzdGljayB0byB0aGUg Zm9sbG93aW5nIGRvY3VtZW50IHRvIG1ha2UgYSByaWdodCBkZWNpc2lvbiBpbg0KPj4+Pj4gZGVm aW5pdGlvbnM6DQo+Pj4+PiANCj4+Pj4+IDEpIFtSRkMyNTAxXSBmb3IgTUFORVRzLiAocHVibGlz aGVkIGluIDE5OTkpDQo+Pj4+PiAyKSBbUkZDNTU0OF0sIFtSRkM1NjczXSwgW1JGQ1JGQzU4MjZd LCBhbmQgW1JGQzU4NjddIGZvciBMTE5zLg0KPj4+Pj4gKHB1Ymxpc2hlZCBpbiAyMDA5KQ0KPj4+ PiANCj4+Pj4gSSB0aGluayB0aGV5IGFyZSBnb29kIHJlZmVyZW5jZXMgdG8gYnVpbGQgc29tZSBh cmd1bWVudHMgaW50byB0aGlzDQo+Pj4+IGRpc2N1c3Npb24uDQo+Pj4+IA0KPj4+Pj4gDQo+Pj4+ PiBMb3cgcG93ZXIgd2FzIGluZGljYXRlZCBpbiBSRkMyNTAxIGluIHNlY3Rpb24gNS4xIGFzIDxw b3NzaWJseSBwb3dlcg0KPj4+Pj4gY29uc3RyYWludHM+IGFuZCBhbHNvIHRoZSB3b3JkICpzaW5r KiwgaW4gcGFnZSA3IHlvdSByZWFkIDxzbGVlcCBtb2RlDQo+Pj4+PiBmb3IgZW5lcmd5IGNvbnNl cnZhdGlvbj4uIElNSE8sIGFzIGxvbmcgd2UgaGF2ZSBhIFJPTEwgV0cgaW4gSUVURiB3ZQ0KPj4+ Pj4gbmVlZCB0byBmb3J3YXJkIHdvcmsgdG8gaXQgd2hpY2ggaGFzIG5vIG1vYmlsaXR5IGJlaGF2 aW9yLiBEZWxlZ2F0aW9uDQo+Pj4+PiB3aWxsIGhlbHAgbWFrZSB3b3JrIGZsb3dpbmcgYW5kIG1v cmUgZm9jdXNlZC4NCj4+Pj4gDQo+Pj4+IFdoZW4geW91IHNheSAiSU1ITywgYXMgbG9uZyB3ZSBo YXZlIGEgUk9MTCBXRyBpbiBJRVRGIHdlIG5lZWQgdG8gZm9yd2FyZA0KPj4+PiB3b3JrIHRvIGl0 IHdoaWNoIGhhcyBubyBtb2JpbGl0eSBiZWhhdmlvciIsIGRvIHlvdSBtZWFuIHRoYXQgdGhlIGRp ZmZlcmVuY2UNCj4+Pj4gYmV0d2VlbiBST0xMIGFuZCBNQU5FVCBpcyBsaW1pdGVkIHRvIG1vYmls aXR5IGNvbnNpZGVyYXRpb25zID8NCj4+Pj4gDQo+Pj4+IEJhc2VkIG9uIHRoZSBkb2NzIHlvdSBt ZW50aW9uZWQsIEkgc2VlIHRoYXQgUkZDNTU0OCwgUkZDNTgyNiwgYW5kIFJGQzU4NjcNCj4+Pj4g YWxsIGluY2x1ZGUgdGhlIHVzdWFsIElvVCBjb25zdHJhaW50cyA6IE1lbW9yeSwgUHJvY2Vzc2lu ZywgUG93ZXIsIEJhdHRlcnksDQo+Pj4+IENvc3QgYW5kIFNpemUgb2YgZGV2aWNlLg0KPj4+PiBS RkM1NjczIGRvZXMgbm90IG1lbnRpb24gZXhwbGljaXRseSBwcm9jZXNzaW5nIGFuZCBzaXplIGNv bnN0cmFpbnRzLCBidXQNCj4+Pj4gbWVudGlvbiBhbGwgdGhlIG90aGVycy4NCj4+Pj4gDQo+Pj4+ IFJGQyAyNTAxIHNwZWFrIGFib3V0IGVuZXJneSBhbmQgcG93ZXIsIGFzIHlvdSBwcmV2aW91c2x5 IG1lbnRpb25lZCwgYnV0IGRvZXMNCj4+Pj4gbm90IHNheSBzb21ldGhpbmcgb24gdGhlIGZvbGxv d2luZyBjb25zdHJhaW50cyA6ICBNZW1vcnksIFByb2Nlc3NpbmcsIENvc3QNCj4+Pj4gYW5kIFNp emUuDQo+Pj4+IA0KPj4+PiBEbyB5b3UgdGhpbmsgdGhhdCB0aGVzZSBjb25zdHJhaW50cyBhcmUg aW4gdGhlIE1BTkVUIHNjb3BlID8NCj4+Pj4gSSBndWVzcyB0aGF0IHRoZXkgbWF5IGJlIChvYnZp b3VzbHkgZm9yIENvc3QpLCBidXQgbm90IGluIHRoZSBzYW1lIG9yZGVyIG9mDQo+Pj4+IG1hZ25p dHVkZSBhcyB0aGUgdHlwZSBvZiBkZXZpY2VzIGRlc2NyaWJlZCBpbiB0aGUgcmVxdWlyZW1lbnRz IFJGQyBvZiBST0xMLg0KPj4+PiANCj4+Pj4gUmVnYXJkcywNCj4+Pj4gDQo+Pj4+IEPDqWRyaWMu DQo+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBSZWdhcmRzDQo+Pj4+PiBBQg0KPj4+Pj4gPT09PT09PQ0K Pj4+Pj4gDQo+Pj4+PiBPbiA4LzEvMTIsIEMgQ2hhdXZlbmV0IDxjLmNoYXV2ZW5ldEB3YXR0ZWNv LmNvbT4gd3JvdGU6DQo+Pj4+Pj4gSGksDQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhpcyBpcyBhbiBpbnRl cmVzdGluZyBkaXNjdXNzaW9uLg0KPj4+Pj4+IA0KPj4+Pj4+IE15IHVuZGVyc3RhbmRpbmcgaXMg dGhhdCBib3RoIE1BTkVUIGFuZCBST0xMIGNvbnNpZGVycyBsb3NzeS9keW5hbWljDQo+Pj4+Pj4g bGlua3MNCj4+Pj4+PiBpbiB0aGUgd2F5IGRlc2NyaWJlZCBpbiB0aGUgTUFORVQgY2hhcnRlciA6 ICAic3RhdGljIGFuZCBkeW5hbWljDQo+Pj4+Pj4gdG9wb2xvZ2llcw0KPj4+Pj4+IHdpdGggaW5j cmVhc2VkIGR5bmFtaWNzIGR1ZSB0byBub2RlIG1vdGlvbiBvciBvdGhlciBmYWN0b3JzLiIgSSBh bHNvDQo+Pj4+Pj4gYWdyZWUNCj4+Pj4+PiB0aGF0IGR5bmFtaWNpdHkgb2YgbGlua3MgaXMgbm90 IGhhcmQgd2lyZWQgdG8gbm9kZSBtb2JpbGl0eS4NCj4+Pj4+PiANCj4+Pj4+PiBTbywgaW4gdGhl IExMTiBWcyBNQU5FVCBkZWJhdGUsIEkgdGhpbmsgdGhleSBzaGFyZSB0aGUgIk4iIGZvciBOZXR3 b3JrcywNCj4+Pj4+PiBhbmQNCj4+Pj4+PiB0aGUgMm5kICJMIiBmb3IgTG9zc3kuDQo+Pj4+Pj4g U28gdGhlIHJlbWFpbmluZyBwb2ludCBpcyB0aGUgZmlyc3QgTCwgbWVhbmluZyBMb3cgUG93ZXIu DQo+Pj4+Pj4gDQo+Pj4+Pj4gTG93IFBvd2VyIHJlcXVpcmVtZW50cyBpcyBleHBsaWNpdCBpbiB0 aGUgUk9MTCBjaGFydGVyIGFuZCBub3QgbWVudGlvbmVkDQo+Pj4+Pj4gYXQNCj4+Pj4+PiBhbGwg aW4gdGhlIE1BTkVUIGNoYXJ0ZXIuDQo+Pj4+Pj4gSXMgdGhlIHBvd2VyIGVmZmljaWVuY3kgY29u c2lkZXJhdGlvbiB0aGUgYmlnIGRpZmZlcmVuY2UgYmV0d2VlbiBST0xMDQo+Pj4+Pj4gYW5kDQo+ Pj4+Pj4gTUFORVQgPw0KPj4+Pj4+IA0KPj4+Pj4+IEPDqWRyaWMuDQo+Pj4+Pj4gDQo+Pj4+Pj4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4+Pj4gRGUgOiByb2xsLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUNCj4+Pj4+ PiBBYmR1c3NhbGFtIEJhcnl1bg0KPj4+Pj4+IEVudm95w6kgOiBtZXJjcmVkaSAxIGFvw7t0IDIw MTIgMDk6MjINCj4+Pj4+PiDDgCA6IEhlbm5pbmcgUm9nZ2UNCj4+Pj4+PiBDYyA6IHJvbGw7IG1h bmV0DQo+Pj4+Pj4gT2JqZXQgOiBbUm9sbF0gU29tZSBMTE5zIGFyZSBOT1QgTUFORVRzDQo+Pj4+ Pj4gDQo+Pj4+Pj4gSGkgSGVubmluZywNCj4+Pj4+PiANCj4+Pj4+PiBJIGFtIGFib3V0IHRvIHNh eSBtYW55IExMTnMgYXJlIE5PVCBNQU5FVHMgYnV0IGl0IHNlZW1zIGxpa2UgdGhlIG1hcmtldA0K Pj4+Pj4+IG9yDQo+Pj4+Pj4gY29tbXVuaXR5IHdpbGwgZGVjaWRlIHRoZSBvdXRjb21lLCBidXQg c3VybHkgdGhhdCBzb21lIExMTnMgYXJlIE5PVA0KPj4+Pj4+IE1BTkVUcy4NCj4+Pj4+PiANCj4+ Pj4+Pj4gQ291bGQgeW91IHN0YXRlIGFuIGV4YW1wbGUgd2hhdCB3b3VsZCBiZSBjb25zaWRlcmVk IGEgTExOIGJ1dCBub3QgYQ0KPj4+Pj4+PiBNQU5FVC4gSSBub3JtYWxseSBjb25zaWRlciBMTE5z IGEgc3Vic2V0IG9mIHdoYXQgd2UgY2FsbCBNQU5FVHMuDQo+Pj4+Pj4gDQo+Pj4+Pj4gSSBub3Qg dG90YWxseSBhZ3JlZSB3aXRoIHRoYXQsIGJlY2F1c2Ugd2UgbmVlZCB0byBiZSBjb25zaWRlcmlu ZyBib3RoDQo+Pj4+Pj4gTkVUcw0KPj4+Pj4+IHVzZSBjYXNlIGFuZCBhcHBsaWNhYmlsaXR5IGlu IHRoZSB2aXNpb24gb2YgdGhlIGRpZmZlcmVudCBXR3MgKE1BTkVUIGFuZA0KPj4+Pj4+IFJPTEwp LiBUaGVyZSBhcmUgbWFueSBleGFtcGxlcyB3ZSBjYW4gZmluZCB0aGVtIGluIHRoZSBbUkZDMjUw MV0gZm9yDQo+Pj4+Pj4gTUFORVRzDQo+Pj4+Pj4gY2hhcmFjdGVyaXN0aWNzIGFuZCBhcHBsaWNh YmlsaXR5LCBhbmQgZm9yIExMTnMgY2hhcmFjdGVyaXN0aWNzIGluDQo+Pj4+Pj4gW1JGQzU1NDhd LCBbUkZDNTY3M10sIFtSRkNSRkM1ODI2XSwgYW5kIFtSRkM1ODY3XSBpbmNsdWRpbmcgTExOcw0K Pj4+Pj4+IHJlcXVpcmVtZW50cy4gVGhhdCBpcyB3aHkgSSBzdWdnZXN0ZWQgYmVmb3JlIHRoYXQN Cj4+Pj4+PiBPTFNSdjIgYW5kIEFPRFZ2MiBzaG91bGQgbWVudGlvbiB0aGVpciBhcHBsaWNhYmls aXR5IHRvIExMTiBpZiB0aGV5IGRvLg0KPj4+Pj4+IFRoZXkNCj4+Pj4+PiBqdXN0IHJlZmVyIHRv IFJGQzI1MDEsIGJ1dCBSRkMyNTAxIGlzIE9MRCBhbmQgZG9lcyBub3QgbWVudGlvbiBMTE4gYnV0 DQo+Pj4+Pj4gZGVzY3JpYmVzIHRoZSBtZWFuaW5nLiBUaGUgYXV0aG9ycyBvZiBSRkMyNTAxIHN0 aWxsIG5vdCByZXNwb25kZWQgdG8gbXkNCj4+Pj4+PiB1cGRhdGUgc3VnZ2VzdGlvbnMuDQo+Pj4+ Pj4gDQo+Pj4+Pj4gSSB1bmRlcnN0b29kIGZyb20gb25lIGRpc2N1c3Npb24gaW4gTUFORVQgV0cg dGhhdCBmZXcgZG9uJ3QgaGF2ZSB0aW1lIHRvDQo+Pj4+Pj4gcmVhZCBtYW55IHBhZ2VzIG9mIGRv Y3VtZW50cywgc28gdGhhdCBpcyB3aHkgSSBzdWdnZXN0ZWQgdG8gaGF2ZQ0KPj4+Pj4+IHRlcm1p bm9sb2d5DQo+Pj4+Pj4gSS1EIFsxXSBhcyB3ZSBoYXZlIFJPTEwgdGVybWlub2xvZ3kgW1JPTExd IC4gSSBhbHNvIHRha2VuIGluaXRpYXRpdmUgdG8NCj4+Pj4+PiBtYWtlDQo+Pj4+Pj4gbmV3IGRy YWZ0IG9mICBNQU5FVCBzdWJuZXQgdGVjaG5vbG9naWVzIHdoaWNoIGluY2x1ZGUgb25seSByZWxh dGVkIExMTnMNCj4+Pj4+PiBbQUIyXS4NCj4+Pj4+PiANCj4+Pj4+PiBUaGVyZWZvcmUsIEkgd2ls bCBhZGQgdGhlIGRlZmluaXRpb24gZm9yIE1BTkVUIGFuZCBMTE4gaW50byBteQ0KPj4+Pj4+IG1h bmV0LXRlcm1pbm9sb2d5IGRyYWZ0IFtBQjFdIChwcm9wb3NlIHRoYXQgYXV0aG9ycyBvZiBbUk9M TF0gZGVmaW5lIExMTg0KPj4+Pj4+IG1vcmUgZGV0YWlscykgdG8gYXNzaXN0IGRpc2N1c3Npb25z IGFzIGl0IGlzIHByb3ZlZCBub3cgaW4gdGhlIGxpc3QgdGhhdA0KPj4+Pj4+IHRoZXJlIHN0aWxs IGlzIHByb2JsZW1zIGluIGRlZmluaXRpb25zIGluIE1BTkVUIFdHIG9yIGluIHNvbWUgSS1EDQo+ Pj4+Pj4gZWRpdG9yaWFsDQo+Pj4+Pj4gY29udGVudC4NCj4+Pj4+PiANCj4+Pj4+PiBbQUIxXSBo dHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWJhcnl1bi1tYW5ldC10ZXJtaW5vbG9neS0wMC50 eHQNCj4+Pj4+PiBbQUIyXSBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWJhcnl1bi1tYW5l dC10ZWNobm9sb2d5LTAwLnR4dA0KPj4+Pj4+IFtST0xMXSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aWQvZHJhZnQtaWV0Zi1yb2xsLXRlcm1pbm9sb2d5LTA2LnR4dA0KPj4+Pj4+IA0KPj4+Pj4+IEJl c3QgV2lzaGVzDQo+Pj4+Pj4gDQo+Pj4+Pj4gQWJkdXNzYWxhbSBCYXJ5dW4NCj4+Pj4+PiBVbml2 ZXJzaXR5IG9mIEdsYW1vcmdhbiwgVUsNCj4+Pj4+PiANCj4+Pj4+PiA9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+Pj4+Pj4gT24gNy8zMS8xMiwg SGVubmluZyBSb2dnZSA8aHJvZ2dlQGdvb2dsZW1haWwuY29tPiB3cm90ZToNCj4+Pj4+Pj4gT24g VHVlLCBKdWwgMzEsIDIwMTIgYXQgNjo0NSBBTSwgQWJkdXNzYWxhbSBCYXJ5dW4NCj4+Pj4+Pj4g c3ViamVjdDogUmU6IFttYW5ldF0gRGlzY3Vzc2luZyBMT0FEbmcgc3VnZ2VzdGlvbnMNCj4+Pj4+ Pj4gPGFiZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tPiB3cm90ZToNCj4+Pj4+Pj4+IElNSE8gdGhp cyBwcm90b2NvbCB3YXMgaW50ZW5kZWQgYXMgZm9yIFJPTEwgV0cgbm90IGZvciBNQU5FVCBXRywg YnV0DQo+Pj4+Pj4+PiB0aGVuIGNoYW5nZWQgaXRzIGRpcmVjdGlvbiB0byBNQU5FVCBbM10uIEhv d2V2ZXIsIHBsZWFzZSBub3RlIHRoYXQNCj4+Pj4+Pj4+ICpPTkxZKiBzb21lIExMTnMgYXJlIE1B TkVUcywgYW5kICpPTkxZKiBzb21lIE1BTkVUcyBhcmUgTExOcy4gVGhhdA0KPj4+Pj4+Pj4gc2Fp ZCwgTE9BRG5nIFNIT1VMRCBzcGVjZnkgd2hlcmUgaXMgaXRzIGxpbWl0cy4gVGhlbiB3ZSBjYW4g ZGlzY3Vzcw0KPj4+Pj4+Pj4gYWRvcHRpb24uDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBDb3VsZCB5b3Ug c3RhdGUgYW4gZXhhbXBsZSB3aGF0IHdvdWxkIGJlIGNvbnNpZGVyZWQgYSBMTE4gYnV0IG5vdCBh DQo+Pj4+Pj4+IE1BTkVULiBJIG5vcm1hbGx5IGNvbnNpZGVyIExMTnMgYSBzdWJzZXQgb2Ygd2hh dCB3ZSBjYWxsIE1BTkVUcy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEhlbm5pbmcgUm9nZ2UNCj4+Pj4+ Pj4gDQo+Pj4+Pj4+IC0tDQo+Pj4+Pj4+IFN0ZXZlbiBIYXdraW5ncyBhYm91dCBjb3NtaWMgaW5m bGF0aW9uOiAiQW4gaW5jcmVhc2Ugb2YgYmlsbGlvbnMgb2YNCj4+Pj4+Pj4gYmlsbGlvbnMgb2Yg cGVyY2VudCBpbiBhIHRpbnkgZnJhY3Rpb24gb2YgYSBzZWNvbmQuIE9mIGNvdXJzZSwgdGhhdA0K Pj4+Pj4+PiB3YXMgYmVmb3JlIHRoZSBwcmVzZW50IGdvdmVybm1lbnQuIg0KPj4+Pj4+PiANCj4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ Pj4+IFJvbGwgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gUm9sbEBpZXRmLm9yZw0KPj4+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0KPj4+Pj4+IA0KPj4+Pj4+IA0K Pj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBtYW5ldCBtYWlsaW5nIGxpc3QN Cj4+PiBtYW5ldEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbWFuZXQNCj4+PiANCj4+PiANCj4+PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPj4+IFRoaXMgZW1haWwg YW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZA0KPj4+ IHJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkDQo+Pj4gcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3Rl bSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuDQo+Pj4gWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcg0KPj4+IGRpc3RyaWJ1dGUgaXRz IGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uDQo+Pj4gKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+PiANCj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG1h bmV0IG1haWxpbmcgbGlzdA0KPj4+IG1hbmV0QGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KPj4gDQo+PiANCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1hbmV0IG1haWxpbmcgbGlz dA0KPiBtYW5ldEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21hbmV0DQo= From jvasseur@cisco.com Thu Aug 2 10:06:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1003121F85C4 for ; Thu, 2 Aug 2012 10:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HT7UugA2QACy for ; Thu, 2 Aug 2012 10:05:59 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E1D1D21F85A0 for ; Thu, 2 Aug 2012 10:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=21018; q=dns/txt; s=iport; t=1343927159; x=1345136759; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4i57y1zHzjIRx9uPz711qCRetAB40AwhaF9ahec8whc=; b=ezWu6gEh9gOhCnLqAExJ5FHHjA1kqwAE0MdXv0GphImKV1NYRryun8Py IVcyI9c1vmxr4M8UOdx7nCLJ/DKsKCj7WM+RO4Zk+vCL/PEaTbiF7Tbbz yeZJPzyz5agiUW7mZG3Xun1bDyA8KLpDVVr4Ci8uV5S8ynQUhjZAefDaq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcZAEmyGlCtJXHA/2dsb2JhbABFgXUGAbccgQeCIAEBAQMBAQEBDwFCFgMDCAUHBAIBCBEEAQEBJwchBgsUCQgCBA4FCQsHB4dcAwYGC5xhlnkNiU6KY2cFBQoHB4YCYAOTdIFTgRSJdoMdgWaCX4FWCQ X-IronPort-AV: E=Sophos;i="4.77,702,1336348800"; d="scan'208";a="107896982" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 02 Aug 2012 17:05:58 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q72H5vm2016607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 17:05:57 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.113]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 12:05:57 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] Some LLNs are NOT MANETs Thread-Index: AQHNb+i2NIMVZDkBeEWaaQkwSTqYtJdFaAmAgAAPqoCAARpEgIAAcBqAgAAIYoCAAAWFAP//smEx Date: Thu, 2 Aug 2012 17:05:57 +0000 Message-ID: <64BC16A9-E170-4338-ABF1-FCCE1C71FCAC@cisco.com> References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> <8BA2751C-A4A5-46E8-9027-22A94045C3FE@cisco.com> , <36AD64C4-44DC-42CF-9CA6-09792BE218D2@herberg.name> In-Reply-To: <36AD64C4-44DC-42CF-9CA6-09792BE218D2@herberg.name> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.006 x-tm-as-result: No--65.835100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , "Stan Ratliff \(sratliff\)" , Abdussalam Baryun Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:06:01 -0000 Looking forward to the next revision of Dymo or Load with a clear statement= of the use case and applicability thus avoiding confusion and so as to be = by sync with Roll and Manet's charters according to IESG's guidance=20 JP Vasseur Cisco Fellow Sent from my iPhone On 2 ao=FBt 2012, at 09:44, "Ulrich Herberg" wrote: > Please wait until the next revision of LOADng. We will update the introdu= ction. Stay tuned! >=20 > Ulrich >=20 > On Aug 2, 2012, at 9:24, Abdussalam Baryun w= rote: >=20 >> Hi Stan, >>=20 >> We don't argue because we like it, but because we want to solve >> misunderstanding, if LOADng mentions LLNs without MANET, and some >> started to argue in meetings about that. LOAD is a protocol for LLN >> and MANET. >>=20 >>> On another note, and more to the list at-large (instead of just replyin= g to >>> Chris), we can argue this for days, or even weeks. But the truth of the >>> matter is that our charter references MANET networks, while the charter= for >>> ROLL references LLN's. It's pretty much just that simple. >>=20 >> To be more simple the Routing Area Charters should have clear >> definitions (so if MANET includes all LLNs so just mention that, if it >> doesn't then it may not include all), on the other hand our I-Ds and >> RFCs should specify applicability, no protocol can solve ALL problems >> of MANET, that is why we have reactive and proactive, but still if you >> read RFC3626, RFC3561, OLSRv2, AODVv2, they don't mention the >> different where reactive or proactive is better nor do they specify >> where their performance change is the large MANET scenarios. We have >> to go out of IETF publications and read IEEE publication to understand >> "Applicability", am I missing some thing, >>=20 >> I agree that the argument may take weeks, not because people like it, >> but simply because RFC2501 is not updated to include LLNs and other >> issues, >>=20 >> AB >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> On 8/2/12, Stan Ratliff (sratliff) wrote: >>> Chris, >>>=20 >>> On Aug 2, 2012, at 5:12 AM, Dearlove, Christopher (UK) wrote: >>>=20 >>>> I would subtly differently emphasise your point. (I think we are basic= ally >>>> in agreement.) I would view ad hoc networks (I'm going to avoid the MA= NET >>>> term as it's overloaded here) as a broad area. LLNs are a specialist >>>> sub-area within that area. The MANET WG in principle covers the whole = of >>>> the area, and most of its work has created protocols that can cover mo= st >>>> of that area. However where there are specialised, and in particular m= ore >>>> limited requirement, sub-areas, specialised protocols may make a bette= r >>>> trade-off (typically be simpler). And you have emphasised one of the k= ey >>>> differences, the differing traffic pattern, and in particular the domi= nant >>>> role of an egress (or ingress, but egress is often more important) >>>> gateway rather than peer to peer communications (which in an LLN are >>>> typically either absent, or rare enough that the otherwise inefficient= go >>>> via gateway, possibly optimised to clip off reused links, is acceptabl= e). >>>>=20 >>>> (This bit may or may not be in agreement with Stan.) Note that I'm not >>>> saying that you can't use e.g. OLSRv2 in an LLN, but that if you have = more >>>> limited/specialised requirements you may be able to do better. Nor am = I >>>> saying RPL or LOADng is (or is not) that better solution, I've studied >>>> neither in enough detail to have a view. >>>>=20 >>>=20 >>> No, we agree=85 As a mentor of mine once said, "You can do anything you= 're big >>> enough to try"=85 ;-) ;-) The definitions we're using (MANET and LLN) a= re >>> somewhat vague, and somewhat overlapping. And any specific network's >>> environment could well lead to multiple choices for a routing protocol. >>>=20 >>> On another note, and more to the list at-large (instead of just replyin= g to >>> Chris), we can argue this for days, or even weeks. But the truth of the >>> matter is that our charter references MANET networks, while the charter= for >>> ROLL references LLN's. It's pretty much just that simple. >>>=20 >>> Regards, >>> Stan >>>=20 >>>=20 >>>> -- >>>> Christopher Dearlove >>>> Senior Principal Engineer, Communications Group >>>> Communications, Networks and Image Analysis Capability >>>> BAE Systems Advanced Technology Centre >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>=20 >>>> BAE Systems (Operations) Limited >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, >>>> Farnborough, Hants, GU14 6YU, UK >>>> Registered in England & Wales No: 1996687 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] >>>> Sent: 01 August 2012 17:23 >>>> To: Dearlove, Christopher (UK) >>>> Cc: Abdussalam Baryun; C Chauvenet; manet >>>> Subject: Re: [manet] Some LLNs are NOT MANETs >>>>=20 >>>> ----------------------! WARNING ! ---------------------- >>>> This message originates from outside our organisation, >>>> either from an external partner or from the internet. >>>> Keep this in mind if you answer this message. >>>> Follow the 'Report Suspicious Emails' link on IT matters >>>> for instructions on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>>=20 >>>> Precisely, Chris. >>>>=20 >>>> I've come to view MANETs more and more in the terms of an "opportunist= ic >>>> network". By that, I mean a network with a fairly large amount of >>>> dynamism, and also a network that contains heterogeneity of links (e.g= ., >>>> different radio types, and/or some wired portions). The challenge of t= hese >>>> networks is to opportunistically (and maximally) use the resources >>>> available to it at any point in time. >>>>=20 >>>> And at least for me (and I know this will draw some fire in return), >>>> another distinction in MANET as opposed to LLN is a greater requiremen= t >>>> for peer-to-peer (node-to-node) communication, From what I've seen of = LLN >>>> deployments (and I'm no expert), they tend to have more of a "multiple >>>> source/single sink" model for the data flow. >>>>=20 >>>> Again, just one opinion. >>>>=20 >>>> Regards, >>>> Stan >>>>=20 >>>> On Aug 1, 2012, at 11:26 AM, Dearlove, Christopher (UK) wrote: >>>>=20 >>>>> The statement that MANETs refers only to networks with physical mobil= ity >>>>> is simply false. While the expansion of the acronym might suggest tha= t, >>>>> in fact MANET has become a term of art, and that art includes many >>>>> networks with some or all nodes that are not physically moving. >>>>>=20 >>>>> -- >>>>> Christopher Dearlove >>>>> Senior Principal Engineer, Communications Group >>>>> Communications, Networks and Image Analysis Capability >>>>> BAE Systems Advanced Technology Centre >>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>=20 >>>>> BAE Systems (Operations) Limited >>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>>>> Centre, Farnborough, Hants, GU14 6YU, UK >>>>> Registered in England & Wales No: 1996687 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behal= f Of >>>>> Abdussalam Baryun >>>>> Sent: 01 August 2012 14:21 >>>>> To: C Chauvenet >>>>> Cc: manet >>>>> Subject: Re: [manet] Some LLNs are NOT MANETs >>>>>=20 >>>>> ----------------------! WARNING ! ---------------------- >>>>> This message originates from outside our organisation, >>>>> either from an external partner or from the internet. >>>>> Keep this in mind if you answer this message. >>>>> Follow the 'Report Suspicious Emails' link on IT matters >>>>> for instructions on reporting suspicious email messages. >>>>> -------------------------------------------------------- >>>>>=20 >>>>> Hi C=E9dric, >>>>>=20 >>>>> Ok we can discuss efficiently when we read the documents (production >>>>> of such WG)as you agreed. >>>>>=20 >>>>>> When you say "IMHO, as long we have a ROLL WG in IETF we need to >>>>>> forward >>>>>> work to it which has no mobility behavior", do you mean that the >>>>>> difference >>>>>> between ROLL and MANET is limited to mobility considerations ? >>>>>=20 >>>>> *Mobility* It is the mostly difference clearly spoted between the >>>>> documents produced by the both WGs, also the name MANET starts with >>>>> Mobile, the word mobile is not equal to change/dynamic. So MANET >>>>> refers to mobile node or mobile network, which means location change >>>>> *NOT* topology change/dynamic. In the old days there was no ROLL WG s= o >>>>> MANET WG was doing the job. >>>>>=20 >>>>>>=20 >>>>>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and >>>>>> RFC5867 >>>>>> all include the usual IoT constraints : Memory, Processing, Power, >>>>>> Battery, >>>>>> Cost and Size of device. >>>>>> RFC5673 does not mention explicitly processing and size constraints, >>>>>> but >>>>>> mention all the others. >>>>>>=20 >>>>>=20 >>>>> Ok, >>>>>=20 >>>>>> RFC 2501 speak about energy and power, as you previously mentioned, = but >>>>>> does >>>>>> not say something on the following constraints : Memory, Processing= , >>>>>> Cost >>>>>> and Size. >>>>>=20 >>>>> Yes your right, but be careful RFC2501 does not exclude thoes >>>>> constraints either. However, if the MANET network has some nodes with >>>>> constraints but clearly mobility is the main constraint. >>>>>=20 >>>>>>=20 >>>>>> Do you think that these constraints are in the MANET scope ? >>>>>> I guess that they may be (obviously for Cost), but not in the same o= rder >>>>>> of >>>>>> magnitude as the type of devices described in the requirements RFC o= f >>>>>> ROLL. >>>>>=20 >>>>> Really don't mind either way for MANET WG, and will think that the WG >>>>> community wants it in between In-Scope and Out-Scope, that may be >>>>> strange but seems that is what is happening as I read documents. Out >>>>> of IETF, MANET is mostly understood as mobile nodes connecting, not >>>>> LLNs. >>>>>=20 >>>>> Overall, IMHO, in the end it is the decision of the IETF community to >>>>> decide of any new idea or any I-D acceptance/adoption, but for the WG >>>>> it MAY take over a WORK as an IETF I-D, but it may not be successful >>>>> to convince the IETF community to continue the work or make it become >>>>> a RFC, we always have to see through to make the work efforts flow >>>>> successfully. We do not forget that many participants work in both >>>>> WGs. >>>>>=20 >>>>> Regards >>>>> Abdussalam >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> On 8/1/12, C Chauvenet wrote: >>>>>> Hi, >>>>>>=20 >>>>>> Thank you for your answer, >>>>>>=20 >>>>>> See inline. >>>>>>=20 >>>>>> Le 1 ao=FBt 2012 =E0 13:41, Abdussalam Baryun a =E9crit : >>>>>>=20 >>>>>>> Hi C=E9dric, >>>>>>>=20 >>>>>>> I think the RFC2501 is more important than the WG charter, because = the >>>>>>> charter MAY change but RFCs never changes (only can be updated, >>>>>>> obsoleted or replaced). >>>>>>=20 >>>>>> Good Point, 100% agree. >>>>>>=20 >>>>>>> So far now all MANET-protocols are refering to >>>>>>> RFC2501 which is good and SHOULD continue, and I like this referenc= ing >>>>>>> to documents (even if they are old or expired) not referencing to >>>>>>> charters, because for example, if in a journal paper we reference t= o >>>>>>> the charter of MANET WG or ROLL WG the information is not solid lik= e >>>>>>> if you reference a published document (publisher date), but still w= e >>>>>>> can reference the charter as web reference sited date. >>>>>>>=20 >>>>>>> I read some paper that reference sited web documents but they may b= e >>>>>>> not valid and cannot be read for some reason. Therefore, IMHO, we n= eed >>>>>>> to stick to the following document to make a right decision in >>>>>>> definitions: >>>>>>>=20 >>>>>>> 1) [RFC2501] for MANETs. (published in 1999) >>>>>>> 2) [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] for LLNs. >>>>>>> (published in 2009) >>>>>>=20 >>>>>> I think they are good references to build some arguments into this >>>>>> discussion. >>>>>>=20 >>>>>>>=20 >>>>>>> Low power was indicated in RFC2501 in section 5.1 as >>>>>> constraints> and also the word *sink*, in page 7 you read >>>>>> for energy conservation>. IMHO, as long we have a ROLL WG in IETF w= e >>>>>>> need to forward work to it which has no mobility behavior. Delegati= on >>>>>>> will help make work flowing and more focused. >>>>>>=20 >>>>>> When you say "IMHO, as long we have a ROLL WG in IETF we need to >>>>>> forward >>>>>> work to it which has no mobility behavior", do you mean that the >>>>>> difference >>>>>> between ROLL and MANET is limited to mobility considerations ? >>>>>>=20 >>>>>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and >>>>>> RFC5867 >>>>>> all include the usual IoT constraints : Memory, Processing, Power, >>>>>> Battery, >>>>>> Cost and Size of device. >>>>>> RFC5673 does not mention explicitly processing and size constraints, >>>>>> but >>>>>> mention all the others. >>>>>>=20 >>>>>> RFC 2501 speak about energy and power, as you previously mentioned, = but >>>>>> does >>>>>> not say something on the following constraints : Memory, Processing= , >>>>>> Cost >>>>>> and Size. >>>>>>=20 >>>>>> Do you think that these constraints are in the MANET scope ? >>>>>> I guess that they may be (obviously for Cost), but not in the same o= rder >>>>>> of >>>>>> magnitude as the type of devices described in the requirements RFC o= f >>>>>> ROLL. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> C=E9dric. >>>>>>=20 >>>>>>>=20 >>>>>>> Regards >>>>>>> AB >>>>>>> =3D=3D=3D=3D=3D=3D=3D >>>>>>>=20 >>>>>>> On 8/1/12, C Chauvenet wrote: >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> This is an interesting discussion. >>>>>>>>=20 >>>>>>>> My understanding is that both MANET and ROLL considers lossy/dynam= ic >>>>>>>> links >>>>>>>> in the way described in the MANET charter : "static and dynamic >>>>>>>> topologies >>>>>>>> with increased dynamics due to node motion or other factors." I al= so >>>>>>>> agree >>>>>>>> that dynamicity of links is not hard wired to node mobility. >>>>>>>>=20 >>>>>>>> So, in the LLN Vs MANET debate, I think they share the "N" for >>>>>>>> Networks, >>>>>>>> and >>>>>>>> the 2nd "L" for Lossy. >>>>>>>> So the remaining point is the first L, meaning Low Power. >>>>>>>>=20 >>>>>>>> Low Power requirements is explicit in the ROLL charter and not >>>>>>>> mentioned >>>>>>>> at >>>>>>>> all in the MANET charter. >>>>>>>> Is the power efficiency consideration the big difference between R= OLL >>>>>>>> and >>>>>>>> MANET ? >>>>>>>>=20 >>>>>>>> C=E9dric. >>>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la pa= rt >>>>>>>> de >>>>>>>> Abdussalam Baryun >>>>>>>> Envoy=E9 : mercredi 1 ao=FBt 2012 09:22 >>>>>>>> =C0 : Henning Rogge >>>>>>>> Cc : roll; manet >>>>>>>> Objet : [Roll] Some LLNs are NOT MANETs >>>>>>>>=20 >>>>>>>> Hi Henning, >>>>>>>>=20 >>>>>>>> I am about to say many LLNs are NOT MANETs but it seems like the >>>>>>>> market >>>>>>>> or >>>>>>>> community will decide the outcome, but surly that some LLNs are NO= T >>>>>>>> MANETs. >>>>>>>>=20 >>>>>>>>> Could you state an example what would be considered a LLN but not= a >>>>>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>>>>=20 >>>>>>>> I not totally agree with that, because we need to be considering b= oth >>>>>>>> NETs >>>>>>>> use case and applicability in the vision of the different WGs (MAN= ET >>>>>>>> and >>>>>>>> ROLL). There are many examples we can find them in the [RFC2501] f= or >>>>>>>> MANETs >>>>>>>> characteristics and applicability, and for LLNs characteristics in >>>>>>>> [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs >>>>>>>> requirements. That is why I suggested before that >>>>>>>> OLSRv2 and AODVv2 should mention their applicability to LLN if the= y >>>>>>>> do. >>>>>>>> They >>>>>>>> just refer to RFC2501, but RFC2501 is OLD and does not mention LLN >>>>>>>> but >>>>>>>> describes the meaning. The authors of RFC2501 still not responded = to >>>>>>>> my >>>>>>>> update suggestions. >>>>>>>>=20 >>>>>>>> I understood from one discussion in MANET WG that few don't have t= ime >>>>>>>> to >>>>>>>> read many pages of documents, so that is why I suggested to have >>>>>>>> terminology >>>>>>>> I-D [1] as we have ROLL terminology [ROLL] . I also taken initiati= ve >>>>>>>> to >>>>>>>> make >>>>>>>> new draft of MANET subnet technologies which include only related >>>>>>>> LLNs >>>>>>>> [AB2]. >>>>>>>>=20 >>>>>>>> Therefore, I will add the definition for MANET and LLN into my >>>>>>>> manet-terminology draft [AB1] (propose that authors of [ROLL] defi= ne >>>>>>>> LLN >>>>>>>> more details) to assist discussions as it is proved now in the lis= t >>>>>>>> that >>>>>>>> there still is problems in definitions in MANET WG or in some I-D >>>>>>>> editorial >>>>>>>> content. >>>>>>>>=20 >>>>>>>> [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >>>>>>>> [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >>>>>>>> [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt >>>>>>>>=20 >>>>>>>> Best Wishes >>>>>>>>=20 >>>>>>>> Abdussalam Baryun >>>>>>>> University of Glamorgan, UK >>>>>>>>=20 >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>>>> On 7/31/12, Henning Rogge wrote: >>>>>>>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>>>>>>>> subject: Re: [manet] Discussing LOADng suggestions >>>>>>>>> wrote: >>>>>>>>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, >>>>>>>>>> but >>>>>>>>>> then changed its direction to MANET [3]. However, please note th= at >>>>>>>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. Th= at >>>>>>>>>> said, LOADng SHOULD specfy where is its limits. Then we can disc= uss >>>>>>>>>> adoption. >>>>>>>>>=20 >>>>>>>>> Could you state an example what would be considered a LLN but not= a >>>>>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>>>>>=20 >>>>>>>>> Henning Rogge >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Steven Hawkings about cosmic inflation: "An increase of billions = of >>>>>>>>> billions of percent in a tiny fraction of a second. Of course, th= at >>>>>>>>> was before the present government." >>>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Roll mailing list >>>>>>>> Roll@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>>=20 >>>>> ******************************************************************** >>>>> This email and any attachments are confidential to the intended >>>>> recipient and may also be privileged. If you are not the intended >>>>> recipient please delete it from your system and notify the sender. >>>>> You should not copy it or use it for any purpose nor disclose or >>>>> distribute its contents to any other person. >>>>> ******************************************************************** >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>=20 >>>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jvasseur@cisco.com Thu Aug 2 10:11:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A325221E803F for ; Thu, 2 Aug 2012 10:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.17 X-Spam-Level: X-Spam-Status: No, score=-10.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tKqWHeAy0u6 for ; Thu, 2 Aug 2012 10:11:32 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2C411E8097 for ; Thu, 2 Aug 2012 10:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=20970; q=dns/txt; s=iport; t=1343927491; x=1345137091; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=x9RmNg07Z2NNT1UII10M1QvXROKCc+94YgzA0/xfPGY=; b=X6rX/AYRrKg0kxF54am9fehXvd4w2dL0BokTRjBvQBLvht55XKaTRxzf AaNIlUBeRbTnBQCHC2dyPQpO+Kg6tGctk9+Po/GQ8qLUYaH3JDny2JRjT CHNWJmfqrq4X9lqUURK8eMbd1RTPAmQj6ztV+yqTrvUA/WCstpDNK+Y52 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcZAD60GlCtJXHA/2dsb2JhbABFgXUGAbcdgQeCIAEBAQMBAQEBDwFCFgMDCAUHBAIBCBEEAQEBJwchBgsUCQgCBA4FCQsHB4dcAwYGC5xjlnsNiU6KY2cFBQoHB4YCYAOTdIFTgRSJdoMdgWaCX4FWCQ X-IronPort-AV: E=Sophos;i="4.77,702,1336348800"; d="scan'208";a="107901345" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 02 Aug 2012 17:11:30 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q72HBU3T021579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 17:11:30 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.113]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 12:11:29 -0500 From: "JP Vasseur (jvasseur)" To: Ulrich Herberg Thread-Topic: [manet] Some LLNs are NOT MANETs Thread-Index: AQHNb+i2NIMVZDkBeEWaaQkwSTqYtJdFaAmAgAAPqoCAARpEgIAAcBqAgAAIYoCAAAWFAP//s+2h Date: Thu, 2 Aug 2012 17:11:29 +0000 Message-ID: References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> <8BA2751C-A4A5-46E8-9027-22A94045C3FE@cisco.com> , <36AD64C4-44DC-42CF-9CA6-09792BE218D2@herberg.name> In-Reply-To: <36AD64C4-44DC-42CF-9CA6-09792BE218D2@herberg.name> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.004 x-tm-as-result: No--64.899300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , "Stan Ratliff \(sratliff\)" , Abdussalam Baryun Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:11:34 -0000 Looking forward to the next revision of Dymo or Load with a clear statement= on the use cases and applicability according to Manet and Roll charters an= d guidance of the iesg JP Vasseur Cisco Fellow Sent from my iPhone On 2 ao=FBt 2012, at 09:44, "Ulrich Herberg" wrote: > Please wait until the next revision of LOADng. We will update the introdu= ction. Stay tuned! >=20 > Ulrich >=20 > On Aug 2, 2012, at 9:24, Abdussalam Baryun w= rote: >=20 >> Hi Stan, >>=20 >> We don't argue because we like it, but because we want to solve >> misunderstanding, if LOADng mentions LLNs without MANET, and some >> started to argue in meetings about that. LOAD is a protocol for LLN >> and MANET. >>=20 >>> On another note, and more to the list at-large (instead of just replyin= g to >>> Chris), we can argue this for days, or even weeks. But the truth of the >>> matter is that our charter references MANET networks, while the charter= for >>> ROLL references LLN's. It's pretty much just that simple. >>=20 >> To be more simple the Routing Area Charters should have clear >> definitions (so if MANET includes all LLNs so just mention that, if it >> doesn't then it may not include all), on the other hand our I-Ds and >> RFCs should specify applicability, no protocol can solve ALL problems >> of MANET, that is why we have reactive and proactive, but still if you >> read RFC3626, RFC3561, OLSRv2, AODVv2, they don't mention the >> different where reactive or proactive is better nor do they specify >> where their performance change is the large MANET scenarios. We have >> to go out of IETF publications and read IEEE publication to understand >> "Applicability", am I missing some thing, >>=20 >> I agree that the argument may take weeks, not because people like it, >> but simply because RFC2501 is not updated to include LLNs and other >> issues, >>=20 >> AB >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> On 8/2/12, Stan Ratliff (sratliff) wrote: >>> Chris, >>>=20 >>> On Aug 2, 2012, at 5:12 AM, Dearlove, Christopher (UK) wrote: >>>=20 >>>> I would subtly differently emphasise your point. (I think we are basic= ally >>>> in agreement.) I would view ad hoc networks (I'm going to avoid the MA= NET >>>> term as it's overloaded here) as a broad area. LLNs are a specialist >>>> sub-area within that area. The MANET WG in principle covers the whole = of >>>> the area, and most of its work has created protocols that can cover mo= st >>>> of that area. However where there are specialised, and in particular m= ore >>>> limited requirement, sub-areas, specialised protocols may make a bette= r >>>> trade-off (typically be simpler). And you have emphasised one of the k= ey >>>> differences, the differing traffic pattern, and in particular the domi= nant >>>> role of an egress (or ingress, but egress is often more important) >>>> gateway rather than peer to peer communications (which in an LLN are >>>> typically either absent, or rare enough that the otherwise inefficient= go >>>> via gateway, possibly optimised to clip off reused links, is acceptabl= e). >>>>=20 >>>> (This bit may or may not be in agreement with Stan.) Note that I'm not >>>> saying that you can't use e.g. OLSRv2 in an LLN, but that if you have = more >>>> limited/specialised requirements you may be able to do better. Nor am = I >>>> saying RPL or LOADng is (or is not) that better solution, I've studied >>>> neither in enough detail to have a view. >>>>=20 >>>=20 >>> No, we agree=85 As a mentor of mine once said, "You can do anything you= 're big >>> enough to try"=85 ;-) ;-) The definitions we're using (MANET and LLN) a= re >>> somewhat vague, and somewhat overlapping. And any specific network's >>> environment could well lead to multiple choices for a routing protocol. >>>=20 >>> On another note, and more to the list at-large (instead of just replyin= g to >>> Chris), we can argue this for days, or even weeks. But the truth of the >>> matter is that our charter references MANET networks, while the charter= for >>> ROLL references LLN's. It's pretty much just that simple. >>>=20 >>> Regards, >>> Stan >>>=20 >>>=20 >>>> -- >>>> Christopher Dearlove >>>> Senior Principal Engineer, Communications Group >>>> Communications, Networks and Image Analysis Capability >>>> BAE Systems Advanced Technology Centre >>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>=20 >>>> BAE Systems (Operations) Limited >>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cen= tre, >>>> Farnborough, Hants, GU14 6YU, UK >>>> Registered in England & Wales No: 1996687 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] >>>> Sent: 01 August 2012 17:23 >>>> To: Dearlove, Christopher (UK) >>>> Cc: Abdussalam Baryun; C Chauvenet; manet >>>> Subject: Re: [manet] Some LLNs are NOT MANETs >>>>=20 >>>> ----------------------! WARNING ! ---------------------- >>>> This message originates from outside our organisation, >>>> either from an external partner or from the internet. >>>> Keep this in mind if you answer this message. >>>> Follow the 'Report Suspicious Emails' link on IT matters >>>> for instructions on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>>=20 >>>> Precisely, Chris. >>>>=20 >>>> I've come to view MANETs more and more in the terms of an "opportunist= ic >>>> network". By that, I mean a network with a fairly large amount of >>>> dynamism, and also a network that contains heterogeneity of links (e.g= ., >>>> different radio types, and/or some wired portions). The challenge of t= hese >>>> networks is to opportunistically (and maximally) use the resources >>>> available to it at any point in time. >>>>=20 >>>> And at least for me (and I know this will draw some fire in return), >>>> another distinction in MANET as opposed to LLN is a greater requiremen= t >>>> for peer-to-peer (node-to-node) communication, From what I've seen of = LLN >>>> deployments (and I'm no expert), they tend to have more of a "multiple >>>> source/single sink" model for the data flow. >>>>=20 >>>> Again, just one opinion. >>>>=20 >>>> Regards, >>>> Stan >>>>=20 >>>> On Aug 1, 2012, at 11:26 AM, Dearlove, Christopher (UK) wrote: >>>>=20 >>>>> The statement that MANETs refers only to networks with physical mobil= ity >>>>> is simply false. While the expansion of the acronym might suggest tha= t, >>>>> in fact MANET has become a term of art, and that art includes many >>>>> networks with some or all nodes that are not physically moving. >>>>>=20 >>>>> -- >>>>> Christopher Dearlove >>>>> Senior Principal Engineer, Communications Group >>>>> Communications, Networks and Image Analysis Capability >>>>> BAE Systems Advanced Technology Centre >>>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>>>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>>>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>>>=20 >>>>> BAE Systems (Operations) Limited >>>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>>>> Centre, Farnborough, Hants, GU14 6YU, UK >>>>> Registered in England & Wales No: 1996687 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behal= f Of >>>>> Abdussalam Baryun >>>>> Sent: 01 August 2012 14:21 >>>>> To: C Chauvenet >>>>> Cc: manet >>>>> Subject: Re: [manet] Some LLNs are NOT MANETs >>>>>=20 >>>>> ----------------------! WARNING ! ---------------------- >>>>> This message originates from outside our organisation, >>>>> either from an external partner or from the internet. >>>>> Keep this in mind if you answer this message. >>>>> Follow the 'Report Suspicious Emails' link on IT matters >>>>> for instructions on reporting suspicious email messages. >>>>> -------------------------------------------------------- >>>>>=20 >>>>> Hi C=E9dric, >>>>>=20 >>>>> Ok we can discuss efficiently when we read the documents (production >>>>> of such WG)as you agreed. >>>>>=20 >>>>>> When you say "IMHO, as long we have a ROLL WG in IETF we need to >>>>>> forward >>>>>> work to it which has no mobility behavior", do you mean that the >>>>>> difference >>>>>> between ROLL and MANET is limited to mobility considerations ? >>>>>=20 >>>>> *Mobility* It is the mostly difference clearly spoted between the >>>>> documents produced by the both WGs, also the name MANET starts with >>>>> Mobile, the word mobile is not equal to change/dynamic. So MANET >>>>> refers to mobile node or mobile network, which means location change >>>>> *NOT* topology change/dynamic. In the old days there was no ROLL WG s= o >>>>> MANET WG was doing the job. >>>>>=20 >>>>>>=20 >>>>>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and >>>>>> RFC5867 >>>>>> all include the usual IoT constraints : Memory, Processing, Power, >>>>>> Battery, >>>>>> Cost and Size of device. >>>>>> RFC5673 does not mention explicitly processing and size constraints, >>>>>> but >>>>>> mention all the others. >>>>>>=20 >>>>>=20 >>>>> Ok, >>>>>=20 >>>>>> RFC 2501 speak about energy and power, as you previously mentioned, = but >>>>>> does >>>>>> not say something on the following constraints : Memory, Processing= , >>>>>> Cost >>>>>> and Size. >>>>>=20 >>>>> Yes your right, but be careful RFC2501 does not exclude thoes >>>>> constraints either. However, if the MANET network has some nodes with >>>>> constraints but clearly mobility is the main constraint. >>>>>=20 >>>>>>=20 >>>>>> Do you think that these constraints are in the MANET scope ? >>>>>> I guess that they may be (obviously for Cost), but not in the same o= rder >>>>>> of >>>>>> magnitude as the type of devices described in the requirements RFC o= f >>>>>> ROLL. >>>>>=20 >>>>> Really don't mind either way for MANET WG, and will think that the WG >>>>> community wants it in between In-Scope and Out-Scope, that may be >>>>> strange but seems that is what is happening as I read documents. Out >>>>> of IETF, MANET is mostly understood as mobile nodes connecting, not >>>>> LLNs. >>>>>=20 >>>>> Overall, IMHO, in the end it is the decision of the IETF community to >>>>> decide of any new idea or any I-D acceptance/adoption, but for the WG >>>>> it MAY take over a WORK as an IETF I-D, but it may not be successful >>>>> to convince the IETF community to continue the work or make it become >>>>> a RFC, we always have to see through to make the work efforts flow >>>>> successfully. We do not forget that many participants work in both >>>>> WGs. >>>>>=20 >>>>> Regards >>>>> Abdussalam >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> On 8/1/12, C Chauvenet wrote: >>>>>> Hi, >>>>>>=20 >>>>>> Thank you for your answer, >>>>>>=20 >>>>>> See inline. >>>>>>=20 >>>>>> Le 1 ao=FBt 2012 =E0 13:41, Abdussalam Baryun a =E9crit : >>>>>>=20 >>>>>>> Hi C=E9dric, >>>>>>>=20 >>>>>>> I think the RFC2501 is more important than the WG charter, because = the >>>>>>> charter MAY change but RFCs never changes (only can be updated, >>>>>>> obsoleted or replaced). >>>>>>=20 >>>>>> Good Point, 100% agree. >>>>>>=20 >>>>>>> So far now all MANET-protocols are refering to >>>>>>> RFC2501 which is good and SHOULD continue, and I like this referenc= ing >>>>>>> to documents (even if they are old or expired) not referencing to >>>>>>> charters, because for example, if in a journal paper we reference t= o >>>>>>> the charter of MANET WG or ROLL WG the information is not solid lik= e >>>>>>> if you reference a published document (publisher date), but still w= e >>>>>>> can reference the charter as web reference sited date. >>>>>>>=20 >>>>>>> I read some paper that reference sited web documents but they may b= e >>>>>>> not valid and cannot be read for some reason. Therefore, IMHO, we n= eed >>>>>>> to stick to the following document to make a right decision in >>>>>>> definitions: >>>>>>>=20 >>>>>>> 1) [RFC2501] for MANETs. (published in 1999) >>>>>>> 2) [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] for LLNs. >>>>>>> (published in 2009) >>>>>>=20 >>>>>> I think they are good references to build some arguments into this >>>>>> discussion. >>>>>>=20 >>>>>>>=20 >>>>>>> Low power was indicated in RFC2501 in section 5.1 as >>>>>> constraints> and also the word *sink*, in page 7 you read >>>>>> for energy conservation>. IMHO, as long we have a ROLL WG in IETF w= e >>>>>>> need to forward work to it which has no mobility behavior. Delegati= on >>>>>>> will help make work flowing and more focused. >>>>>>=20 >>>>>> When you say "IMHO, as long we have a ROLL WG in IETF we need to >>>>>> forward >>>>>> work to it which has no mobility behavior", do you mean that the >>>>>> difference >>>>>> between ROLL and MANET is limited to mobility considerations ? >>>>>>=20 >>>>>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and >>>>>> RFC5867 >>>>>> all include the usual IoT constraints : Memory, Processing, Power, >>>>>> Battery, >>>>>> Cost and Size of device. >>>>>> RFC5673 does not mention explicitly processing and size constraints, >>>>>> but >>>>>> mention all the others. >>>>>>=20 >>>>>> RFC 2501 speak about energy and power, as you previously mentioned, = but >>>>>> does >>>>>> not say something on the following constraints : Memory, Processing= , >>>>>> Cost >>>>>> and Size. >>>>>>=20 >>>>>> Do you think that these constraints are in the MANET scope ? >>>>>> I guess that they may be (obviously for Cost), but not in the same o= rder >>>>>> of >>>>>> magnitude as the type of devices described in the requirements RFC o= f >>>>>> ROLL. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> C=E9dric. >>>>>>=20 >>>>>>>=20 >>>>>>> Regards >>>>>>> AB >>>>>>> =3D=3D=3D=3D=3D=3D=3D >>>>>>>=20 >>>>>>> On 8/1/12, C Chauvenet wrote: >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> This is an interesting discussion. >>>>>>>>=20 >>>>>>>> My understanding is that both MANET and ROLL considers lossy/dynam= ic >>>>>>>> links >>>>>>>> in the way described in the MANET charter : "static and dynamic >>>>>>>> topologies >>>>>>>> with increased dynamics due to node motion or other factors." I al= so >>>>>>>> agree >>>>>>>> that dynamicity of links is not hard wired to node mobility. >>>>>>>>=20 >>>>>>>> So, in the LLN Vs MANET debate, I think they share the "N" for >>>>>>>> Networks, >>>>>>>> and >>>>>>>> the 2nd "L" for Lossy. >>>>>>>> So the remaining point is the first L, meaning Low Power. >>>>>>>>=20 >>>>>>>> Low Power requirements is explicit in the ROLL charter and not >>>>>>>> mentioned >>>>>>>> at >>>>>>>> all in the MANET charter. >>>>>>>> Is the power efficiency consideration the big difference between R= OLL >>>>>>>> and >>>>>>>> MANET ? >>>>>>>>=20 >>>>>>>> C=E9dric. >>>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la pa= rt >>>>>>>> de >>>>>>>> Abdussalam Baryun >>>>>>>> Envoy=E9 : mercredi 1 ao=FBt 2012 09:22 >>>>>>>> =C0 : Henning Rogge >>>>>>>> Cc : roll; manet >>>>>>>> Objet : [Roll] Some LLNs are NOT MANETs >>>>>>>>=20 >>>>>>>> Hi Henning, >>>>>>>>=20 >>>>>>>> I am about to say many LLNs are NOT MANETs but it seems like the >>>>>>>> market >>>>>>>> or >>>>>>>> community will decide the outcome, but surly that some LLNs are NO= T >>>>>>>> MANETs. >>>>>>>>=20 >>>>>>>>> Could you state an example what would be considered a LLN but not= a >>>>>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>>>>=20 >>>>>>>> I not totally agree with that, because we need to be considering b= oth >>>>>>>> NETs >>>>>>>> use case and applicability in the vision of the different WGs (MAN= ET >>>>>>>> and >>>>>>>> ROLL). There are many examples we can find them in the [RFC2501] f= or >>>>>>>> MANETs >>>>>>>> characteristics and applicability, and for LLNs characteristics in >>>>>>>> [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs >>>>>>>> requirements. That is why I suggested before that >>>>>>>> OLSRv2 and AODVv2 should mention their applicability to LLN if the= y >>>>>>>> do. >>>>>>>> They >>>>>>>> just refer to RFC2501, but RFC2501 is OLD and does not mention LLN >>>>>>>> but >>>>>>>> describes the meaning. The authors of RFC2501 still not responded = to >>>>>>>> my >>>>>>>> update suggestions. >>>>>>>>=20 >>>>>>>> I understood from one discussion in MANET WG that few don't have t= ime >>>>>>>> to >>>>>>>> read many pages of documents, so that is why I suggested to have >>>>>>>> terminology >>>>>>>> I-D [1] as we have ROLL terminology [ROLL] . I also taken initiati= ve >>>>>>>> to >>>>>>>> make >>>>>>>> new draft of MANET subnet technologies which include only related >>>>>>>> LLNs >>>>>>>> [AB2]. >>>>>>>>=20 >>>>>>>> Therefore, I will add the definition for MANET and LLN into my >>>>>>>> manet-terminology draft [AB1] (propose that authors of [ROLL] defi= ne >>>>>>>> LLN >>>>>>>> more details) to assist discussions as it is proved now in the lis= t >>>>>>>> that >>>>>>>> there still is problems in definitions in MANET WG or in some I-D >>>>>>>> editorial >>>>>>>> content. >>>>>>>>=20 >>>>>>>> [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >>>>>>>> [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >>>>>>>> [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt >>>>>>>>=20 >>>>>>>> Best Wishes >>>>>>>>=20 >>>>>>>> Abdussalam Baryun >>>>>>>> University of Glamorgan, UK >>>>>>>>=20 >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>>>> On 7/31/12, Henning Rogge wrote: >>>>>>>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>>>>>>>> subject: Re: [manet] Discussing LOADng suggestions >>>>>>>>> wrote: >>>>>>>>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, >>>>>>>>>> but >>>>>>>>>> then changed its direction to MANET [3]. However, please note th= at >>>>>>>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. Th= at >>>>>>>>>> said, LOADng SHOULD specfy where is its limits. Then we can disc= uss >>>>>>>>>> adoption. >>>>>>>>>=20 >>>>>>>>> Could you state an example what would be considered a LLN but not= a >>>>>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>>>>>=20 >>>>>>>>> Henning Rogge >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Steven Hawkings about cosmic inflation: "An increase of billions = of >>>>>>>>> billions of percent in a tiny fraction of a second. Of course, th= at >>>>>>>>> was before the present government." >>>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Roll mailing list >>>>>>>> Roll@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>>=20 >>>>> ******************************************************************** >>>>> This email and any attachments are confidential to the intended >>>>> recipient and may also be privileged. If you are not the intended >>>>> recipient please delete it from your system and notify the sender. >>>>> You should not copy it or use it for any purpose nor disclose or >>>>> distribute its contents to any other person. >>>>> ******************************************************************** >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>=20 >>>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Thu Aug 2 10:40:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A95611E8196 for ; Thu, 2 Aug 2012 10:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwJ3EtdeXhn8 for ; Thu, 2 Aug 2012 10:40:44 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 80A3911E8195 for ; Thu, 2 Aug 2012 10:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=19788; q=dns/txt; s=iport; t=1343929244; x=1345138844; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9bXY/MjUq26UCDIje5earORcntSS8NL8dgh5vgO+h1E=; b=M/26gTubdOgpBZoPe5RyZ4cIB1BWm1FYwCKhFiwCUvQDgJDsfadgC5WL EQbUptg77tL2tf5Aao5Qjh58YRYvX5FKeklpQvA7yUWEwH7HhvTpXb1n1 uYDJR0VCqHFRzX5dce175uLyYx1QTdpOqG1ByWzUJaZbzanmtAh6zqao9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFa7GlCtJV2Y/2dsb2JhbABFuRmBB4IgAQEBAwEBAQEPAUIWAwMIBQcEAgEIEQQBAQEnByEGCxQJCAIEDgUJCwcHh1wDBgYLnGKWeQ2JTopjZwUFCgcHhgJgA4gYi1yBU4EUiXaDHYFmgl+BVgk X-IronPort-AV: E=Sophos;i="4.77,702,1336348800"; d="scan'208";a="107910646" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 02 Aug 2012 17:40:43 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q72HehaJ023322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 17:40:43 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.180]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 12:40:42 -0500 From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] Some LLNs are NOT MANETs Thread-Index: AQHNb+i2NIMVZDkBeEWaaQkwSTqYtJdFaAmAgAAPqoCAARpEgIAAcBqAgAAJ4QCAABPuAA== Date: Thu, 2 Aug 2012 17:40:42 +0000 Message-ID: <394D7DEB-B148-4129-ADFA-47CEA81181E1@cisco.com> References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> <8BA2751C-A4A5-46E8-9027-22A94045C3FE@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.249.67] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.004 x-tm-as-result: No--56.204200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <182249B4AF43964796AEB1A47AA84D67@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:40:46 -0000 Chris,=20 As you did earlier, I'd slightly, subtly re-empasise what you said:=20 A solution just intended for LLN's, or which that is the dominant case for,= belongs in ROLL (no "unless" clause). Regards, Stan On Aug 2, 2012, at 12:29 PM, Dearlove, Christopher (UK) wrote: > Taking your last point on what charters say, I would interpret that as: > - A solution just intended for LLNs, or which that is the dominant case f= or, belongs to ROLL (unless they don't want it). > - A wide ranging solution (which could include LLNs as a special case) be= longs in MANET. > - A specialist solution that is not an LLN specialist solution is permiss= ible in MANET, though a specialised WG could be created for it. >=20 > But all subject to the overriding condition there has to be a reason to d= o it, not just a protocol with no user base looking for a home. And of cour= se I'm just talking about ad hoc routing protocols (by which I mean, roughl= y speaking, decentralised multi-hop routing in dynamic or otherwise unknown= characteristic networks) or closely related things here. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 > Sent: 02 August 2012 16:54 > To: Dearlove, Christopher (UK) > Cc: Abdussalam Baryun; C Chauvenet; manet > Subject: Re: [manet] Some LLNs are NOT MANETs >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Chris,=20 >=20 > On Aug 2, 2012, at 5:12 AM, Dearlove, Christopher (UK) wrote: >=20 >> I would subtly differently emphasise your point. (I think we are basical= ly in agreement.) I would view ad hoc networks (I'm going to avoid the MANE= T term as it's overloaded here) as a broad area. LLNs are a specialist sub-= area within that area. The MANET WG in principle covers the whole of the ar= ea, and most of its work has created protocols that can cover most of that = area. However where there are specialised, and in particular more limited r= equirement, sub-areas, specialised protocols may make a better trade-off (t= ypically be simpler). And you have emphasised one of the key differences, t= he differing traffic pattern, and in particular the dominant role of an egr= ess (or ingress, but egress is often more important) gateway rather than p= eer to peer communications (which in an LLN are typically either absent, or= rare enough that the otherwise inefficient go via gateway, possibly optimi= sed to clip off reused links, is acceptable). >>=20 >> (This bit may or may not be in agreement with Stan.) Note that I'm not s= aying that you can't use e.g. OLSRv2 in an LLN, but that if you have more l= imited/specialised requirements you may be able to do better. Nor am I sayi= ng RPL or LOADng is (or is not) that better solution, I've studied neither = in enough detail to have a view. >>=20 >=20 > No, we agree. As a mentor of mine once said, "You can do anything you're = big enough to try". ;-) ;-) The definitions we're using (MANET and LLN) are= somewhat vague, and somewhat overlapping. And any specific network's envir= onment could well lead to multiple choices for a routing protocol.=20 >=20 > On another note, and more to the list at-large (instead of just replying = to Chris), we can argue this for days, or even weeks. But the truth of the = matter is that our charter references MANET networks, while the charter for= ROLL references LLN's. It's pretty much just that simple.=20 >=20 > Regards, > Stan >=20 >=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >> Sent: 01 August 2012 17:23 >> To: Dearlove, Christopher (UK) >> Cc: Abdussalam Baryun; C Chauvenet; manet >> Subject: Re: [manet] Some LLNs are NOT MANETs >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> Precisely, Chris.=20 >>=20 >> I've come to view MANETs more and more in the terms of an "opportunistic= network". By that, I mean a network with a fairly large amount of dynamism= , and also a network that contains heterogeneity of links (e.g., different = radio types, and/or some wired portions). The challenge of these networks i= s to opportunistically (and maximally) use the resources available to it at= any point in time.=20 >>=20 >> And at least for me (and I know this will draw some fire in return), ano= ther distinction in MANET as opposed to LLN is a greater requirement for pe= er-to-peer (node-to-node) communication, From what I've seen of LLN deploym= ents (and I'm no expert), they tend to have more of a "multiple source/sing= le sink" model for the data flow. >>=20 >> Again, just one opinion.=20 >>=20 >> Regards, >> Stan >>=20 >> On Aug 1, 2012, at 11:26 AM, Dearlove, Christopher (UK) wrote: >>=20 >>> The statement that MANETs refers only to networks with physical mobilit= y is simply false. While the expansion of the acronym might suggest that, i= n fact MANET has become a term of art, and that art includes many networks = with some or all nodes that are not physically moving. >>>=20 >>> --=20 >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cent= re, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Abdussalam Baryun >>> Sent: 01 August 2012 14:21 >>> To: C Chauvenet >>> Cc: manet >>> Subject: Re: [manet] Some LLNs are NOT MANETs >>>=20 >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>>=20 >>> Hi C=E9dric, >>>=20 >>> Ok we can discuss efficiently when we read the documents (production >>> of such WG)as you agreed. >>>=20 >>>> When you say "IMHO, as long we have a ROLL WG in IETF we need to forwa= rd >>>> work to it which has no mobility behavior", do you mean that the diffe= rence >>>> between ROLL and MANET is limited to mobility considerations ? >>>=20 >>> *Mobility* It is the mostly difference clearly spoted between the >>> documents produced by the both WGs, also the name MANET starts with >>> Mobile, the word mobile is not equal to change/dynamic. So MANET >>> refers to mobile node or mobile network, which means location change >>> *NOT* topology change/dynamic. In the old days there was no ROLL WG so >>> MANET WG was doing the job. >>>=20 >>>>=20 >>>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC5= 867 >>>> all include the usual IoT constraints : Memory, Processing, Power, Bat= tery, >>>> Cost and Size of device. >>>> RFC5673 does not mention explicitly processing and size constraints, b= ut >>>> mention all the others. >>>>=20 >>>=20 >>> Ok, >>>=20 >>>> RFC 2501 speak about energy and power, as you previously mentioned, bu= t does >>>> not say something on the following constraints : Memory, Processing, = Cost >>>> and Size. >>>=20 >>> Yes your right, but be careful RFC2501 does not exclude thoes >>> constraints either. However, if the MANET network has some nodes with >>> constraints but clearly mobility is the main constraint. >>>=20 >>>>=20 >>>> Do you think that these constraints are in the MANET scope ? >>>> I guess that they may be (obviously for Cost), but not in the same ord= er of >>>> magnitude as the type of devices described in the requirements RFC of = ROLL. >>>=20 >>> Really don't mind either way for MANET WG, and will think that the WG >>> community wants it in between In-Scope and Out-Scope, that may be >>> strange but seems that is what is happening as I read documents. Out >>> of IETF, MANET is mostly understood as mobile nodes connecting, not >>> LLNs. >>>=20 >>> Overall, IMHO, in the end it is the decision of the IETF community to >>> decide of any new idea or any I-D acceptance/adoption, but for the WG >>> it MAY take over a WORK as an IETF I-D, but it may not be successful >>> to convince the IETF community to continue the work or make it become >>> a RFC, we always have to see through to make the work efforts flow >>> successfully. We do not forget that many participants work in both >>> WGs. >>>=20 >>> Regards >>> Abdussalam >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> On 8/1/12, C Chauvenet wrote: >>>> Hi, >>>>=20 >>>> Thank you for your answer, >>>>=20 >>>> See inline. >>>>=20 >>>> Le 1 ao=FBt 2012 =E0 13:41, Abdussalam Baryun a =E9crit : >>>>=20 >>>>> Hi C=E9dric, >>>>>=20 >>>>> I think the RFC2501 is more important than the WG charter, because th= e >>>>> charter MAY change but RFCs never changes (only can be updated, >>>>> obsoleted or replaced). >>>>=20 >>>> Good Point, 100% agree. >>>>=20 >>>>> So far now all MANET-protocols are refering to >>>>> RFC2501 which is good and SHOULD continue, and I like this referencin= g >>>>> to documents (even if they are old or expired) not referencing to >>>>> charters, because for example, if in a journal paper we reference to >>>>> the charter of MANET WG or ROLL WG the information is not solid like >>>>> if you reference a published document (publisher date), but still we >>>>> can reference the charter as web reference sited date. >>>>>=20 >>>>> I read some paper that reference sited web documents but they may be >>>>> not valid and cannot be read for some reason. Therefore, IMHO, we nee= d >>>>> to stick to the following document to make a right decision in >>>>> definitions: >>>>>=20 >>>>> 1) [RFC2501] for MANETs. (published in 1999) >>>>> 2) [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] for LLNs. >>>>> (published in 2009) >>>>=20 >>>> I think they are good references to build some arguments into this >>>> discussion. >>>>=20 >>>>>=20 >>>>> Low power was indicated in RFC2501 in section 5.1 as >>>> constraints> and also the word *sink*, in page 7 you read >>>> for energy conservation>. IMHO, as long we have a ROLL WG in IETF we >>>>> need to forward work to it which has no mobility behavior. Delegation >>>>> will help make work flowing and more focused. >>>>=20 >>>> When you say "IMHO, as long we have a ROLL WG in IETF we need to forwa= rd >>>> work to it which has no mobility behavior", do you mean that the diffe= rence >>>> between ROLL and MANET is limited to mobility considerations ? >>>>=20 >>>> Based on the docs you mentioned, I see that RFC5548, RFC5826, and RFC5= 867 >>>> all include the usual IoT constraints : Memory, Processing, Power, Bat= tery, >>>> Cost and Size of device. >>>> RFC5673 does not mention explicitly processing and size constraints, b= ut >>>> mention all the others. >>>>=20 >>>> RFC 2501 speak about energy and power, as you previously mentioned, bu= t does >>>> not say something on the following constraints : Memory, Processing, = Cost >>>> and Size. >>>>=20 >>>> Do you think that these constraints are in the MANET scope ? >>>> I guess that they may be (obviously for Cost), but not in the same ord= er of >>>> magnitude as the type of devices described in the requirements RFC of = ROLL. >>>>=20 >>>> Regards, >>>>=20 >>>> C=E9dric. >>>>=20 >>>>>=20 >>>>> Regards >>>>> AB >>>>> =3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>>> On 8/1/12, C Chauvenet wrote: >>>>>> Hi, >>>>>>=20 >>>>>> This is an interesting discussion. >>>>>>=20 >>>>>> My understanding is that both MANET and ROLL considers lossy/dynamic >>>>>> links >>>>>> in the way described in the MANET charter : "static and dynamic >>>>>> topologies >>>>>> with increased dynamics due to node motion or other factors." I also >>>>>> agree >>>>>> that dynamicity of links is not hard wired to node mobility. >>>>>>=20 >>>>>> So, in the LLN Vs MANET debate, I think they share the "N" for Netwo= rks, >>>>>> and >>>>>> the 2nd "L" for Lossy. >>>>>> So the remaining point is the first L, meaning Low Power. >>>>>>=20 >>>>>> Low Power requirements is explicit in the ROLL charter and not menti= oned >>>>>> at >>>>>> all in the MANET charter. >>>>>> Is the power efficiency consideration the big difference between ROL= L >>>>>> and >>>>>> MANET ? >>>>>>=20 >>>>>> C=E9dric. >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part= de >>>>>> Abdussalam Baryun >>>>>> Envoy=E9 : mercredi 1 ao=FBt 2012 09:22 >>>>>> =C0 : Henning Rogge >>>>>> Cc : roll; manet >>>>>> Objet : [Roll] Some LLNs are NOT MANETs >>>>>>=20 >>>>>> Hi Henning, >>>>>>=20 >>>>>> I am about to say many LLNs are NOT MANETs but it seems like the mar= ket >>>>>> or >>>>>> community will decide the outcome, but surly that some LLNs are NOT >>>>>> MANETs. >>>>>>=20 >>>>>>> Could you state an example what would be considered a LLN but not a >>>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>>=20 >>>>>> I not totally agree with that, because we need to be considering bot= h >>>>>> NETs >>>>>> use case and applicability in the vision of the different WGs (MANET= and >>>>>> ROLL). There are many examples we can find them in the [RFC2501] for >>>>>> MANETs >>>>>> characteristics and applicability, and for LLNs characteristics in >>>>>> [RFC5548], [RFC5673], [RFCRFC5826], and [RFC5867] including LLNs >>>>>> requirements. That is why I suggested before that >>>>>> OLSRv2 and AODVv2 should mention their applicability to LLN if they = do. >>>>>> They >>>>>> just refer to RFC2501, but RFC2501 is OLD and does not mention LLN b= ut >>>>>> describes the meaning. The authors of RFC2501 still not responded to= my >>>>>> update suggestions. >>>>>>=20 >>>>>> I understood from one discussion in MANET WG that few don't have tim= e to >>>>>> read many pages of documents, so that is why I suggested to have >>>>>> terminology >>>>>> I-D [1] as we have ROLL terminology [ROLL] . I also taken initiative= to >>>>>> make >>>>>> new draft of MANET subnet technologies which include only related L= LNs >>>>>> [AB2]. >>>>>>=20 >>>>>> Therefore, I will add the definition for MANET and LLN into my >>>>>> manet-terminology draft [AB1] (propose that authors of [ROLL] define= LLN >>>>>> more details) to assist discussions as it is proved now in the list = that >>>>>> there still is problems in definitions in MANET WG or in some I-D >>>>>> editorial >>>>>> content. >>>>>>=20 >>>>>> [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt >>>>>> [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt >>>>>> [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt >>>>>>=20 >>>>>> Best Wishes >>>>>>=20 >>>>>> Abdussalam Baryun >>>>>> University of Glamorgan, UK >>>>>>=20 >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>> On 7/31/12, Henning Rogge wrote: >>>>>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>>>>>> subject: Re: [manet] Discussing LOADng suggestions >>>>>>> wrote: >>>>>>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, b= ut >>>>>>>> then changed its direction to MANET [3]. However, please note that >>>>>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >>>>>>>> said, LOADng SHOULD specfy where is its limits. Then we can discus= s >>>>>>>> adoption. >>>>>>>=20 >>>>>>> Could you state an example what would be considered a LLN but not a >>>>>>> MANET. I normally consider LLNs a subset of what we call MANETs. >>>>>>>=20 >>>>>>> Henning Rogge >>>>>>>=20 >>>>>>> -- >>>>>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>>>>> billions of percent in a tiny fraction of a second. Of course, that >>>>>>> was before the present government." >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> Roll mailing list >>>>>> Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ******************************************************************** >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >=20 >=20 From abdussalambaryun@gmail.com Fri Aug 3 07:54:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68FED21F8DC7 for ; Fri, 3 Aug 2012 07:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1jpYzEYWhBI for ; Fri, 3 Aug 2012 07:54:16 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BEC4221F8DDD for ; Fri, 3 Aug 2012 07:54:16 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so889130vbb.31 for ; Fri, 03 Aug 2012 07:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YCD+CaYjITv3T1WTzfya05ZJVapSbJwchCGUCui5k1g=; b=ovswxg9n8P3lFrOQmk5GpBxwtnMQKzMaN0sJ0l316OhfMgbVYOXHN2Icdd9Prsm8II ZYkLuFEg3NzYF095RlQ7jIKFsASyJauAEp+ta8Mm6l7dSl/TQx7VVHNFw+8M87biDycb T7MoE4AFUWQ4+T86zRW9w457CYlV9Aw9yDHE/IL/DQe8OqsuFEA3zP7CoGVJy7bmgMpb SxGg4FKOxb+iFpsDHiAC922QrICdfa2sVDHi2VTmQ0QbwblNXHMY0T0QkNg/evpt3xcZ JMwliX2Hc6/AbkXsYs5h+hEB9f2zxUn4brFFq0wFi4BfqdyHSy4oERskkHsDcmeSCZuK DyjA== MIME-Version: 1.0 Received: by 10.220.149.148 with SMTP id t20mr1553478vcv.12.1344005656236; Fri, 03 Aug 2012 07:54:16 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Fri, 3 Aug 2012 07:54:16 -0700 (PDT) In-Reply-To: References: <97B69B30E0EF244B940B65EA541E3F2D022E471E@DBXPRD0510MB395.eurprd05.prod.outlook.com> <1E474CEB-4BFE-4299-B450-C7F3510148A8@watteco.com> Date: Fri, 3 Aug 2012 15:54:16 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=f46d04374987b753b204c65db311 Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Some LLNs are NOT MANETs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:54:17 -0000 --f46d04374987b753b204c65db311 Content-Type: text/plain; charset=ISO-8859-1 +1 I support the manet wg charter mentions some/all points as below, On 8/2/2012 9:29 AM, Dearlove, Christopher (UK) wrote: Taking your last point on what charters say, I would interpret that as: - A solution just intended for LLNs, or which that is the dominant case for, belongs to ROLL (unless they don't want it). - A wide ranging solution (which could include LLNs as a special case) belongs in MANET. - A specialist solution that is not an LLN specialist solution is permissible in MANET, though a specialised WG could be created for it. But all subject to the overriding condition there has to be a reason to do it, not just a protocol with no user base looking for a home. And of course I'm just talking about ad hoc routing protocols (by which I mean, roughly speaking, decentralised multi-hop routing in dynamic or otherwise unknown characteristic networks) or closely related things here. --f46d04374987b753b204c65db311 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1
=A0
I support the manet wg charter mentions=A0some/all points as below,
=A0
On 8/2/2012 9:29 AM, Dearlove, Christopher (UK) wrote:
Taking your last point on what charters=
 say, I would interpret that as:
- A solution just intended for LLNs, or which that is the dominant case for=
, belongs to ROLL (unless they don't want it).
- A wide ranging solution (which could include LLNs as a special case) belo=
ngs in MANET.
- A specialist solution that is not an LLN specialist solution is permissib=
le in MANET, though a specialised WG could be created for it.

But all subject to the overriding condition there has to be a reason to do =
it, not just a protocol with no user base looking for a home. And of course=
 I'm just talking about ad hoc routing protocols (by which I mean, roug=
hly speaking, decentralised multi-hop routing in dynamic or otherwise unkno=
wn characteristic networks) or closely related things here.
--f46d04374987b753b204c65db311-- From abdussalambaryun@gmail.com Sat Aug 4 02:24:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EBE21F878E for ; Sat, 4 Aug 2012 02:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9n8KXS56mSs for ; Sat, 4 Aug 2012 02:24:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E032021F8711 for ; Sat, 4 Aug 2012 02:24:29 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1663670vbb.31 for ; Sat, 04 Aug 2012 02:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5N8yxD7Qm7yP6/Z2OZrn5ePe+LelXBXbMmnvfUvsgng=; b=q+j0Lfz/VKz2Ry+zF6L5JbcJVjIIkYZI/OpbDNSqR3A6B8whaMMwNkzdTMdBoCJA/i VZtOiKWkmJloSVersRxemS2aGTOkxNLPb0dAfdt3nutcU+56azGfi3OOnlxntiBQBrnr 494J+NQU5xZ616Jh4RU05ttVnB3xNJ3vBmSebJcXqs4gXJEG0UsAeuSMaLic1DLLHu4j 7dQJwEurxdjgEMSJ12xW0aHHwhzkQqs26iVXnm3Grzj9btqlnTb9ha7wfEcyzVoXO+Sl NJhtyNQlhECfc6n+Hg9lXiKz8M2vcvaFBSBRR+hR5xDamKmCohgK2QsILlwJSuEeNu7l HsbA== MIME-Version: 1.0 Received: by 10.58.133.73 with SMTP id pa9mr3926824veb.51.1344072269402; Sat, 04 Aug 2012 02:24:29 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Sat, 4 Aug 2012 02:24:29 -0700 (PDT) Date: Sat, 4 Aug 2012 11:24:29 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Questions: Subnet Technology and Routing Topology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 09:24:31 -0000 Hi, > And one more scenario. Your nodes are all stationary, your propagation is > stationary. You have no moving obstacles. But things are still > (sporadically) dynamic when your nodes fail (battery exhaustion, accident, > enemy action). So do you mean that the topology dynamics is the key for distinguishing MANETs? or do you mean having reactive or proactive protocol is the key? > Strange wording, in my opinion. It seems to me that if the > network _topology_ is truly static, you do not need a routing > protocol at all. (Note that just as the absence of movement does > not imply a static topology, a static topology does not imply > stationary nodes). IMHO after above paragraphs, the question is which topology your looking at not its dynamics/statics, because in ROLL and in MANET protocols both routing topologies are dynamic, but different methods. The new version of the draft-00 of MANET subnet technology [AB2] will distiguish between ROLL-LLNs and MANET-LLNs. MANET depend in their routing on Logical Topology [AB1] as for some LLNs that are not related to MANET have routings in the both Physical and Logical Topology [AB1]. Second issue is some MANET architecture are different from LLN architecture. LLN uses layer 2 to mesh and its routing maybe influenced by it could we say the same in MANET. Please comment, [AB1] http://www.ietf.org/id/draft-baryun-manet-terminology-00.txt [AB2] http://www.ietf.org/id/draft-baryun-manet-technology-00.txt Regards Abdussalam Baryun University of Glamorgan, UK ---------------------------------------------------------------------------------------------------------------- In discussions one may be wrong, or may be right, but it does not matter if we work together as a group to progress and resolve all issues. IETF WGs are always right. ----------------------------------------------------------------------------------------------------------------- >Subject: Re: [manet] Discussing LOADng suggestions >From: "Dearlove, Christopher (UK)" >Date: Wed, 1 Aug 2012 09:04:04 +0000 > > If a network is static, but not preconfigured, then you may still want to > run a proactive routing protocol up to the point where you have established > the topology, then turn it off. Or if there's a reason not to want to do > that, you could run a reactive routing protocol, with anything up to > infinite expiry time on discovered routes. > > And one more scenario. Your nodes are all stationary, your propagation is > stationary. You have no moving obstacles. But things are still > (sporadically) dynamic when your nodes fail (battery exhaustion, accident, > enemy action). > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | > http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Ulrich Herberg > Sent: 31 July 2012 19:26 > To: Velt, R. (Ronald) in 't > Cc: manet; Abdussalam Baryun > Subject: Re: [manet] Discussing LOADng suggestions > > > *** WARNING *** > This message originates from outside our organisation, either from an > external partner or the internet. > Keep this in mind if you answer this message. > Please see this > process > on how to deal with suspicious emails. > Ronald, > On Tue, Jul 31, 2012 at 11:23 AM, Velt, R. (Ronald) in 't > > wrote: > >>-----Original Message----- >>From: manet-bounces@ietf.org >> [mailto:manet-bounces@ietf.org] On Behalf >>Of Antonin Bas >>Sent: dinsdag 31 juli 2012 19:44 >>To: Ulrich Herberg >>Cc: manet; Abdussalam Baryun >>Subject: Re: [manet] Discussing LOADng suggestions >> >>According to MANET charter, >> >>The purpose of the MANET working group is to standardize IP routing >> protocol functionality suitable for wireless routing application within >> both static and dynamic topologies with increased dynamics due to node >> motion or other factors. > Strange wording, in my opinion. It seems to me that if the network > _topology_ is truly static, you do not need a routing protocol at all. > > > I agree. > > > (Note that just as the absence of movement does not imply a static topology, > a static topology does not imply stationary nodes). > >> >>So I don't think MANETs are defined by mobility, but by "increased >>dynamics",which can be due to motion, but also to lossy links. > So why aren't they called ANETs? > > > Or DANET ("dynamic"). It just did not sound as nice when the term was > created. > > Best > Ulrich > > > > > Ronald From hrogge@googlemail.com Sat Aug 4 08:40:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1036C21F86DB for ; Sat, 4 Aug 2012 08:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ7Pklj7uGvU for ; Sat, 4 Aug 2012 08:40:55 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 74C2B21F864A for ; Sat, 4 Aug 2012 08:40:55 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1266531pbb.31 for ; Sat, 04 Aug 2012 08:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1fd1Cs96GGLfif9r5I5I9krU+ZRd+La8ZUrblyHxvSM=; b=fik4zTdjo838Mh/cn91ILSG9NWdsVgFRVwQjjBw3VWQjcynO3FNZoFJrJbonF0Vrbu hLR6LYAect17rM710ounMAf2BG03NSabuTzquwuWO1x+MQcbkgn2QG+tEguFOmYVveXT FXNMAKcybRZVk9wWH0FximE8UH1fR5WctCRpYFg68RNxIRCcTxLtm2UMqRFfZe8KeUbK fV4w+CoK/b7XwBifDx2ZY95UBdUiH2buUzpeZBeMguVs/Q8d++4nupe/U3EipGj6mGcM 5MN0mIOwEyFkQRlbW4/sy3w91ZHb5LERFAoJ9xMbT+G0j2rZNaEcPmJutd8UVVtHAcEJ EbPw== Received: by 10.66.89.6 with SMTP id bk6mr5099377pab.81.1344094855167; Sat, 04 Aug 2012 08:40:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.241.131 with HTTP; Sat, 4 Aug 2012 08:40:34 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Sat, 4 Aug 2012 08:40:34 -0700 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Questions: Subnet Technology and Routing Topology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 15:40:56 -0000 On Sat, Aug 4, 2012 at 2:24 AM, Abdussalam Baryun wrote: > IMHO after above paragraphs, the question is which topology your > looking at not its dynamics/statics, because in ROLL and in MANET > protocols both routing topologies are dynamic, but different methods. I would disagree. > The new version of the draft-00 of MANET subnet technology [AB2] will > distiguish between ROLL-LLNs and MANET-LLNs. MANET depend in their > routing on Logical Topology [AB1] as for some LLNs that are not > related to MANET have routings in the both Physical and Logical > Topology [AB1]. I am not sure this makes any sense. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From yi.jiazi@gmail.com Mon Aug 6 09:18:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB73F21F860B for ; Mon, 6 Aug 2012 09:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQfVLD9dhYH0 for ; Mon, 6 Aug 2012 09:18:59 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0D2F21F85E7 for ; Mon, 6 Aug 2012 09:18:58 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so1500952wib.13 for ; Mon, 06 Aug 2012 09:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=8uu10wmc2RwkxZa77vIMrwBqFQ3HzkNw3/a+Hdo6VsQ=; b=DD1foRh5a7csKjqE1ISYIzBhYDWIRf+PBBhp8k7fgKs6pMFi1RsGkGY9c8rgozH8sd 9C4AYFYg/bDHr9irZCKBJavk6CMMVvIHiKIBStRg0AFx6WRn5iHK/6LY7uFYK+5z7VZC JmcwdNGZovQO0lvTGE940aCEBpiIOBOZRs13Rs80+QDiJKJ2RDM2rAmaloJUNxF454zZ 8l+agCqWhAB4kNFulxboMMHtWWMbHzBG+tpNQjowsgBcRnkLzw3SjnFQ+5VLFScOjrGt LKrn+h7zU12M71sVfZqJBQD9Pj9j+aWGpQSXjNQM//+yzsOFQkKiSGKogJGIwrsiFP8C O0sA== Received: by 10.216.136.230 with SMTP id w80mr6178310wei.199.1344269937428; Mon, 06 Aug 2012 09:18:57 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id fr4sm23985259wib.8.2012.08.06.09.18.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Aug 2012 09:18:56 -0700 (PDT) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_C6090CDD-0DA2-4C8B-AF40-E516A73C90C1" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Jiazi YI In-Reply-To: <1B40484159234F4FB6FE11D4C2F408DE01962FAE@SUKNPT8108.cogent-dsn.local> Date: Mon, 6 Aug 2012 18:18:54 +0200 Message-Id: References: <1B40484159234F4FB6FE11D4C2F408DE01962FAE@SUKNPT8108.cogent-dsn.local> To: John Dowdell X-Mailer: Apple Mail (2.1485) Cc: manet@ietf.org Subject: Re: [manet] NHDP-sec-threats feedback X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 16:19:00 -0000 --Apple-Mail=_C6090CDD-0DA2-4C8B-AF40-E516A73C90C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear John,=20 Thanks for your comments, please check inline: On Jul 31, 2012, at 3:39 PM, John Dowdell = wrote: > Some comments on NHDP-sec-threats. > =20 > The quality of the implementation is outside of the scope of this = document, but here will be some variables in how robustly the protocol = has been implemented. It's probably hard to consider the quality of the implementation, but = misconfiguration of certain parameters of the protocol is worth to think = about.=20 > A simple implementation will be considerably less robust than one with = comprehensive error and failed state detection. Maybe we have a different definition of *simple*, but I kind of like = simple implementation :-P . Of course, those with more consideration of = error handling will be more robust.=20 > Links with high bit error rates are particularly difficult to cater = for, since implementations may simply crash when there are too many = simultaneous error conditions. =46rom the view of a routing protocol, I would rather say "packet loss"? = The bit error should be handled at phy/link layer. For the routing = protocol, the packet is either successfully received, or lost. I think = in that case, for NHDP, it's the parameters related to interval that = handles the holding time in the information base.=20 > =20 > However, some specifics relating to sequence numbers. > =20 > If the attacking node sent control packets with random sequence = numbers, and the receiving node was expecting linearly increasing = sequence numbers, would an implementation ignore packets sent with lower = sequence numbers than the highest sequence number sent? An example: say = a node was expecting to receive packets 1, 2, 3, 4, 5 and actually = received packets 10, 15, 12, 7, 20, 11, then the receiver would process = packets 10, 15 and 20 and discard 12, 7 and 11, but will waste = processing time doing so. The implementation may decide on supplementary = action if the sequence numbers are spread so far apart, as that may give = the illusion that this link has a higher packet loss than is actually = the case. An attack vector related to sequence numbers has been addressed in = section 4.5 Sequence Number Attack. = http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-00#section-4.= 5 We currently just consider an attacker generates HELLOs with increased = sequence numbers that blank out the legitimate HELLOs. In the cases of = high packet loss you mentioned (for example, receive 10, 15, 12, 7, 20, = 11 from a legitimate router), my first reflection is that it's not a = security issue, but an issue of parameter setting of the routers. In = your example, message 7, 11, 12 will be dropped, of course. In the = meantime, it's the routing protocol which decides the routing = information base, based on REFRESH_INTERVAL, L_HOLD_TIME, etc.=20 best=20 Jiazi > =20 > John > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Joseph Macker > Sent: 31 July 2012 01:09 > To: manet@ietf.org > Subject: [manet] NHDP-sec-threats feedback > =20 > I apologize to Jiazi and co-authors as we accidentally skipped one of = the slide sets at this afternoon's meeting. >=20 > Please review the slides for NHDP-sec-threats located = athttp://tools.ietf.org/wg/manet/agenda > and see draft-ietf-manet-nhdp-sec-threats-00 >=20 > The authors are asking for consideration of WG LAST CALL on this = document so please comment. >=20 > -Joe > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_C6090CDD-0DA2-4C8B-AF40-E516A73C90C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear = John, 

Thanks for your comments, please = check inline:


On Jul 31, 2012, at 3:39 PM, John Dowdell <John.Dowdell@Cassidian.com&= gt; wrote:

Some comments on = NHDP-sec-threats.
 
The quality = of the implementation is outside of the scope of this document, but here = will be some variables in how robustly the protocol has been = implemented. =


It's probably hard to consider the quality of the implementation, = but misconfiguration of certain parameters of the protocol is worth to = think about. 


A simple implementation will be = considerably less robust than one with comprehensive error and failed = state detection. =

Maybe = we have a different definition of *simple*, but I kind of like simple = implementation :-P . Of course, those with more consideration of error = handling will be more robust. 


Links with high bit error = rates are particularly difficult to cater for, since implementations may = simply crash when there are too many simultaneous error = conditions.

=46rom the view of a routing protocol, I would rather say "packet = loss"? The bit error should be handled at phy/link layer. For the = routing protocol, the packet is either successfully received, or lost. I = think in that case, for NHDP, it's the parameters related to interval = that handles the holding time in the information = base. 


However, some specifics relating to = sequence numbers.
 
If the = attacking node sent control packets with random sequence numbers, and = the receiving node was expecting linearly increasing sequence numbers, = would an implementation ignore packets sent with lower sequence numbers = than the highest sequence number sent? An example: say a node was = expecting to receive packets 1, 2, 3, 4, 5 and actually received packets = 10, 15, 12, 7, 20, 11, then the receiver would process packets 10, 15 = and 20 and discard 12, 7 and 11, but will waste processing time doing = so. The implementation may decide on supplementary action if the = sequence numbers are spread so far apart, as that may give the illusion = that this link has a higher packet loss than is actually the = case.


=
An attack vector related to sequence numbers has been = addressed in section 4.5 Sequence Number Attack. http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-00= #section-4.5

We currently just consider an = attacker generates HELLOs with increased sequence numbers that blank out = the legitimate HELLOs. In the cases of high packet loss you mentioned = (for example, receive  10, 15, 12, 7, 20, 11 from a = legitimate router), my first reflection is that it's not a security = issue, but an issue of parameter setting of the routers. In your = example, message 7, 11, 12 will be dropped, of course. In the meantime, = it's the routing protocol which decides the routing information base, = based on REFRESH_INTERVAL, L_HOLD_TIME, = etc. 

best 

Ji= azi


 
 manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Joseph = Macker
Sent: 31 July 2012 = 01:09
To: manet@ietf.org
 [manet] NHDP-sec-threats = feedback
I apologize = to Jiazi and co-authors as we accidentally skipped one of the slide sets = at this afternoon's meeting.

Please review the slides for = NHDP-sec-threats located atmanet@ietf.org
massive amounts of interfering radio transmissions, which will > prevent legitimate traffic (e.g.,control traffic as well as data > traffic) on part of a network. >=20 > Depending on lower layers, this may not affect transmissions: HELLO > messages from an NHDP router with "jammed" interfaces may be = received > by other NHDP routers. =20 Is it "this may or may not affect transmissions"? With CSMA, Tx is blocked. It is not the interfaces that are jammed. The carrier is jammed. > As [RFC6130] identifies and uses only bi- > directional links, ??? It uses the transmission channel (either uni or bi-directional to detect = if links are bi-directional. > a link from a jammed NHDP router to a non-jammed > NHDP router Again, the carrier is jammed, not the routers. Although hammers can be used to trash routers. This is a real world = threat too. > would not be considered, and the jammed NHDP router > appear simply as "disconnected" for the un-jammed part of the = network > - which is able to maintain accurate topology maps. In general, jamming results in an increase of the noise level. This = leads to a large effect on link quality. The effect is very similar to = other blocking factors, like too long range or obstacles. So for NHDP, = it is nothing special. >=20 > If, due to a jamming attack, a considerable amount of HELLO messages > are lost or corrupted due to collisions, neighbor NHDP routers are > not able to establish links between them any more. Thus, NHDP will > present empty information bases to the protocols using it. So jamming does not introduce a specific threat on NHDP. I suggest removing the RF jamming threat out of this document. It has = little to do with NHDP. Or why not mention EMP bombs? Or more natural threats, like what water = can do with electronics? What can be included: injecting massive amount of hello messages, which = fills the carrier, affects CPU/memory, gets batteries low etc. >=20 > 4.2. Eavesdropping >=20 > Eavesdropping is a common and easy passive attack in a wireless > environment. Once a packet is transmitted, any adjacent NHDP router > can potentially obtain a copy, for immediate or later processing. Eavesdropping by itself is not a threat on the NHDP protocol.=20 One may have problems with leakage of topology information > Neither the source nor the intended destination can detect this. A > malicious NHDP router (attacker, not malicious NHDP router) > can eavesdrop on the NHDP message exchange and > thus learn the local topology. It may also eavesdrop on data = traffic > to learn source and destination addresses of data packets, or other > header information, as well as the packet payload. >=20 > Eavesdropping does not pose a direct threat to the network nor to > NHDP, in as much as that it does not alter the information recorded > by NHDP in its information bases and presented to other protocols > using it, but it can provide network information required for > enabling other attacks, such as the identity of communicating NHDP > routers, link characteristic, NHDP router configuration, etc. So eavesdropping has little to do with threats to NHDP. I suggest removing this topic. Or add "Concerns on confidentiality and = privacy". > 4.3. Incorrect HELLO Message Generation >=20 > An NHDP router running [RFC6130] performs two distinct tasks: it > periodically generates HELLO messages, and it processes incoming > HELLO messages from neighbor NHDP routers. This section describes > security attacks involving the HELLO generation. I don't think there is a threat on message generation, other than bugs. I think the focus should be on threats on non-compromised nodes, = processing incoming malicious NHDP messages, sent by attacker. > 4.3.1. Identity Spoofing >=20 > Identity spoofing implies that a Compromised NHDP router sends HELLO > messages, pretending to have the identity of another NHDP router. A > Compromised NHDP router can accomplish this by using another NHDP > router's IP address in an address block of a HELLO message, and > associating this address with a LOCAL_IF Address Block TLV. Spoofing can be done with any IP address, which does not "belong" to the = sender.=20 >=20 > An NHDP router receiving the HELLO message from a neighbor, will > assume that it originated from the NHDP router with the spoofed > interface address. As a consequence, it will add a Link Tuple to > that neighbor with the spoofed address, and include it in its next > HELLO messages as a heard neighbor (and possibly as symmetric > neighbor after another HELLO exchange). >=20 > Identity spoofing is particular harmful if a Compromised NHDP router > spoofs the identity of another NHDP router that exists in the same > routing domain. With respect to NHDP, such a duplicated, spoofed > address can lead to an inconsistent state up to two hops from an = NHDP > router. Figure 1 depicts a simple example. In that example, NHDP > router A is in radio range of C, but not of the Compromised NHDP > router X. If X spoofs the address of A, that can lead to conflicts > for upper-layer routing protocols, What are upper-layer routing protocols? We are in the IP layer, I think. > and therefore for wrong path > calculations as well as incorrect data traffic forwarding. Could be, but this get not clear in this example. Isn't this link spoofing? >=20 > .---. .---. .---. > | A |----| C |----| X | > '---' '---' '---' >=20 > Figure 1 >=20 > Figure 2 depicts another example. In this example, A is two hops > away from NHDP router C, reachable through NHDP router B. If the > Compromised NHDP router X spoofs the address of A, C may think that = A > is indeed reachable through NHDP router D. Router D is affected first. After link is verified as bi-directional, C = is affected. > .---. .---. .---. .---. .---. > | A |----| B |----| C |----| D |----| X | > '---' '---' '---' '---' '---' >=20 > Figure 2 >=20 > 4.3.2. Link Spoofing >=20 > Similar to identity spoofing, link spoofing implies that a > Compromised NHDP router sends HELLO messages, signaling an incorrect > set of neighbors. This may take either of two forms: >=20 > o A Compromised NHDP Router can postulate addresses of non-present > neighbor NHDP routers in an address block of a HELLO, associated > with LINK_STATUS TLVs. >=20 > o A Compromised NHDP router can "ignore" otherwise existing > neighbors by not advertising them in its HELLO messages. I can't see why this is forbidden. I don't say "it is nice behavior". >=20 > The effect of link spoofing with respect to NHDP are twofold, > depending on the two cases mentioned above: If the Compromised NHDP > router ignores existing neighbors in its advertisements, links will > be missing in the information bases maintained by other routers, and > there may not be any connectivity to or from these NHDP routers to > others NHDP routers in the MANET. Yes. But why forward packets via a compromised router anyway? > If, on the other hand, the > Compromised NHDP router advertises non-existing links, this will = lead > to inclusion of topological information in the information base, > describing non-existing links in the network (which, then, may be > used by other protocols using NHDP in place of other, existing, > links). Exactly. The effect would be black holes. >=20 > 4.4. Replay Attack >=20 > A replay attack implies that control traffic from one region of the > network is recorded and replayed in a different region (this type of > attack is also known as the Wormhole attack). Replay Attack could also be: same place, replayed later in time. Or even = directly in time. Isn't wormhole: (almost) same time, different place? > This may, for example, > happen when two Compromised NHDP routers collaborate on an attack, > one recording traffic in its proximity and tunneling it to the other > Compromised NHDP router, which replays the traffic. In a protocol > where links are discovered by testing reception, this will result in > extraneous link creation (basically, a "virtual link between the two > Compromised NHDP routers will appear in the information bases of > neighboring NHDP routers). The packet capture, transfer and inject must be two-way before it has a = practical affect. >=20 > While this situation may result from an attack, it may also be > intentional: if data-traffic also is relayed over the "virtual" = link, > the link being detected is indeed valid for use. This is, for > instance, used in wireless repeaters. If data traffic is not = carried > over the virtual link, an imaginary, useless, link between the two > Compromised NHDP routers, has been advertised, and is being recorded > in the information bases of their neighboring NHDP routers. Exactly. It is not the repeater characteristic what matters, but the = filters in forwarding. >=20 > Replay attacks can be especially damaging if coupled with spoofing > and tampering with sequence numbers in the replayed messages, > potentially destroying some important topology information in NHDP > routers all over the network, as described in Section 4.5. I don't see why replay is more damaging than false packet injection. The difference is that replay attacks need additional protection = mechanisms (more than just signing). >=20 > 4.6. Message Timing Attacks >=20 > In [RFC6130], each HELLO message contains a "validity time" and may > contain an "interval time" field, identifying the time for which > information in that control message should be considered valid until > discarded, and the time until the next control message of the same > type should be expected [RFC5497]. >=20 > 4.6.1. Interval Time Attack >=20 > A use of the expected interval between two successive HELLO messages > is for determining the link quality in [RFC6130]: if messages are = not > received within the expected intervals (e.g., a certain fraction of > messages are missing), then this may be used to exclude a link from > being considered as useful, even if (some) bi-directional > communication has been verified. If a Compromised NHDP router X > spoofs the identity of an existing NHDP router A, and sends HELLOs > indicating a low interval time, an NHDP router B receiving this = HELLO > will expect the following HELLO to arrive within the interval time > indicated - or otherwise, decrease the link quality for the link = A-B. > Thus, X may cause NHDP router B's estimate of the link quality for > the link A-B to fall below the limit, where it is no longer > considered as useful and, thus, not used. This needs spoofing, I think. Why would an attacker take such a = difficult approach? It can declare the links as unusable directly. >=20 > 4.6.2. Validity Time Attack >=20 > A Compromised NHDP router X can spoof the identity of an NHDP router > A and send a HELLO using a low validity time (e.g.,1 ms). A > receiving NHDP router B will discard the information upon expiration > of that interval, i.e., a link between NHDP router A and B will be > "torn down" by X. (more general comment) I think the attacker can create messages, or = capture & replay. On the created messages, it can inject whatever. I'm = not sure the listed options are complete. Why such an in detail = description? At least, I would include a "any other false message" = section. >=20 > 4.7. Indirect Jamming >=20 > Indirect jamming is when a Compromised NHDP router X by its actions > causes other legitimate NHDP routers to generate inordinate amounts > of control traffic. This increases channel occupation, and the > overhead in each receiving NHDP router processing this control > traffic. With this traffic originating from Legitimate NHDP = routers, > the malicious device may remain undetected to the wider network. Yes, it may or may not be detected. I miss the message here :-) >=20 > Figure 3 illustrates indirect jamming of [RFC6130]. A Compromised > NHDP router X advertises a symmetric spoofed link to the = non-existing > NHDP router B (at time t0). Router A selects X as MPR upon = reception > of the HELLO, and will trigger a HELLO at t1. Overhearing this > triggered HELLO, the attacker sends another HELLO at t2, advertising > the link to B as lost, which leads to NHDP router A deselecting the > attacker as MPR, and another triggered message at t3. The cycle may > be repeated, alternating advertising the link X-B as LOST and SYM. >=20 > MPRs(X) MPRs() > .---. .---. .---. .---. > | A | | A | | A | | A | > '---' '---' '---' '---' > | | | | > | SYM(B) | | LOST(B) | > | | | | > .---. .---. .---. .---. > | X | | X | | X | | X | > '---' '---' '---' '---' > . . > . . > . . > ..... ..... > . B . . B . > ..... ..... >=20 > t0 t1 t2 t3 >=20 > Figure 3 I don't get why the channel would be occupied. When the attacker spoofs many identities and set up links with extreme = long validity time, the hello messages from affected routers would = increase to huge sizes. In a somewhat dense network, this can easily = overload the network. Similar approach for TC messages and flooding. >=20 > 5. Impact of inconsistent Information Bases on Protocols using NHDP >=20 > This section describes the impact on protocols, using NHDP, of NHDP > failing to obtain and represent accurate information, possibly as a > consequence of the attacks described in Section 4. This description > emphasizes the impacts on the MANET protocols OLSRv2 [OLSRv2], and > SMF [SMF]. >=20 > 5.1. MPR Calculation MPR calculation and flooding is not a task of NHDP. > 5.1.3. Broadcast Storm I use broadcast storm for a very different problem (STP problems). >=20 > 5.2. Routing Loops Set up routes is not a task of NHDP. >=20 > 5.3. Invalid or Non-Existing Paths to Destinations Set up routes is not a task of NHDP. >=20 > 5.4. Data Sinkhole Set up routes is not a task of NHDP. Teco >=20 > best >=20 > Jiazi Yi >=20 > http://www.jiaziyi.com > LIX, Ecole Polytechnique > Route de Saclay 91128 Palaiseau Cedex France >=20 > On Jul 30, 2012, at 5:09 PM, Joseph Macker wrote: >=20 >> I apologize to Jiazi and co-authors as we accidentally skipped one of = the slide sets at this afternoon's meeting. >>=20 >> Please review the slides for NHDP-sec-threats located at = http://tools.ietf.org/wg/manet/agenda >> and see draft-ietf-manet-nhdp-sec-threats-00 >>=20 >> The authors are asking for consideration of WG LAST CALL on this = document so please comment. >>=20 >> -Joe >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Mon Aug 13 02:12:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272BB21F8707 for ; Mon, 13 Aug 2012 02:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.338 X-Spam-Level: X-Spam-Status: No, score=-10.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNxh4ztaeUbw for ; Mon, 13 Aug 2012 02:12:28 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 6859021F8718 for ; Mon, 13 Aug 2012 02:12:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,758,1336345200"; d="scan'208";a="263099193" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 13 Aug 2012 10:12:27 +0100 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q7D9CQdO015892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Aug 2012 10:12:26 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.170]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Mon, 13 Aug 2012 10:12:26 +0100 From: "Dearlove, Christopher (UK)" To: Teco Boot , Jiazi YI Thread-Topic: [manet] NHDP-sec-threats feedback Thread-Index: AQHNbrDHpRjcvV9cckSSf5d3aF6xZ5dChnwAgBCWQQCABGzA4A== Date: Mon, 13 Aug 2012 09:12:26 +0000 Message-ID: References: <6E0E9E31-A9D4-403E-8F12-85F6EF1E898C@jiaziyi.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] NHDP-sec-threats feedback X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 09:12:29 -0000 > Personal opinion: Why not change all plain text NHDP to crypto text [RFC6130]? Pre-shared single secret key for all? Or what? ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Mon Aug 13 22:02:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E0D21F8621 for ; Mon, 13 Aug 2012 22:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXla+Srjf0WX for ; Mon, 13 Aug 2012 22:02:11 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC9B221F84CE for ; Mon, 13 Aug 2012 22:02:09 -0700 (PDT) Received: by weyu54 with SMTP id u54so3407172wey.31 for ; Mon, 13 Aug 2012 22:02:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=X/0/CwkP8VGXWRztqSN20BxYZgajzdZNX9uHPMkIi7M=; b=S/+pzaSsfT10q50mmQmSaMdC5DNB0ll9OshAFs1Ac+uFE3Lw6ZYtNf8GqiDEP1GIzT oXrl8RIBWMYiVX2ymvSCjAuBpGiLbWuo21izXH2mZCUKbuCJgu6KTPJnnNbcEKeXLbKD GqhaZMszAE4+kuCDlRPro+KGUFyoXvL7zbc6v+xRoYc7y2sE0Z9qgEVxf45Gksnnt2Md O/jgGv2VJIKEeFfbioEb2g/8qymUeABG80Ccn1PDVyIIaJ1bl7PMGNIG88bCxEMJ6d10 uf1UL2MPWcoCe0y42dCMhV3Jghd2f2OA+P46OHXO0xkVCNI0X7UO+7Wb3YRJ1yoKiz+W r04A== Received: by 10.216.24.85 with SMTP id w63mr8049265wew.145.1344920528490; Mon, 13 Aug 2012 22:02:08 -0700 (PDT) Received: from [10.87.19.36] ([80.187.201.33]) by mx.google.com with ESMTPS id el6sm20262193wib.8.2012.08.13.22.02.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Aug 2012 22:02:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Tue, 14 Aug 2012 07:01:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6E0E9E31-A9D4-403E-8F12-85F6EF1E898C@jiaziyi.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnleJmUe0WF0lnZcoZKnq2yl3Cn18M8gLwzQwjZo4smxim3+4wOxZD3beXd1QOiA2onrd8m Cc: "manet@ietf.org" Subject: Re: [manet] NHDP-sec-threats feedback X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 05:02:11 -0000 Op 13 aug. 2012, om 11:12 heeft Dearlove, Christopher (UK) het volgende = geschreven: >> Personal opinion: Why not change all plain text NHDP to crypto text = [RFC6130]?=20 >=20 > Pre-shared single secret key for all? Or what? Be reader friendly, use "NHDP", not "[RFC6130]".=20 Teco >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 From jpmacker@gmail.com Thu Aug 16 06:08:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5B321F85E4 for ; Thu, 16 Aug 2012 06:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYRw8SKJCjBa for ; Thu, 16 Aug 2012 06:08:26 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C89321F84D5 for ; Thu, 16 Aug 2012 06:08:26 -0700 (PDT) Received: by ggnh4 with SMTP id h4so3145344ggn.31 for ; Thu, 16 Aug 2012 06:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=rfTG/XegFb317rXJ26HGQBw+7S8OQvrBO5eU6MLulh8=; b=mpdAsiGRqTLxqmeJiTA4Fn4Ud4HMJhkfeA0Qn2LoMjJfnViFLw1KbxbvX9DTig5Lm2 a7dJTKl8+lfTJsPa4j4WgeEuDuLDsmOeGaE880C0b7MXsNgWHKgdjgZ5nbYqJYvk0Kdc SMbG4lXdg4fPLz8277cX+PqI/LFCfHdv7x7Rov5wlOej3iwctp+O4rWrR3jiM5+kP9Lj CU1tIoK5vvGE5hmi/i9CF6mX4fUAM+l86nup5ycXNBI3rrZbsKPeOtVeeYNDbcjpprGM c+VF0DpwEg+6O4KiGqfcdPCpWsWXiwC6UHaHhovH9fVWfmE2P4PRqgfOG2qQzs8CcW+d vu9w== Received: by 10.236.113.145 with SMTP id a17mr1280887yhh.15.1345122505805; Thu, 16 Aug 2012 06:08:25 -0700 (PDT) Received: from ?IPv6:2002:458c:9704:1234:70fd:1341:f687:1bb2? ([2002:458c:9704:1234:70fd:1341:f687:1bb2]) by mx.google.com with ESMTPS id t63sm8270592yhd.7.2012.08.16.06.08.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Aug 2012 06:08:25 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: jpmacker Date: Thu, 16 Aug 2012 09:08:25 -0400 To: Henning Rogge Cc: manet , Abdussalam Baryun Subject: Re: [manet] Questions: Subnet Technology and Routing Topology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 13:08:27 -0000 i would also disagree Sent from my iPad On Aug 4, 2012, at 11:40 AM, Henning Rogge wrote: > On Sat, Aug 4, 2012 at 2:24 AM, Abdussalam Baryun > wrote: >> IMHO after above paragraphs, the question is which topology your >> looking at not its dynamics/statics, because in ROLL and in MANET >> protocols both routing topologies are dynamic, but different methods. > > I would disagree. > >> The new version of the draft-00 of MANET subnet technology [AB2] will >> distiguish between ROLL-LLNs and MANET-LLNs. MANET depend in their >> routing on Logical Topology [AB1] as for some LLNs that are not >> related to MANET have routings in the both Physical and Logical >> Topology [AB1]. > > I am not sure this makes any sense. > > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From internet-drafts@ietf.org Thu Aug 16 09:35:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8ADA21F8608; Thu, 16 Aug 2012 09:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.364 X-Spam-Level: X-Spam-Status: No, score=-102.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNiNWQ4ChLXu; Thu, 16 Aug 2012 09:35:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154A021F85C6; Thu, 16 Aug 2012 09:35:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120816163540.471.3290.idtracker@ietfa.amsl.com> Date: Thu, 16 Aug 2012 09:35:40 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:35:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Link Metrics for the Mobile Ad Hoc Network (MANET) Routi= ng Protocol OLSRv2 - Rationale Author(s) : Christopher Dearlove Thomas Heide Clausen Philippe Jacquet Filename : draft-ietf-manet-olsrv2-metrics-rationale-00.txt Pages : 29 Date : 2012-08-01 Abstract: This document describes the rationale for and design considerations behind how link metrics are included in OLSRv2, in order to allow routing by other than minimum hop count routes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-metrics-rationale There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From abdussalambaryun@gmail.com Fri Aug 17 04:36:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480A421F84CE for ; Fri, 17 Aug 2012 04:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8gLAoZrezeO for ; Fri, 17 Aug 2012 04:36:32 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5E65B21F846F for ; Fri, 17 Aug 2012 04:36:32 -0700 (PDT) Received: by qadz3 with SMTP id z3so1405161qad.10 for ; Fri, 17 Aug 2012 04:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9lo5JEFxlbUu3Z3RE+F0Qp8bfRyd0C2GGrhQVagebus=; b=DM0ljxZxZkmm0aIcMUGCAGcXf8uagcUnblyR7YK4NXE/z647d4pIYAMu7pFuhdTbQq ffkAzTf/fJAVJAjPg3aWvhtRXn4YYk34YhOaf20FgX/9eNClFvSld3N+mpI8CNflABbE NjJJj4SmQGdJERDxwojGMwxUd1cPYMpJALU4bgmgturINIh3LY/jyYK/WMJYAbhmKHeA HbWNcQU4gVHQkzrm+R1UTX0OXQhjrPA9emlHwMiBxR1PBg8eYLQ/2OhMuBLuXm6C0api N974JjOE/AJzLBAfccad1C7npgVg5Frj66tBrotZSvApwsI7aTGFIbe29w+L3nTrujvl /1ww== MIME-Version: 1.0 Received: by 10.58.32.233 with SMTP id m9mr2393217vei.23.1345203391486; Fri, 17 Aug 2012 04:36:31 -0700 (PDT) Received: by 10.220.62.77 with HTTP; Fri, 17 Aug 2012 04:36:30 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Aug 2012 12:36:30 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=047d7b3392294cdcd204c77492cd Subject: Re: [manet] Questions: Subnet Technology and Routing Topology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 11:36:33 -0000 --047d7b3392294cdcd204c77492cd Content-Type: text/plain; charset=ISO-8859-1 If there is no *reason* for agree or disagree, then there can't be a discussion. I will consider any opinion with no reason as a vote, not a discussion. Thanking you, AB ---------------- On Thu, Aug 16, 2012 at 2:08 PM, jpmacker wrote: > i would also disagree > > Sent from my iPad > > On Aug 4, 2012, at 11:40 AM, Henning Rogge wrote: > > > On Sat, Aug 4, 2012 at 2:24 AM, Abdussalam Baryun > > wrote: > >> IMHO after above paragraphs, the question is which topology your > >> looking at not its dynamics/statics, because in ROLL and in MANET > >> protocols both routing topologies are dynamic, but different methods. > > > > I would disagree. > > > >> The new version of the draft-00 of MANET subnet technology [AB2] will > >> distiguish between ROLL-LLNs and MANET-LLNs. MANET depend in their > >> routing on Logical Topology [AB1] as for some LLNs that are not > >> related to MANET have routings in the both Physical and Logical > >> Topology [AB1]. > > > > I am not sure this makes any sense. > > > > Henning Rogge > > > > -- > > Steven Hawkings about cosmic inflation: "An increase of billions of > > billions of percent in a tiny fraction of a second. Of course, that > > was before the present government." > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > --047d7b3392294cdcd204c77492cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If there is no *reason* for agree or disagree, then there can't be= a discussion.
I will consider any opinion with no reason as a vo= te, not a discussion. Thanking you,
=A0
AB
---------= -------
On Thu, Aug 16, 2012 at 2:08 PM, jpmacker <jpm= acker@gmail.com> wrote:
i would also disagree

Sent from my iPad

On Aug 4, 2012, at 11:40 AM, Henning Rogge <hrogge@googlemail.com> wrote:

> On Sat, Aug 4, 2012 at 2:24 AM, Abdussalam Baryun
> <abdussalambaryun@gma= il.com> wrote:
>> IMHO after above paragraphs, the question is which topology your >> looking at not its dynamics/statics, because in ROLL and in MANET<= br> >> protocols both routing topologies are dynamic, but different metho= ds.
>
> I would disagree.
>
>> The new version of the draft-00 of MANET subnet technology [AB2] w= ill
>> distiguish between ROLL-LLNs and MANET-LLNs. MANET depend in their=
>> routing on Logical Topology [AB1] as for some LLNs that are not >> related to MANET have routings in the both Physical and Logical >> Topology [AB1].
>
> I am not sure this makes any sense.
>
> Henning Rogge
>
> --
> Steven Hawkings about cosmic inflation: "An increase of billions = of
> billions of percent in a tiny fraction of a second. Of course, that > was before the present government."
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

--047d7b3392294cdcd204c77492cd-- From jpmacker@gmail.com Fri Aug 17 10:21:24 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09C021F8494 for ; Fri, 17 Aug 2012 10:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.672 X-Spam-Level: X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXXn8LT6A7Wx for ; Fri, 17 Aug 2012 10:21:24 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1370A11E809B for ; Fri, 17 Aug 2012 10:21:24 -0700 (PDT) Received: by yenm5 with SMTP id m5so4637124yen.31 for ; Fri, 17 Aug 2012 10:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=l49/U9NDk3tG9/b9a0oXlct6+EsLp1PCBhmo5eA7amA=; b=hKyFWUMJKKNuYkb4SSWJGSgYjUdrWh07QXNn7IPHGCq337E8NQDxoV1C0HPklbd6gs 2ybWwB3MLuUQpIRTaOL/7Nl8ObepEL7Q4RaEVyjv1sP0+ZHAH+tNtjl2xq8lCrdq+5pW H+g+k+EnsIDJoZNu3jVKJenHpVPlTp1mDKyGri5Ic0HE447M5ZUN4SdGIPnZmHJhhFsN RvKy6ve4xGuCRh32edfOfM55hE/2pq/2g3/kVObtIe3/wGNIJytwPzYmttN3p6SRwkSO L5ZO7wTMf2WVdqdl8wLgyIqjQ81Dz/h/bp/FSodGG3O51YVpvnh4kOAWVqsf5u/h7Hin NzEQ== Received: by 10.236.176.8 with SMTP id a8mr9294845yhm.54.1345224083610; Fri, 17 Aug 2012 10:21:23 -0700 (PDT) Received: from ?IPv6:2002:458c:9704:1234:40db:bdfe:5e99:644? ([2002:458c:9704:1234:40db:bdfe:5e99:644]) by mx.google.com with ESMTPS id a4sm7390827anm.14.2012.08.17.10.21.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Aug 2012 10:21:23 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-2898E68D-EBD0-448C-96F8-598C8213A966 Message-Id: X-Mailer: iPad Mail (9B206) From: jpmacker Date: Fri, 17 Aug 2012 13:21:21 -0400 To: Abdussalam Baryun Cc: manet Subject: Re: [manet] Questions: Subnet Technology and Routing Topology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 17:21:24 -0000 --Apple-Mail-2898E68D-EBD0-448C-96F8-598C8213A966 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii -1 disagree the definition of consensus usually involves "agreement" as the main idea so= agree/disagree is a fine means to gain a rough feeling for consensus. On Aug 17, 2012, at 7:36 AM, Abdussalam Baryun w= rote: > If there is no *reason* for agree or disagree, then there can't be a discu= ssion. > I will consider any opinion with no reason as a vote, not a discussion. Th= anking you, > =20 > AB > ---------------- > On Thu, Aug 16, 2012 at 2:08 PM, jpmacker wrote: > i would also disagree >=20 > Sent from my iPad >=20 > On Aug 4, 2012, at 11:40 AM, Henning Rogge wrote: >=20 > > On Sat, Aug 4, 2012 at 2:24 AM, Abdussalam Baryun > > wrote: > >> IMHO after above paragraphs, the question is which topology your > >> looking at not its dynamics/statics, because in ROLL and in MANET > >> protocols both routing topologies are dynamic, but different methods. > > > > I would disagree. > > > >> The new version of the draft-00 of MANET subnet technology [AB2] will > >> distiguish between ROLL-LLNs and MANET-LLNs. MANET depend in their > >> routing on Logical Topology [AB1] as for some LLNs that are not > >> related to MANET have routings in the both Physical and Logical > >> Topology [AB1]. > > > > I am not sure this makes any sense. > > > > Henning Rogge > > > > -- > > Steven Hawkings about cosmic inflation: "An increase of billions of > > billions of percent in a tiny fraction of a second. Of course, that > > was before the present government." > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-2898E68D-EBD0-448C-96F8-598C8213A966 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
-1 disagree

the definition of consensus usually involves "agreement" as the main idea so agree/disagree is a fine means to gain a rough feeling for consensus.


On Aug 17, 2012, at 7:36 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

If there is no *reason* for agree or disagree, then there can't be a discussion.
I will consider any opinion with no reason as a vote, not a discussion. Thanking you,
 
AB
----------------
On Thu, Aug 16, 2012 at 2:08 PM, jpmacker <jpmacker@gmail.com> wrote:
i would also disagree

Sent from my iPad

On Aug 4, 2012, at 11:40 AM, Henning Rogge <hrogge@googlemail.com> wrote:

> On Sat, Aug 4, 2012 at 2:24 AM, Abdussalam Baryun
> <abdussalambaryun@gmail.com> wrote:
>> IMHO after above paragraphs, the question is which topology your
>> looking at not its dynamics/statics, because in ROLL and in MANET
>> protocols both routing topologies are dynamic, but different methods.
>
> I would disagree.
>
>> The new version of the draft-00 of MANET subnet technology [AB2] will
>> distiguish between ROLL-LLNs and MANET-LLNs. MANET depend in their
>> routing on Logical Topology [AB1] as for some LLNs that are not
>> related to MANET have routings in the both Physical and Logical
>> Topology [AB1].
>
> I am not sure this makes any sense.
>
> Henning Rogge
>
> --
> Steven Hawkings about cosmic inflation: "An increase of billions of
> billions of percent in a tiny fraction of a second. Of course, that
> was before the present government."
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--Apple-Mail-2898E68D-EBD0-448C-96F8-598C8213A966-- From abdussalambaryun@gmail.com Fri Aug 17 22:57:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DBB11E80A6 for ; Fri, 17 Aug 2012 22:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6I5F-sLKYye for ; Fri, 17 Aug 2012 22:57:17 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB30D21F846D for ; Fri, 17 Aug 2012 22:57:17 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4585813vbb.31 for ; Fri, 17 Aug 2012 22:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kgvHEIaFEznVw3Fp3vIcpsCdyXvlWA5mF/juwduvamo=; b=tVnpbJlhZQZe7r2m0qo0MP+T3ZIA8qDcZsMhn+FC0C0ns4Ycz/AkZiwdojYhgt/kMT 65xjkMP0lFLWU1FLOHa9glJB9u3wDjiaXfd02F5XrtU2kOEdmEncLEytpx1Ij1ykAyIO N1Hs/Y5tjoXplWBq1ZhNQ9+hGFqkBsBGM/BApm1ttEsjZUs3wPjqId6kOWMbT/9TRlOG nTW5bD9XUhgDH9ttjTrJ6Qo5UbNhxeM88x5e2oPo0/B1iCr/PeWKBQCuytpGyB4/4ZKF 13UFxTmXQX3aDTlbJA8mdu5m/KCWYEf7AMvHZG1YlhSgb7exkjXCCxTLURovp02ffzIf W/aA== MIME-Version: 1.0 Received: by 10.220.141.208 with SMTP id n16mr4621877vcu.22.1345269436885; Fri, 17 Aug 2012 22:57:16 -0700 (PDT) Received: by 10.220.62.77 with HTTP; Fri, 17 Aug 2012 22:57:16 -0700 (PDT) In-Reply-To: References: Date: Sat, 18 Aug 2012 07:57:16 +0200 Message-ID: From: Abdussalam Baryun To: jpmacker Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Questions: Subnet Technology and Routing Topology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 05:57:18 -0000 > -1 disagree > > the definition of consensus usually involves "agreement" as the main idea so > agree/disagree is a fine means to gain a rough feeling for consensus. > For any IETF WG decisions, we need consensus, and the consensus involves agree/disagree. For WGs' discussions, a participant argument position needs known reason, which involves why/why-not. IMO, for an ietf-participant progress, he/she needs to know *why* through discussions/questions, and he/she should make *decisions* for the WG's I-Ds/RFCs with his/her group through rough consensus. Decisions are accepted by community only if they are discussed or they have clear reasons. AB > > On Aug 17, 2012, at 7:36 AM, Abdussalam Baryun > wrote: > >> If there is no *reason* for agree or disagree, then there can't be a >> discussion. >> I will consider any opinion with no reason as a vote, not a discussion. >> Thanking you, >> >> AB >> ---------------- >> On Thu, Aug 16, 2012 at 2:08 PM, jpmacker wrote: >> i would also disagree >> >> Sent from my iPad >> >> On Aug 4, 2012, at 11:40 AM, Henning Rogge wrote: >> >> > On Sat, Aug 4, 2012 at 2:24 AM, Abdussalam Baryun >> > wrote: >> >> IMHO after above paragraphs, the question is which topology your >> >> looking at not its dynamics/statics, because in ROLL and in MANET >> >> protocols both routing topologies are dynamic, but different methods. >> > >> > I would disagree. >> > >> >> The new version of the draft-00 of MANET subnet technology [AB2] will >> >> distiguish between ROLL-LLNs and MANET-LLNs. MANET depend in their >> >> routing on Logical Topology [AB1] as for some LLNs that are not >> >> related to MANET have routings in the both Physical and Logical >> >> Topology [AB1]. >> > >> > I am not sure this makes any sense. >> > >> > Henning Rogge >> > >> > -- >> > Steven Hawkings about cosmic inflation: "An increase of billions of >> > billions of percent in a tiny fraction of a second. Of course, that >> > was before the present government." >> > _______________________________________________ >> > manet mailing list >> > manet@ietf.org >> > https://www.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > From boberry@cisco.com Sat Aug 18 04:49:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00ABE21F854A for ; Sat, 18 Aug 2012 04:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-l7IwjdUleo for ; Sat, 18 Aug 2012 04:49:30 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 373F621F8540 for ; Sat, 18 Aug 2012 04:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=boberry@cisco.com; l=3880; q=dns/txt; s=iport; t=1345290570; x=1346500170; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/cJKcBfkXb/auehmbsmLSxucNu+KDjzhfmsM01VswHg=; b=MlNebcSYJEqiLid9Xr76ynEG+XUtopR9ES5YgqP+WXwXkaDsMxhe+9YP ABKE2EkEB3FpOhW/DmfzdoGB2aMq8XenVadotq+4xEIVAyP1Z4a0fY7D2 qU6UIlr0am8YvpauWrX1DUvLfrbi09kQbBsd03wLtR0UhqwluFeqzZgoS w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANOAL1CrRDoH/2dsb2JhbABFuj+BB4IgAQEBBAEBAQ8BJzICCAMQCxguIQYwBhMUDodcAwsMmXmWOA2JSgSKJ2SGMmADk3yBU4VchTCDIIFmgnw X-IronPort-AV: E=Sophos;i="4.77,790,1336348800"; d="scan'208";a="55365001" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 18 Aug 2012 11:49:30 +0000 Received: from [192.168.1.203] (ggsg-1vpn2-230-105.cisco.com [10.81.230.105]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7IBnSdR019662; Sat, 18 Aug 2012 11:49:29 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Sat, 18 Aug 2012 07:49:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <753E2C8C-0D8E-497D-ADD4-2AF6885C66D3@cisco.com> References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1084) Cc: manet Subject: Re: [manet] Questions: Subnet Technology and Routing Topology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 11:49:31 -0000 AB, Joe To avoid personal perspectives and unintended bias, suggest we simply=20 refer to in rfc2418, IETF Working Group Guidelines and Procedures. There is a lot said in rfc2418 about discussions and the WG Chairs process and discretion to determine consensus. Pasted two important ones below Thanks -Bo "...consensus MUST be reviewed on the mailing list." "Working groups make decisions through a "rough consensus" process. IETF consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group shall prevail. (However, it must be noted that "dominance" is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement.) Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as "rough consensus" and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached." On Aug 18, 2012, at 1:57 AM, Abdussalam Baryun wrote: >> -1 disagree >>=20 >> the definition of consensus usually involves "agreement" as the main = idea so >> agree/disagree is a fine means to gain a rough feeling for consensus. >>=20 >=20 > For any IETF WG decisions, we need consensus, and the consensus > involves agree/disagree. For WGs' discussions, a participant argument > position needs known reason, which involves why/why-not. > IMO, for an ietf-participant progress, he/she needs to know *why* > through discussions/questions, and he/she should make *decisions* for > the WG's I-Ds/RFCs with his/her group through rough consensus. > Decisions are accepted by community only if they are discussed or they > have clear reasons. >=20 > AB >=20 >>=20 >> On Aug 17, 2012, at 7:36 AM, Abdussalam Baryun = >> wrote: >>=20 >>> If there is no *reason* for agree or disagree, then there can't be a >>> discussion. >>> I will consider any opinion with no reason as a vote, not a = discussion. >>> Thanking you, >>>=20 >>> AB >>> ---------------- >>> On Thu, Aug 16, 2012 at 2:08 PM, jpmacker = wrote: >>> i would also disagree >>>=20 >>> Sent from my iPad >>>=20 >>> On Aug 4, 2012, at 11:40 AM, Henning Rogge = wrote: >>>=20 >>>> On Sat, Aug 4, 2012 at 2:24 AM, Abdussalam Baryun >>>> wrote: >>>>> IMHO after above paragraphs, the question is which topology your >>>>> looking at not its dynamics/statics, because in ROLL and in MANET >>>>> protocols both routing topologies are dynamic, but different = methods. >>>>=20 >>>> I would disagree. >>>>=20 >>>>> The new version of the draft-00 of MANET subnet technology [AB2] = will >>>>> distiguish between ROLL-LLNs and MANET-LLNs. MANET depend in their >>>>> routing on Logical Topology [AB1] as for some LLNs that are not >>>>> related to MANET have routings in the both Physical and Logical >>>>> Topology [AB1]. >>>>=20 >>>> I am not sure this makes any sense. >>>>=20 >>>> Henning Rogge >>>>=20 >>>> -- >>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>> billions of percent in a tiny fraction of a second. Of course, that >>>> was before the present government." >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From prvs=9579434723=bcheng@ll.mit.edu Mon Aug 20 12:57:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A5621F85B8 for ; Mon, 20 Aug 2012 12:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUtLYD7Eqq0n for ; Mon, 20 Aug 2012 12:57:25 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id C4BEB21F8592 for ; Mon, 20 Aug 2012 12:57:24 -0700 (PDT) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id q7KJvMtW012708 for ; Mon, 20 Aug 2012 15:57:22 -0400 From: "Cheng, Bow-Nan - 0665 - MITLL" To: "manet@ietf.org" Date: Mon, 20 Aug 2012 15:57:19 -0400 Thread-Topic: DLEP thoughts/questions Thread-Index: Ac1/DgMECiNReYjhQIm2wtLDINj4wA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC580EDF16095bchengllmitedu_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-20_04:2012-08-20, 2012-08-20, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208200235 Subject: [manet] DLEP thoughts/questions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 19:57:26 -0000 --_000_CC580EDF16095bchengllmitedu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, I tried to filter through all the MANET list the past few months and apolog= ize if a few of these have been asked and resolved already.. We've been wo= rking with DLEP and had a few thoughts/questions: * Connectionless radios (e.g. CSMA) - Currently DLEP is connection based an= d expects the radio to detect link state changes and link characteristic ch= anges. If the radio does it detect these changes, there is no session setup= and no metrics exchanged. The issue arises with radios that do not maintai= n a concept of a "link". For example, 802.11 only exchanges link informatio= n when there's data to be sent. Is there some thoughts on how to make DLEP = more flexible to handle radios that do not maintain this state, for example= 802.11 based radios. Perhaps, DLEP should be allow the server end to start= neighbor sessions instead of just the radio end. Also, it might be good to revisit the whole necessity of setting up per nei= ghbor sessions. This is particularly relevant for the radios that don't rea= lly know link status or can't do a good job of predicting it with RSSI. May= be just signaling would suffice. This way the radio still sends metric info= rmation to the radio without the need of knowing the link availability. * Multicast =96 Currently there is no way to handle radios that operate at = different power/modulation rates for different types of multicast traffic. = At different power rates different multicast packets may be able to reach d= ifferent amounts of neighbors. In Draft 02, they say that you can use a multicast address to define a neig= hbor. The question is do they expect that for every multicast group in the = network, a "neighbor session" will be established? This can blow up quickl= y, but it does provide the possibility of doing radios with multiple power = modulation (I.e. Map a mcast group to a certain power level). * Flow Control =96 Up until Draft 02 there has been no flow control and rat= e based control was assumed, which does not work well in shared medium. Dra= ft 02 added a paragraph about an optional credit based flow control, simila= r to RFC4978. It is unclear how credit based flow control will perform for = a broadcast medium and some work is needed to investigate a right approach.= Maybe a pause frame flow control or some sort of a hybrid approach is bett= er suited. * Link Metrics - More work is needed on proper link metrics. Maybe DLEP sho= uld be able to provide a core set of link metrics like it does now but also= allow for each radio to provide radio specific metrics that a routing prot= ocol may chose to take advantage of. In Draft 02 a new metric, Expected Forwarding Time (EFT) was added, which i= s a combo of a bunch of different latencies. Maybe it just makes sense to r= eport that in the latency field instead. Then they list for EFT, the metric= ETX in parenthesis which is something else. ETX (expected transmission cou= nt) as can be seen in the following paper: pdos.csail.mit.edu/papers/grid:m= obicom03/paper.pdf is widely used in MANET for the metric instead of hop co= unt because it estimates loss. We agree on using the ETX, but not sold on E= FT. * Data and Control Paths =96 Currently DLEP only allows both data and DLEP = control plane packets to travel over the same interface. DLEP needs to be m= ore flexible to allow for the cases where data and control plane need to be= separated over different interfaces. -Bow-Nan --_000_CC580EDF16095bchengllmitedu_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi all,

I tried to filter through all the M= ANET list the past few months and apologize if a few of these have been ask= ed and resolved already..  We've been working with DLEP and had a few = thoughts/questions:

* Connectio= nless radios (e.g. CSMA) - Currently DLEP is connection based and expects t= he radio to detect link state changes and link characteristic changes. If t= he radio does it detect these changes, there is no session setup and no met= rics exchanged. The issue arises with radios that do not maintain a concept= of a "link". For example, 802.11 only exchanges link information= when there's data to be sent. Is there some thoughts on how to make DLEP m= ore flexible to handle radios that do not maintain this state, for example = 802.11 based radios. Perhaps, DLEP should be allow the server end to start = neighbor sessions instead of just the radio end. 

Also, it might be goo= d to revisit the whole necessity of setting up per neighbor sessions. This = is particularly relevant for the radios that don't really know link status = or can't do a good job of predicting it with RSSI. Maybe just signaling wou= ld suffice. This way the radio still sends metric information to the radio = without the need of knowing the link availability.

* Multicast =96 Currently= there is no way to handle radios that operate at different power/modulatio= n rates for different types of multicast traffic. At different power rates = different multicast packets may be able to reach different amounts of neigh= bors.
In D= raft 02, they say that you can use a multicast address to define a neighbor= . The question is do they expect that for every multicast group in the netw= ork, a "neighbor session" will be established?  This can blo= w up quickly, but it does provide the possibility of doing radios with mult= iple power modulation (I.e. Map a mcast group to a certain power level).
* Flow Control =96 Up until Draft 02 there has been no flow control and= rate based control was assumed, which does not work well in shared medium.= Draft 02 added a paragraph about an optional credit based flow control, si= milar to RFC4978. It is unclear how credit based flow control will perform = for a broadcast medium and some work is needed to investigate a right appro= ach. Maybe a pause frame flow control or some sort of a hybrid approach is = better suited.

* Link Metrics - More work is needed on proper link metr= ics. Maybe DLEP should be able to provide a core set of link metrics like i= t does now but also allow for each radio to provide radio specific metrics = that a routing protocol may chose to take advantage of. 

In Draft 02 a = new metric, Expected Forwarding Time (EFT) was added, which is a combo of a bunch of different latencies. Maybe it just makes se= nse to report that in the latency field instead. Then they list for EFT, th= e metric ETX in parenthesis which is something else. ETX (expected transmis= sion count) as can be seen in the following paper: = pdos.csail.mit.e= du/papers/grid:mobicom03/paper.pdf is widely used in MANET for the metric instead of hop count b= ecause it estimates loss. We agree on using the ETX, but not sold on EFT.
* Data and Control Paths =96 Currently DLEP only allows both data and = DLEP control plane packets to travel over the same interface. DLEP needs to= be more flexible to allow for the cases where data and control plane need = to be separated over different interfaces.

-Bow-Na= n
--_000_CC580EDF16095bchengllmitedu_-- From jpmacker@gmail.com Mon Aug 20 14:12:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48BC21F8581 for ; Mon, 20 Aug 2012 14:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.936 X-Spam-Level: X-Spam-Status: No, score=-2.936 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAgKkgpxHLBC for ; Mon, 20 Aug 2012 14:12:02 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 948F821F8592 for ; Mon, 20 Aug 2012 14:12:02 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so6242865vcb.31 for ; Mon, 20 Aug 2012 14:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gfQ0EfUyeTsjomHvvAP+w8hHZBMT+IMUtYpthEwaLzs=; b=lMlm7oPRzSLEr9AMvyJeky6gBBJYFDguJIg436v220zVR52Y8293lAw3IcJXnud00z qNIxXlP1QbnGIrnerrMdwr+7678lW/w8tuk6EtV/kqbPG9IskQ6C8m7ryMCpATTRu+xs oBz1cO6x2o7vIPblVGIytZoIogR0yEvb7BQxjGnoHQc6sjZU5erMgv95KndT/ncWzzQx pKAQQtXtKM/TTjZeHi9/svZUl3hA9pSxWYvs8GYaKQiHrbFwPH26mJVjRdEAKJ0+yP9I gnEHU2E2IR+YS8nd/E6mQx9iJsPDD7gcQ2j94+xAVglj+ND3WZvD9BNzlG7Q9X1I4jBr 51NQ== MIME-Version: 1.0 Received: by 10.220.240.5 with SMTP id ky5mr11353497vcb.57.1345497111965; Mon, 20 Aug 2012 14:11:51 -0700 (PDT) Received: by 10.59.5.6 with HTTP; Mon, 20 Aug 2012 14:11:51 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Aug 2012 17:11:51 -0400 Message-ID: From: Joseph Macker To: "Cheng, Bow-Nan - 0665 - MITLL" Content-Type: multipart/alternative; boundary=14dae9cdc68b67af1404c7b8f5ef Cc: "manet@ietf.org" Subject: Re: [manet] DLEP thoughts/questions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 21:12:03 -0000 --14dae9cdc68b67af1404c7b8f5ef Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bow-nan: Thanks for posting its a good time to post WG comments/question on DLEP futures since authors are likely in the revision process. Thanks, Joe On Mon, Aug 20, 2012 at 3:57 PM, Cheng, Bow-Nan - 0665 - MITLL < bcheng@ll.mit.edu> wrote: > Hi all, > > I tried to filter through all the MANET list the past few months and > apologize if a few of these have been asked and resolved already.. We've > been working with DLEP and had a few thoughts/questions: > > * Connectionless radios (e.g. CSMA) - Currently DLEP is connection based > and expects the radio to detect link state changes and link characteristi= c > changes. If the radio does it detect these changes, there is no session > setup and no metrics exchanged. The issue arises with radios that do not > maintain a concept of a "link". For example, 802.11 only exchanges link > information when there's data to be sent. Is there some thoughts on how t= o > make DLEP more flexible to handle radios that do not maintain this state, > for example 802.11 based radios. Perhaps, DLEP should be allow the server > end to start neighbor sessions instead of just the radio end. > > Also, it might be good to revisit the whole necessity of setting up per > neighbor sessions. This is particularly relevant for the radios that don'= t > really know link status or can't do a good job of predicting it with RSSI= . > Maybe just signaling would suffice. This way the radio still sends metric > information to the radio without the need of knowing the link availabilit= y. > > * Multicast =96 Currently there is no way to handle radios that operate a= t > different power/modulation rates for different types of multicast traffic= . > At different power rates different multicast packets may be able to reach > different amounts of neighbors. > > In Draft 02, they say that you can use a multicast address to define a > neighbor. The question is do they expect that for every multicast group i= n > the network, a "neighbor session" will be established? This can blow up > quickly, but it does provide the possibility of doing radios with multipl= e > power modulation (I.e. Map a mcast group to a certain power level). > > * Flow Control =96 Up until Draft 02 there has been no flow control and r= ate > based control was assumed, which does not work well in shared medium. Dra= ft > 02 added a paragraph about an optional credit based flow control, similar > to RFC4978. It is unclear how credit based flow control will perform for = a > broadcast medium and some work is needed to investigate a right approach. > Maybe a pause frame flow control or some sort of a hybrid approach is > better suited. > > * Link Metrics - More work is needed on proper link metrics. Maybe DLEP > should be able to provide a core set of link metrics like it does now but > also allow for each radio to provide radio specific metrics that a routin= g > protocol may chose to take advantage of. > > In Draft 02 a new metric, Expected Forwarding Time (EFT) was added, which > is a combo of a bunch of different latencies. Maybe it just makes sense > to report that in the latency field instead. Then they list for EFT, the > metric ETX in parenthesis which is something else. ETX (expected > transmission count) as can be seen in the following paper: pdos.csail.*mi= t > *.edu/papers/grid:mobicom03/paper.pdf is widely used in MANET for the > metric instead of hop count because it estimates loss. We agree on using > the ETX, but not sold on EFT. > > * Data and Control Paths =96 Currently DLEP only allows both data and DLE= P > control plane packets to travel over the same interface. DLEP needs to be > more flexible to allow for the cases where data and control plane need to > be separated over different interfaces. > > -Bow-Nan > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --14dae9cdc68b67af1404c7b8f5ef Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bow-nan:

Thanks for posting its a good time to post WG comments/ques= tion on DLEP futures since authors are likely in the revision process.
<= br>Thanks,
Joe

On Mon, Aug 20, 2012 at= 3:57 PM, Cheng, Bow-Nan - 0665 - MITLL <bcheng@ll.mit.edu> = wrote:
Hi all,

I t= ried to filter through all the MANET list the past few months and apologize= if a few of these have been asked and resolved already.. =A0We've been= working with DLEP and had a few thoughts/questions:

* Connectionless radios (e.g. CSMA) - Currently DL= EP is connection based and expects the radio to detect link state changes a= nd link characteristic changes. If the radio does it detect these changes, = there is no session setup and no metrics exchanged. The issue arises with r= adios that do not maintain a concept of a "link". For example, 80= 2.11 only exchanges link information when there's data to be sent. Is t= here some thoughts on how to make DLEP more flexible to handle radios that = do not maintain this state, for example 802.11 based radios. Perhaps, DLEP = should be allow the server end to start neighbor sessions instead of just t= he radio end.=A0

Also, it might be = good to revisit the whole necessity of setting up per neighbor sessions. Th= is is particularly relevant for the radios that don't really know link = status or can't do a good job of predicting it with RSSI. Maybe just si= gnaling would suffice. This way the radio still sends metric information to= the radio without the need of knowing the link availability.

* Multicast =96 Cu= rrently there is no way to handle radios that operate at different power/mo= dulation rates for different types of multicast traffic. At different power= rates different multicast packets may be able to reach different amounts o= f neighbors.

In Draft 02, they say that you can use a multicast addres= s to define a neighbor. The question is do they expect that for every multi= cast group in the network, a "neighbor session" will be establish= ed? =A0This can blow up quickly, but it does provide the possibility of doi= ng radios with multiple power modulation (I.e. Map a mcast group to a certa= in power level).

* Flow Control =96= Up until Draft 02 there has been no flow control and rate based control wa= s assumed, which does not work well in shared medium. Draft 02 added a para= graph about an optional credit based flow control, similar to RFC4978. It i= s unclear how credit based flow control will perform for a broadcast medium= and some work is needed to investigate a right approach. Maybe a pause fra= me flow control or some sort of a hybrid approach is better suited.

* Link Metrics -= =A0More work is needed on proper link metrics. Maybe DLEP should be able to= provide a core set of link metrics like it does now but also allow for eac= h radio to provide radio specific metrics that a routing protocol may chose= to take advantage of.=A0

In Draft 02 a new = metric, Expected Forwarding Time (EFT) was added, which is a combo of a bunch of different late= ncies. Maybe=A0it just makes sense to report that in the latency fie= ld instead. Then they list for EFT, the metric ETX in parenthesis which is = something else. ETX (expected transmission count) as can be seen in the fol= lowing paper:=A0pdos.csail.mit.edu/papers/grid:mobicom03/paper.pdf=A0is widely used in MANET for the metric instead of hop c= ount because it estimates loss. We agree on using the ETX, but not sold on = EFT.

* Data and Control= Paths =96 Currently DLEP only allows both data and DLEP control plane pack= ets to travel over the same interface. DLEP needs to be more flexible to al= low for the cases where data and control plane need to be separated over di= fferent interfaces.

-Bow-Nan

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--14dae9cdc68b67af1404c7b8f5ef-- From abdussalambaryun@gmail.com Tue Aug 21 09:42:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6F621F87A3 for ; Tue, 21 Aug 2012 09:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G1gymRjLgH1 for ; Tue, 21 Aug 2012 09:42:35 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A2B5B21F8639 for ; Tue, 21 Aug 2012 09:42:35 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2977vcb.31 for ; Tue, 21 Aug 2012 09:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=11TeZwz6/fGMBK6gfXtwKvy1GIDj/Bh5Gq50JNkSMn0=; b=I1GZvY+mweKI2UtrCeJpZTuUSAFRGLG1AwxxGlsEjkhxE8KqDFRK405QD9UHSU1RYt 3P2qbLeLCOEXrlSGmVkP4uUrxxpHZ2u/thXBpcUCCSkCDGpEeOucJ9AkvzsEBTfObovr ck552nuZb6sMH6GY3o/7Ub9cIGr/KVsCQJoPVughiNk7z8ATR0b18Mf/ojQoLcNlPxSS msjzFRxxi9pXUAojfi+6aoGrnJhd8p++jzuTFRTAXdwD2PeiYdQ7aZZslm3u6Gmf2cuY FP6T2zSVHvUjTttxw9cGqNPAEKVneIqzlkdEoUh2mfVNyz3CPxgST0AmMOVR1kfcMXkJ 3O9A== MIME-Version: 1.0 Received: by 10.220.154.17 with SMTP id m17mr7975651vcw.31.1345567354641; Tue, 21 Aug 2012 09:42:34 -0700 (PDT) Received: by 10.220.55.9 with HTTP; Tue, 21 Aug 2012 09:42:34 -0700 (PDT) Date: Tue, 21 Aug 2012 17:42:34 +0100 Message-ID: From: Abdussalam Baryun To: bcheng@ll.mit.edu Content-Type: multipart/alternative; boundary=f46d043890d731dd3804c7c950e8 Cc: manet Subject: Re: [manet] DLEP thoughts/questions/comments X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:42:37 -0000 --f46d043890d731dd3804c7c950e8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Bow-Nan and wg-participants, I thank you for your message and input, and I share with you some thoughts, and add some comments. comments in line: > > Hi all, > > I tried to filter through all the MANET list the past few months and > apologize if a few of these have been asked and resolved already.. We've > been working with DLEP and had a few thoughts/questions: > > * Connectionless radios (e.g. CSMA) - Currently DLEP is connection based > and expects the radio to detect link state changes and link characteristi= c > changes. If the radio does it detect these changes, there is no session > setup and no metrics exchanged. The issue arises with radios that do not > maintain a concept of a "link". For example, 802.11 only exchanges link > information when there's data to be sent. Is there some thoughts on how t= o > make DLEP more flexible to handle radios that do not maintain this state, > for example 802.11 based radios. Perhaps, DLEP should be allow the server > end to start neighbor sessions instead of just the radio end. > > IMO, the DLEP is connection based between the server and client but connectionless between neighbor peers. > > Also, it might be good to revisit the whole necessity of setting up per > neighbor sessions. This is particularly relevant for the radios that don'= t > really know link status or can't do a good job of predicting it with RSSI= . > Maybe just signaling would suffice. This way the radio still sends metric > information to the radio without the need of knowing the link availabilit= y. > > Yes DLEP is flexible to do both depending on the use case. > > * Multicast =96 Currently there is no way to handle radios that operate = at > different power/modulation rates for different types of multicast traffic= . > At different power rates different multicast packets may be able to reach > different amounts of neighbors. > > This will depend on the MANET subnet technology (Layer 2) used for communication, I don't think DLEP is for data-communicating, but it is for discovery. This idea you refer to is similar what I was thinking so I am trying to include in draft of manet-technologies [**]. > > In Draft 02, they say that you can use a multicast address to define a > neighbor. The question is do they expect that for every multicast group i= n > the network, a "neighbor session" will be established? This can blow up > quickly, but it does provide the possibility of doing radios with multipl= e > power modulation (I.e. Map a mcast group to a certain power level). > > IMO, it was mentioning multicast address for discovery not for communication, but MANET layer 2 is responsible for that. > * Flow Control =96 Up until Draft 02 there has been no flow control and r= ate > based control was assumed, which does not work well in shared medium. Dra= ft > 02 added a paragraph about an optional credit based flow control, similar > to RFC4978. It is unclear how credit based flow control will perform for = a > broadcast medium and some work is needed to investigate a right approach. > Maybe a pause frame flow control or some sort of a hybrid approach is > better suited. > > This was advised, presented, and discussed in the 82 WG (2011) meeting and I think the authors are invcestigating it (including other issues). This was the reason I am writing an I-D [**] related to it. > > * Link Metrics - More work is needed on proper link metrics. Maybe DLEP > should be able to provide a core set of link metrics like it does now but > also allow for each radio to provide radio specific metrics that a routin= g > protocol may chose to take advantage of. > > I support this idea totally which I think node's radio ability is important that can benefit the routing. I call that Node Ability of Participation (NAP), which I believe it will help in DSRv2+DLEP (both are in my work-in-progress). > In Draft 02 a new metric, Expected Forwarding Time (EFT) was added, which > is a combo of a bunch of different latencies. Maybe it just makes sense > to report that in the latency field instead. Then they list for EFT, the > metric ETX in parenthesis which is something else. ETX (expected > transmission count) as can be seen in the following paper: pdos.csail.*mi= t > *.edu/papers/grid:mobicom03/paper.pdf is widely used in MANET for the > metric instead of hop count because it estimates loss. We agree on using > the ETX, but not sold on EFT. > > I support that ETX is important for DLEP, and to add others depending on use case. > * Data and Control Paths =96 Currently DLEP only allows both data and DLE= P > control plane packets to travel over the same interface. DLEP needs to be > more flexible to allow for the cases where data and control plane need to > be separated over different interfaces. > > IMO, DLEP is not in the data plane, but control plane for neighbor discovery, [**] http://tools.ietf.org/id/draft-baryun-manet-technology-00.txt Best Regards Abdussalam Baryun University of Glamorgan, UK ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I maybe wrong or maybe right but it does not matter if we work as a group. IETF WGs are always right. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ---------------------------------------------------------------------------= ------------ This message and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. This message is in compliance with the IETF regulations. ---------------------------------------------------------------------------= ------------ --f46d043890d731dd3804c7c950e8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Bow-Nan and=A0wg-participants,
=A0
I thank you = for your message and input, and I share with you some thoughts, and add som= e comments.

comments in line:
= =A0
Hi all,

I tried to filter through= all the=20 MANET list the past few months and apologize if a few of these have been as= ked=20 and resolved already.. We've been working with DLEP and had a few=20 thoughts/questions:

* Connectionless=20 radios (e.g. CSMA) - Currently DLEP is connection based and expects the rad= io to=20 detect link state changes and link characteristic changes. If the radio doe= s it=20 detect these changes, there is no session setup and no metrics exchanged. T= he=20 issue arises with radios that do not maintain a concept of a "link&quo= t;. For=20 example, 802.11 only exchanges link information when there's data to be= sent. Is=20 there some thoughts on how to make DLEP more flexible to handle radios that= do=20 not maintain this state, for example 802.11 based radios. Perhaps, DLEP sho= uld=20 be allow the server end to start neighbor sessions instead of just the radi= o=20 end.
=A0
=A0
IMO, the DLEP is connection based between the server= and client but connectionless between neighbor peers.
=A0
<= blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-c= olor:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class= =3D"gmail_quote">
=A0
=A0Also, it mi= ght be=20 good to revisit the whole necessity of setting up per neighbor sessions. Th= is is=20 particularly relevant for the radios that don't really know link status= or can't=20 do a good job of predicting it with RSSI. Maybe just signaling would suffic= e.=20 This way the radio still sends metric information to the radio without the = need=20 of knowing the link availability.
=A0
Yes=A0DLEP=A0is= =A0flexible to do both depending on the use case.
=A0
=A0* Multicast= =96=20 Currently there is no way to handle radios that operate at different=20 power/modulation rates for different types of multicast traffic. At differe= nt=20 power rates different multicast packets may be able to reach different amou= nts=20 of neighbors.
=A0
This will depend on the MANET subnet = technology=A0(Layer 2) used for communication, I don't think DLEP is fo= r data-communicating, but it is for discovery. This idea you refer to is si= milar what I was thinking so I am trying to include in draft of manet-techn= ologies [**].
=A0
In Draft 02, they say that=20 you can use a multicast address to define a neighbor. The question is do th= ey=20 expect that for every multicast group in the network, a "neighbor sess= ion" will=20 be established? This can blow up quickly, but it does provide the possibil= ity=20 of doing radios with multiple power modulation (I.e. Map a mcast group to a= =20 certain power level).
=A0
IMO, it was mentioning multicast address=A0for discovery= not for communication, but MANET layer 2 is responsible for that.
=A0
* Flow Control =96=20 Up until Draft 02 there has been no flow control and rate based control was= =20 assumed, which does not work well in shared medium. Draft 02 added a paragr= aph=20 about an optional credit based flow control, similar to RFC4978. It is uncl= ear=20 how credit based flow control will perform for a broadcast medium and some = work=20 is needed to investigate a right approach. Maybe a pause frame flow control= or=20 some sort of a hybrid approach is better suited.
=A0
= =A0
This was advised, presented, and discussed=A0in the 82 WG (20= 11)=A0meeting and I think the authors are invcestigating it (including othe= r issues). This was the reason I am writing an I-D=A0[**] related to it.
=A0
=A0
=A0* Link Metr= ics=20 - More work is needed on proper link metrics. Maybe DLEP should be able to= =20 provide a core set of link metrics like it does now but also allow for each= =20 radio to provide radio specific metrics that a routing protocol may chose t= o=20 take advantage of.
=A0
=A0
I=A0support=A0thi= s idea totally which I think node's radio ability is important that can= benefit the routing. I call that Node Ability of Participation (NAP), whic= h I believe it will help in DSRv2+DLEP (both are in my work-in-progress).
=A0
In Draft 02 a new=20 metric, Expected Forwarding Time (EFT) was added, which is a combo of a=20 bunch of different latencies. Maybe it just makes sense to report th= at in=20 the latency field instead. Then they list for EFT, the metric ETX in parent= hesis=20 which is something else. ETX (expected transmission count) as can be seen i= n the=20 following paper: pdos.csail.mit.edu/papers/grid:mobicom03/paper.pdf is=20 widely used in MANET for the metric instead of hop count because it estimat= es=20 loss. We agree on using the ETX, but not sold on EFT.
= =A0
=A0
I support that ETX is important for D= LEP, and to add others depending on use case.
=A0
* Data and=20 Control Paths =96 Currently DLEP only allows both data and DLEP control pla= ne=20 packets to travel over the same interface. DLEP needs to be more flexible t= o=20 allow for the cases where data and control plane need to be separated over= =20 different interfaces.
=A0
IMO, DLEP is not in the data plane, b= ut control plane for neighbor discovery,
=A0
=A0
Best Regards
Abdussalam Bary= un
University of Glamorgan, UK
=A0
++++++++++= ++++++++++++++++++++++++++++++++++++++++++++++
I maybe wrong or m= aybe right but it does not matter if we work as a group.
IETF WGs are always right.
+++++++++++++++++++++++++++++++++= +++++++++++++++++++++++
=A0
---------------------------= ------------------------------------------------------------
This= message and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipi= ent please delete it from your system and notify the sender.
This messag= e is in compliance with=A0the IETF regulations.
-----------------= ---------------------------------------------------------------------- --f46d043890d731dd3804c7c950e8-- From sratliff@cisco.com Tue Aug 21 09:53:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F7C21F854C for ; Tue, 21 Aug 2012 09:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.123 X-Spam-Level: X-Spam-Status: No, score=-10.123 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7WTJGnbLI9Z for ; Tue, 21 Aug 2012 09:53:08 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8100721F857A for ; Tue, 21 Aug 2012 09:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=12989; q=dns/txt; s=iport; t=1345567988; x=1346777588; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sT5Uwe5kwyzdZC5sicmD18rXqXyoOPsr8gLOzjt1uNA=; b=PppswrIqkTjyERfNFIsCai8UULkzUNQE1PPpHzVP5mqoQoAaQKj/JRW1 EBcdt120Tsbv4l3v9W14usN7ByR5IApTZqRabtBSfroUIu3DTLf5+aGyM m61AMNj0wmrXl3PJq2nt8A3vxs/QNQrIBZ2gijH1UPHTw1BWAjWUdHykE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGW8M1CtJV2c/2dsb2JhbABFgkq4GYEHgiEBAQQBAQEPAVsCCRACAQgOMQcnCxQRAQEEDgUih2sLmR2gPYsIG4YhYAOVUoEUjRmBZoJh X-IronPort-AV: E=Sophos;i="4.77,803,1336348800"; d="scan'208,217";a="113836272" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 21 Aug 2012 16:53:08 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7LGr7xL001331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Aug 2012 16:53:08 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.113]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0298.004; Tue, 21 Aug 2012 11:53:07 -0500 From: "Stan Ratliff (sratliff)" To: Joseph Macker Thread-Topic: [manet] DLEP thoughts/questions Thread-Index: Ac1/DgMECiNReYjhQIm2wtLDINj4wAANFCKAAClBMwA= Date: Tue, 21 Aug 2012 16:53:07 +0000 Message-ID: <15182137-64D1-43D3-A388-E240B2EFD151@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.105] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19128.005 x-tm-as-result: No--41.148000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_1518213764D143D3A388E240B2EFD151ciscocom_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP thoughts/questions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:53:09 -0000 --_000_1518213764D143D3A388E240B2EFD151ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Bow-Nan, +1 on the "Thanks for posting". Yes, the authors are in the middle of producing an 03 version of the draft.= Will post as soon as we reach consensus on the set of edits. Regards, Stan On Aug 20, 2012, at 5:11 PM, Joseph Macker wrote: Bow-nan: Thanks for posting its a good time to post WG comments/question on DLEP fut= ures since authors are likely in the revision process. Thanks, Joe On Mon, Aug 20, 2012 at 3:57 PM, Cheng, Bow-Nan - 0665 - MITLL > wrote: Hi all, I tried to filter through all the MANET list the past few months and apolog= ize if a few of these have been asked and resolved already.. We've been wo= rking with DLEP and had a few thoughts/questions: * Connectionless radios (e.g. CSMA) - Currently DLEP is connection based an= d expects the radio to detect link state changes and link characteristic ch= anges. If the radio does it detect these changes, there is no session setup= and no metrics exchanged. The issue arises with radios that do not maintai= n a concept of a "link". For example, 802.11 only exchanges link informatio= n when there's data to be sent. Is there some thoughts on how to make DLEP = more flexible to handle radios that do not maintain this state, for example= 802.11 based radios. Perhaps, DLEP should be allow the server end to start= neighbor sessions instead of just the radio end. Also, it might be good to revisit the whole necessity of setting up per nei= ghbor sessions. This is particularly relevant for the radios that don't rea= lly know link status or can't do a good job of predicting it with RSSI. May= be just signaling would suffice. This way the radio still sends metric info= rmation to the radio without the need of knowing the link availability. * Multicast =96 Currently there is no way to handle radios that operate at = different power/modulation rates for different types of multicast traffic. = At different power rates different multicast packets may be able to reach d= ifferent amounts of neighbors. In Draft 02, they say that you can use a multicast address to define a neig= hbor. The question is do they expect that for every multicast group in the = network, a "neighbor session" will be established? This can blow up quickl= y, but it does provide the possibility of doing radios with multiple power = modulation (I.e. Map a mcast group to a certain power level). * Flow Control =96 Up until Draft 02 there has been no flow control and rat= e based control was assumed, which does not work well in shared medium. Dra= ft 02 added a paragraph about an optional credit based flow control, simila= r to RFC4978. It is unclear how credit based flow control will perform for = a broadcast medium and some work is needed to investigate a right approach.= Maybe a pause frame flow control or some sort of a hybrid approach is bett= er suited. * Link Metrics - More work is needed on proper link metrics. Maybe DLEP sho= uld be able to provide a core set of link metrics like it does now but also= allow for each radio to provide radio specific metrics that a routing prot= ocol may chose to take advantage of. In Draft 02 a new metric, Expected Forwarding Time (EFT) was added, which i= s a combo of a bunch of different latencies. Maybe it just makes sense to r= eport that in the latency field instead. Then they list for EFT, the metric= ETX in parenthesis which is something else. ETX (expected transmission cou= nt) as can be seen in the following paper: pdos.csail.mit.edu/papers/grid:m= obicom03/paper.pdf is widely used in MANET for the metric instead of hop co= unt because it estimates loss. We agree on using the ETX, but not sold on E= FT. * Data and Control Paths =96 Currently DLEP only allows both data and DLEP = control plane packets to travel over the same interface. DLEP needs to be m= ore flexible to allow for the cases where data and control plane need to be= separated over different interfaces. -Bow-Nan _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_1518213764D143D3A388E240B2EFD151ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Bow-Nan, 

+1 on the "Thanks for posting". 

Yes, the authors are in the middle of producing an 03 version of the d= raft. Will post as soon as we reach consensus on the set of edits. 

Regards,
Stan

On Aug 20, 2012, at 5:11 PM, Joseph Macker wrote:

Bow-nan:

Thanks for posting its a good time to post WG comments/question on DLEP fut= ures since authors are likely in the revision process.

Thanks,
Joe

On Mon, Aug 20, 2012 at 3:57 PM, Cheng, Bow-Nan = - 0665 - MITLL <bcheng@ll.mit.edu> wrote:
Hi all,

I tried to filter through all= the MANET list the past few months and apologize if a few of these have be= en asked and resolved already..  We've been working with DLEP and had = a few thoughts/questions:

* Connectionle= ss radios (e.g. CSMA) - Currently DLEP is connection based and expects the = radio to detect link state changes and link characteristic changes. If the = radio does it detect these changes, there is no session setup and no metrics exchanged. The issue arises with = radios that do not maintain a concept of a "link". For example, 8= 02.11 only exchanges link information when there's data to be sent. Is ther= e some thoughts on how to make DLEP more flexible to handle radios that do not maintain this state, for example 802.11 based= radios. Perhaps, DLEP should be allow the server end to start neighbor ses= sions instead of just the radio end. 

Also, it might= be good to revisit the whole necessity of setting up per neighbor sessions= . This is particularly relevant for the radios that don't really know link = status or can't do a good job of predicting it with RSSI. Maybe just signaling would suffice. This way the radio still= sends metric information to the radio without the need of knowing the link= availability.

* Multicast = =96 Currently there is no way to handle radios that operate at different po= wer/modulation rates for different types of multicast traffic. At different= power rates different multicast packets may be able to reach different amounts of neighbors.

In Draft 02, they say that you can use a multicast ad= dress to define a neighbor. The question is do they expect that for every m= ulticast group in the network, a "neighbor session" will be established?  This can blow up quickly, but it = does provide the possibility of doing radios with multiple power modulation= (I.e. Map a mcast group to a certain power level).

* Flow Control= =96 Up until Draft 02 there has been no flow control and rate based contro= l was assumed, which does not work well in shared medium. Draft 02 added a = paragraph about an optional credit based flow control, similar to RFC4978. It is unclear how credit based flow cont= rol will perform for a broadcast medium and some work is needed to investig= ate a right approach. Maybe a pause frame flow control or some sort of a hy= brid approach is better suited.

* Link Metrics= - More work is needed on proper link metrics. Maybe DLEP should be ab= le to provide a core set of link metrics like it does now but also allow fo= r each radio to provide radio specific metrics that a routing protocol may chose to take advantage of. 

In Draft 02 a = new metric, Expected Forwarding Time (EFT) was added, which is a combo of a bunch of different la= tencies. Maybe it just makes sense to report that in the latency field instead. Then they list for EFT,= the metric ETX in parenthesis which is something else. ETX (expected trans= mission count) as can be seen in the following paper: pdos.cs= ail.mit.edu/papers/grid:mobic= om03/paper.pdf is widely used in MANET for the metric instead of hop count because it estima= tes loss. We agree on using the ETX, but not sold on EFT.

* Data and Con= trol Paths =96 Currently DLEP only allows both data and DLEP control plane = packets to travel over the same interface. DLEP needs to be more flexible t= o allow for the cases where data and control plane need to be separated over different interfaces.

-Bow-Nan

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_1518213764D143D3A388E240B2EFD151ciscocom_-- From ulrich@herberg.name Wed Aug 22 13:50:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E9F21F86C1 for ; Wed, 22 Aug 2012 13:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2Xfh8bq3jYj for ; Wed, 22 Aug 2012 13:50:19 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 53F0D21F86A3 for ; Wed, 22 Aug 2012 13:50:17 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so32191vcb.31 for ; Wed, 22 Aug 2012 13:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q6PsTja//rrREyuUJ+tBGRy2nWb+kdkSXxnF69n11I0=; b=hpDWLOjefGyc8ThpRH1PM12yTCsDfzs3x3whii3nNUsYBZ2JP0wYhSHo0kTcLHvvtQ QH7M1clNyAILiHbvIlNBNtQ4z4aATC1ZY/XneqWzdz74M+KUyH4MSAuqsKS3nraFlKMu Abiik8ILYga9jPceo1vCGvdxs1ec6FgQsDWPw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Q6PsTja//rrREyuUJ+tBGRy2nWb+kdkSXxnF69n11I0=; b=ogzGDsum4oH2rL/E6WEuZl7honHzCbq+UQmNkkG/Lt7deg4gBw6s2YUUVgbDNF9Ueq UECZrRTO7Ovin8TnNOHgBkSnuKkh0SlyJr3eQ1E3+uRDbow02jFaidJhMSPC+IVVOMgX JCew7j4luZ07wbsINdpKnFQ2T11G18pfCblfVWhIZc0MS+mkYpEZpws8JNqqfPmCD12L rSTtkPZNk0wPVwqFt0HPkGqUSIqi5KGG0EE0v4dJWqtSYn2VI643d5zGTnpQpb/f7qi5 AMCLwwVOddVXra7MpJx7lKuQ8ucZLk0wSnH6jrpq0Ttk895LUA9qSrYhhwld65vvkiWl ukfQ== MIME-Version: 1.0 Received: by 10.220.221.18 with SMTP id ia18mr17700925vcb.62.1345668616506; Wed, 22 Aug 2012 13:50:16 -0700 (PDT) Received: by 10.58.187.78 with HTTP; Wed, 22 Aug 2012 13:50:16 -0700 (PDT) In-Reply-To: References: <1B40484159234F4FB6FE11D4C2F408DE01962FAE@SUKNPT8108.cogent-dsn.local> Date: Wed, 22 Aug 2012 13:50:16 -0700 Message-ID: From: Ulrich Herberg To: Jiazi YI Content-Type: multipart/alternative; boundary=14dae9cfc700df4bd304c7e0e394 X-Gm-Message-State: ALoCoQlLxolF3diaiJqCR/FYM0z3TcIZc41dS6xpT95KXUbLpbKo1KfmTlIP6Mpe3vFqiV3Ngb4a Cc: manet@ietf.org Subject: Re: [manet] NHDP-sec-threats feedback X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 20:50:20 -0000 --14dae9cfc700df4bd304c7e0e394 Content-Type: text/plain; charset=ISO-8859-1 Dear John, some additional comments: On Mon, Aug 6, 2012 at 9:18 AM, Jiazi YI wrote: > Dear John, > > Thanks for your comments, please check inline: > > > On Jul 31, 2012, at 3:39 PM, John Dowdell > wrote: > > Some comments on NHDP-sec-threats.**** > > The quality of the implementation is outside of the scope of this > document, but here will be some variables in how robustly the protocol has > been implemented. > > > > It's probably hard to consider the quality of the implementation, but > misconfiguration of certain parameters of the protocol is worth to think > about. > I agree with Jiazi. This document investigates security threats to the protocol itself, not to a specific implementation. A bad implementation can always lead to security flaws, even if the specification of the protocol has no vulnerabilities. > > > A simple implementation will be considerably less robust than one with > comprehensive error and failed state detection. > > > Maybe we have a different definition of *simple*, but I kind of like > simple implementation :-P . Of course, those with more consideration of > error handling will be more robust. > I also agree with Jiazi; simple code often entails much less risk of security flaws of the implementation (such as buffer overflows etc) than long, complex code. But again, the scope of the draft is the protocol, not implementations. > > > Links with high bit error rates are particularly difficult to cater for, > since implementations may simply crash when there are too many simultaneous > error conditions. > > > From the view of a routing protocol, I would rather say "packet loss"? The > bit error should be handled at phy/link layer. For the routing protocol, > the packet is either successfully received, or lost. I think in that case, > for NHDP, it's the parameters related to interval that handles the holding > time in the information base. > NHDP is supposed to work on very lossy channels when using a suitable link quality mechanism (and I have tried that myself with very high loss rates). As such, there is no error condition issued, but rather it is the normal expected behavior of NHDP. Using timers and link quality, NHDP will simply change the status of a link if too many packets are lost. Using hysteresis functions, it is assured that the link does not frequently flip between LOST/HEARD status. If the implementation crashes in these situations, it is not a security flaw of the protocol, but rather a sign that the implementation has issues. > > > **** > > However, some specifics relating to sequence numbers.**** > > If the attacking node sent control packets with random sequence numbers, > > Do you talk about packet sequence numbers or message sequence numbers (using RFC5444 terminology)? > and the receiving node was expecting linearly increasing sequence numbers, > > NHDP does not expect linearly increasing sequence numbers. In fact, NHDP does not even require that HELLO messages contain sequence numbers. They may be used for link quality mechanisms, but that is out of scope of the specification of NHDP. > would an implementation ignore packets sent with lower sequence numbers > than the highest sequence number sent? > > For the above reasons: no (both for packet sequence numbers and message sequence numbers) > An example: say a node was expecting to receive packets 1, 2, 3, 4, 5 and > actually received packets 10, 15, 12, 7, 20, 11, then the receiver would > process packets 10, 15 and 20 and discard 12, 7 and 11, but will waste > processing time doing so. > > Note that RFC5444 allows for parsing a message only partially, e.g. first the message header containing a sequence number, and only later the message body. > The implementation may decide on supplementary action if the sequence > numbers are spread so far apart, as that may give the illusion that this > link has a higher packet loss than is actually the case. > > > > An attack vector related to sequence numbers has been addressed in section > 4.5 Sequence Number Attack. > http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-00#section-4.5 > > We currently just consider an attacker generates HELLOs with increased > sequence numbers that blank out the legitimate HELLOs. In the cases of high > packet loss you mentioned (for example, receive 10, 15, 12, 7, 20, 11 from > a legitimate router), my first reflection is that it's not a security > issue, but an issue of parameter setting of the routers. In your example, > message 7, 11, 12 will be dropped, of course. In the meantime, it's the > routing protocol which decides the routing information base, based on > REFRESH_INTERVAL, L_HOLD_TIME, etc. > Actually, I think that section 4.5 is incorrect for NHDP; it seems to belong into an OLSRv2-sec-threats document, since sequence numbers are used in TC messages only (not in HELLOs), and TCs checked for possible duplicate processing/forwarding only in OLSRv2, not in NHDP. I will discuss that with my co-authors. Regards Ulrich **** John**** ------------------------------ *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On Behalf Of *Joseph Macker *Sent:* 31 July 2012 01:09 *To:* manet@ietf.org *Subject:* [manet] NHDP-sec-threats feedback**** I apologize to Jiazi and co-authors as we accidentally skipped one of the slide sets at this afternoon's meeting. Please review the slides for NHDP-sec-threats located at http://tools.ietf.org/wg/manet/agenda and see draft-ietf-manet-nhdp-sec-threats-00 The authors are asking for consideration of WG LAST CALL on this document so please comment. -Joe**** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --14dae9cfc700df4bd304c7e0e394 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear John,

some additional comments:

On Mon, Aug 6, 2012 at 9:18 AM, Jiazi YI <ietf@jiaziyi.com> wrote:
Dea= r John,=A0

Thanks for your comments, please check = inline:


On Jul 31, 2012, at 3:39 PM, John Dowdell &= lt;John.Dow= dell@Cassidian.com> wrote:

Some comments on NHDP= -sec-threats.
=A0
The quality of the implementation is outsid= e of the scope of this document, but here will be some variables in how rob= ustly the protocol has been implemented.


It's = probably hard to consider the quality of the implementation, but misconfigu= ration of certain parameters of the protocol is worth to think about.=A0



I agree with Jiazi. This document= investigates security threats to the protocol itself, not to a specific im= plementation. A bad implementation can always lead to security flaws, even = if the specification of the protocol has no vulnerabilities.

=A0


A simple implementati= on will be considerably less robust than one with comprehensive error and f= ailed state detection.

Maybe we have a differen= t definition of *simple*, but I kind of like simple implementation :-P . Of= course, those with more consideration of error handling will be more robus= t.=A0


I also agree with Jiazi; simple code = often entails much less risk of security flaws of the implementation (such = as buffer overflows etc) than long, complex code. But again, the scope of t= he draft is the protocol, not implementations.

=A0


Links with high bit e= rror rates are particularly difficult to cater for, since implementations m= ay simply crash when there are too many simultaneous error conditions.

From the view of a routi= ng protocol, I would rather say "packet loss"? The bit error shou= ld be handled at phy/link layer. For the routing protocol, the packet is ei= ther successfully received, or lost. I think in that case, for NHDP, it'= ;s the parameters related to interval that handles the holding time in the = information base.=A0


NHDP is supposed to work on very loss= y channels when using a suitable link quality mechanism (and I have tried t= hat myself with very high loss rates). As such, there is no error condition= issued, but rather it is the normal expected behavior of NHDP. Using timer= s and link quality, NHDP will simply change the status of a link if too man= y packets are lost. Using hysteresis functions, it is assured that the link= does not frequently flip between LOST/HEARD status. If the implementation = crashes in these situations, it is not a security flaw of the protocol, but= rather a sign that the implementation has issues.

=A0

Do you tal= k about packet sequence numbers or message sequence numbers (using RFC5444 = terminology)?
=A0
and the receiving nod= e was expecting linearly increasing sequence numbers,
NHDP does not = expect linearly increasing sequence numbers. In fact, NHDP does not even re= quire that HELLO messages contain sequence numbers. They may be used for li= nk quality mechanisms, but that is out of scope of the specification of NHD= P.
=A0
would an implementati= on ignore packets sent with lower sequence numbers than the highest sequenc= e number sent?
For the above = reasons: no (both for packet sequence numbers and message sequence numbers)=

=A0
An example: say a nod= e was expecting to receive packets 1, 2, 3, 4, 5 and actually received pack= ets 10, 15, 12, 7, 20, 11, then the receiver would process packets 10, 15 a= nd 20 and discard 12, 7 and 11, but will waste processing time doing so.

Note that = RFC5444 allows for parsing a message only partially, e.g. first the message= header containing a sequence number, and only later the message body.
=A0
The implementation ma= y decide on supplementary action if the sequence numbers are spread so far = apart, as that may give the illusion that this link has a higher packet los= s than is actually the case.


An attack= vector related to sequence numbers has been addressed in section 4.5 Seque= nce Number Attack.=A0http://tools.ietf.org/h= tml/draft-ietf-manet-nhdp-sec-threats-00#section-4.5

We currently just consider an attacker generates HELLOs= with increased sequence numbers that blank out the legitimate HELLOs. In t= he cases of high packet loss you mentioned (for example, receive=A0=A010, 1= 5, 12, 7, 20, 11=A0from a legitimate router), my first reflection is that i= t's not a security issue, but an issue of parameter setting of the rout= ers. In your example, message 7, 11, 12 will be dropped, of course. In the = meantime, it's the routing protocol which decides the routing informati= on base, based on REFRESH_INTERVAL, L_HOLD_TIME, etc.=A0


Actually, I think that section 4.5 is= incorrect for NHDP; it seems to belong into an OLSRv2-sec-threats document= , since sequence numbers are used in TC messages only (not in HELLOs), and = TCs checked for possible duplicate processing/forwarding only in OLSRv2, no= t in NHDP. I will discuss that with my co-authors.

Regards
Ulrich

=
=A0
John
<= /div>
From:= =A0manet-bounces@ietf.org= =A0[mailto:manet-bounces@ietf.org]=A0On Behalf Of=A0Joseph Macker<= br> Sent:=A031 July= 2012 01:09
To:=A0<= /span>manet@ietf.org
Subject:=A0[man= et] NHDP-sec-threats feedback<= /u>
= =A0
I apologize to Jiazi and co-authors as we accidentally skipped one of the s= lide sets at this afternoon's meeting.

Please review the s= lides for NHDP-sec-threats located athttp://tools.ietf.org/wg/manet/agenda

and see draft-ietf-manet-nhdp-sec-threats-00

The authors are ask= ing for consideration of WG LAST CALL on this document so please comment.
-Joe
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


______________________________________= _________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--14dae9cfc700df4bd304c7e0e394-- From abdussalambaryun@gmail.com Sun Aug 26 06:44:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D42221F8472 for ; Sun, 26 Aug 2012 06:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJS7c8PCEycz for ; Sun, 26 Aug 2012 06:44:36 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4D221F846F for ; Sun, 26 Aug 2012 06:44:36 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4016095vcb.31 for ; Sun, 26 Aug 2012 06:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x7xuLYUQAqmzuxXs+0NHoukw/pcvkfXf7NvA3KAnJh4=; b=gg3rXpMnJjNUT38NLP29GAD2YWQEh5koRj3l6zt9EBBvYs500V5/fH7NPtdp7Zeril 3u242dBblBUlxFqyTISXGTYOswBzquF1pS42LVRWlJXC3kAV587D/jovWeksRthvSwrK jSWD7fM3RqMQtpa3VCXF5CbuZywnDE+4eSfIVw+63dXXQe9daTU9Vc5g49lkmzLvNf6j I4eohf5YXfQjCFyg9RjDpFxhLQuQqY8xPlWR1xuE2USTj9GqTm4MHGfXoE024lc0LirO ViYrn9x4EXRzPGpUd4VxoDsUT+Izc5TNxFVw01kxw364kesclL6vNc4/sDx0hEj4gjyV /K3A== MIME-Version: 1.0 Received: by 10.58.32.233 with SMTP id m9mr10200052vei.23.1345988675451; Sun, 26 Aug 2012 06:44:35 -0700 (PDT) Received: by 10.220.55.9 with HTTP; Sun, 26 Aug 2012 06:44:35 -0700 (PDT) In-Reply-To: References: Date: Sun, 26 Aug 2012 15:44:35 +0200 Message-ID: From: Abdussalam Baryun To: Joseph Macker Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Propose update RFC2501 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 13:44:37 -0000 ++++++++second reminder++++++++++ Hi could I know why it is bad idea in relation to the reasons of update posted? AB --- On 8/1/12, Abdussalam Baryun wrote: > Hi Joe, > > Thanks for your comment. could I know the reason please, for the future, > > AB > == > On 8/1/12, Joseph Macker wrote: >> I responded to you already that I thought it was a bad idea. >> >> On Wed, Aug 1, 2012 at 12:27 AM, Abdussalam Baryun < >> abdussalambaryun@gmail.com> wrote: >> >>> Hi Joe, >>> >>> This is a reminder to a post I send before you as one author of >>> RFC2501, and the below. I need your respond to my suggestion. I >>> thought you will discuss it in the meeting but you did not mention it, >>> please comment/advise, >>> >>> AB >>> ==== >>> >>> On 7/4/12, Abdussalam Baryun wrote: >>> > Hi All, >>> > >>> > I want to propose draft-ietf work to be done on update the RFC2501, >>> > which I don't mind doing, on the following issues: >>> > >>> > 1- to include all active MANET routing RFCs as describing its network >>> > characteristics and its network context applicability, as mentioned by >>> > section-6. >>> > 2- to include the RFC5444 characteristics, or benefits to MANET >>> > performance. >>> > 3- to include NHDP RFC6130. >>> > 4- IPv6 considerations >>> > 5- Add more information in characteristic section on issue of >>> > reliability and scalability. >>> > >>> > RFC2501> 3. Characteristics of MANETs >>> > MANETs have several salient characteristics: >>> > AB>Add> 5) issue of variable E2E delay and node disconnecting from >>> > MANET. >>> > AB> suggest> to consider LLN >>> > >>> > 2501> 5. IP-Layer Mobile Routing >>> > AB> interfaces as physical layer technology, what about interfaces as >>> > logical? in some other parts we read wireless interface >>> > >>> > 2501> 5>Future interoperability may be achieved using mechanisms other >>> than >>> > mobile IP. >>> > AB> Are we there, could we answer to add some? >>> > >>> > 2501>5>Supporting these features appears only to require identifying >>> > host and router interfaces with IP addresses, identifying a router >>> > with a separate Router ID, and permitting routers to have multiple >>> > wired and wireless interfaces. >>> > AB> replace "host and router" with " router" as it was done in DYMO >>> > and >>> > OLSRv2 >>> > >>> > 2501> 4) Proactive operation: The flip-side of demand-based >>> > operation. >>> > AB> not clear >>> > >>> > 2501> Section 6.7, Duplex link and bidirectional link >>> > AB> why we use *duplex* with *link*, duplex is related to the >>> > interface system more than the link, so I recommend only using >>> > *bidirectional-link* and replace duplex-link. >>> > >>> > 2501> The following is a list of quantitative metrics that can be used >>> > to >>> > assess the performance of any routing protocol. >>> > AB> add examples of new metric used in industry or by active manet >>> > protocols >>> > >>> > 2501> 7. Security Considerations >>> > AB> Needs to be amended to consider new techniques >>> > >>> > The purpose of the proposed update, is first because RFC2501 is a >>> > reference to many new RFCs and that updates directs progress designs. >>> > Please note that I will not do this work until most active participant >>> > agree, thanking you, >>> > >>> > Best Regards >>> > Abdussalam >>> > >>> > +++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> > On 6/21/12, Charles E. Perkins wrote: >>> >> >>> >> Hello Abdussalam, >>> >> >>> >> I didn't see what part of RFC 2501 needed to be revised. >>> >> Do you have a specific proposal? I think that, before you >>> >> could expect any discussion on revising that document, >>> >> you would have to point out what part or parts need >>> >> work. >>> >> >>> >> Regards, >>> >> Charlie P. >>> >> >>> >> On 6/21/2012 9:10 AM, Abdussalam Baryun wrote: >>> >>>> Could we Update RFC2501? >>> >>> I see that RFC2501 some how defines MANET technologies, which will >>> >>> be >>> >>> a good reference in the draft I am writting of L2 subnets, but maybe >>> >>> RFC2501 is enough for the protocols, and no need for a new draft. >>> >>> However, that will depend on the WG discussion and decision :) >>> >>> >>> >>> I got no answer of the question so far, therefore, I will propose it >>> >>> to be discussed in the next meeting IETF 84. >>> >>> >>> >>> AB >>> >>> ===================================================== >>> >>> On 6/6/12, Abdussalam Baryun wrote: >>> >>>> Hi Folks, >>> >>>> >>> >>>> the RFC2501 is the best RFC I read and I like it because it is easy >>> >>>> to >>> >>>> read, understandable, and covers solid issues of MANET. I hope the >>> >>>> authors give us a feedback if they want to make new one as Version >>> >>>> 2. >>> >>>> >>> >>>> I see that it is old (1999), and it may be interesting to update it >>> >>>> some how, I hope the authors can update its issues and evaluation, >>> >>>> now >>> >>>> we got new RFCs and industries have new needs than 90s, it does not >>> >>>> cover different devices constraints as sensors and LLNs, and IPv6, >>> >>>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 are >>> >>>> getting renew versions. >>> >>>> >>> >>>> As I can see OLSRv2 and AODVv2 are going in progress, why we don't >>> >>>> try >>> >>>> to update RFC2501 as well, it will only take few days or a month, >>> >>>> to >>> >>>> draft and submit so why leave it old-documents with old >>> >>>> considerations? Please advise, >>> >>>> >>> >>>> Abdussalam Baryun >>> >>>> University of Glamorgan, UK. >>> >>>> ========================================================= >>> >>>> >>> >>> _______________________________________________ >>> >>> manet mailing list >>> >>> manet@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> >> >>> >> >>> >> -- >>> >> Regards, >>> >> Charlie P. >>> >> >>> >> >>> > >>> >> > From jpmacker@gmail.com Sun Aug 26 10:33:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A204B21F8518 for ; Sun, 26 Aug 2012 10:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ7sLF6-QWMs for ; Sun, 26 Aug 2012 10:33:21 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD75021F84F3 for ; Sun, 26 Aug 2012 10:33:20 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4059592vbb.31 for ; Sun, 26 Aug 2012 10:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=9yjaWXZsI7Y6k4JGQC9O2QeE1C3OxAlA39LhZlmN14Y=; b=N8aRmUmWHNpVPVj3mioH04TTPk3GQ16P457Rga86OUzAhbQOS56Hn0zpbZ99ZSmH2+ fQ+T38PpKifGS4u2helD6ljUkBZsgPPqWDpH6AzBKPt77FtsbSUWVndbEQApnvYyGRH9 kV8YEV5vW5IhpJoDrcr6O5ClX1Z+wv5m6Bz6Kxa/3QhtP5gTUni2vjEAnTFIxSwlgilA OjM8X1bnSh8/oBS7Sw/0Vd5Cj/VqYVi8xEzZTmHVex1bkendXSLi1lHE3F8p8Xe2auA2 us9EbV4FOH+zzc8XcaVnzVVmF0YhANu89R/9lV6bOV8Y5T5dQqOPQWePevQ9ckp3OiK0 +d/g== Received: by 10.52.21.82 with SMTP id t18mr8178315vde.66.1346002400175; Sun, 26 Aug 2012 10:33:20 -0700 (PDT) Received: from ?IPv6:2002:458c:9704:1234:10c0:78d1:97cc:9953? ([2002:458c:9704:1234:10c0:78d1:97cc:9953]) by mx.google.com with ESMTPS id i13sm8482395vdj.4.2012.08.26.10.33.19 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 26 Aug 2012 10:33:19 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <116CFD27-CAFE-40C9-ABCE-61E6D6A5D2F9@gmail.com> X-Mailer: iPad Mail (9B206) From: jpmacker Date: Sun, 26 Aug 2012 13:33:18 -0400 To: Abdussalam Baryun Cc: manet Subject: Re: [manet] Propose update RFC2501 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 17:33:21 -0000 its an infomational thats not critical to our wg progress right now and does= not need updating in my opinion. Many other wg members have expressed the= ir disagreement to the Proposal as wg activity also. can you accept the nega= tive wg feedback or not? Sent from my iPad On Aug 26, 2012, at 9:44 AM, Abdussalam Baryun w= rote: > ++++++++second reminder++++++++++ > Hi >=20 > could I know why it is bad idea in relation to the reasons of update poste= d? >=20 > AB > --- > On 8/1/12, Abdussalam Baryun wrote: >> Hi Joe, >>=20 >> Thanks for your comment. could I know the reason please, for the future, >>=20 >> AB >> =3D=3D >> On 8/1/12, Joseph Macker wrote: >>> I responded to you already that I thought it was a bad idea. >>>=20 >>> On Wed, Aug 1, 2012 at 12:27 AM, Abdussalam Baryun < >>> abdussalambaryun@gmail.com> wrote: >>>=20 >>>> Hi Joe, >>>>=20 >>>> This is a reminder to a post I send before you as one author of >>>> RFC2501, and the below. I need your respond to my suggestion. I >>>> thought you will discuss it in the meeting but you did not mention it, >>>> please comment/advise, >>>>=20 >>>> AB >>>> =3D=3D=3D=3D >>>>=20 >>>> On 7/4/12, Abdussalam Baryun wrote: >>>>> Hi All, >>>>>=20 >>>>> I want to propose draft-ietf work to be done on update the RFC2501, >>>>> which I don't mind doing, on the following issues: >>>>>=20 >>>>> 1- to include all active MANET routing RFCs as describing its network >>>>> characteristics and its network context applicability, as mentioned by= >>>>> section-6. >>>>> 2- to include the RFC5444 characteristics, or benefits to MANET >>>>> performance. >>>>> 3- to include NHDP RFC6130. >>>>> 4- IPv6 considerations >>>>> 5- Add more information in characteristic section on issue of >>>>> reliability and scalability. >>>>>=20 >>>>> RFC2501> 3. Characteristics of MANETs >>>>> MANETs have several salient characteristics: >>>>> AB>Add> 5) issue of variable E2E delay and node disconnecting from >>>>> MANET. >>>>> AB> suggest> to consider LLN >>>>>=20 >>>>> 2501> 5. IP-Layer Mobile Routing >>>>> AB> interfaces as physical layer technology, what about interfaces as >>>>> logical? in some other parts we read wireless interface >>>>>=20 >>>>> 2501> 5>Future interoperability may be achieved using mechanisms other= >>>> than >>>>> mobile IP. >>>>> AB> Are we there, could we answer to add some? >>>>>=20 >>>>> 2501>5>Supporting these features appears only to require identifying >>>>> host and router interfaces with IP addresses, identifying a router >>>>> with a separate Router ID, and permitting routers to have multiple >>>>> wired and wireless interfaces. >>>>> AB> replace "host and router" with " router" as it was done in DYMO >>>>> and >>>>> OLSRv2 >>>>>=20 >>>>> 2501> 4) Proactive operation: The flip-side of demand-based >>>>> operation. >>>>> AB> not clear >>>>>=20 >>>>> 2501> Section 6.7, Duplex link and bidirectional link >>>>> AB> why we use *duplex* with *link*, duplex is related to the >>>>> interface system more than the link, so I recommend only using >>>>> *bidirectional-link* and replace duplex-link. >>>>>=20 >>>>> 2501> The following is a list of quantitative metrics that can be used= >>>>> to >>>>> assess the performance of any routing protocol. >>>>> AB> add examples of new metric used in industry or by active manet >>>>> protocols >>>>>=20 >>>>> 2501> 7. Security Considerations >>>>> AB> Needs to be amended to consider new techniques >>>>>=20 >>>>> The purpose of the proposed update, is first because RFC2501 is a >>>>> reference to many new RFCs and that updates directs progress designs. >>>>> Please note that I will not do this work until most active participant= >>>>> agree, thanking you, >>>>>=20 >>>>> Best Regards >>>>> Abdussalam >>>>>=20 >>>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>> On 6/21/12, Charles E. Perkins wrote: >>>>>>=20 >>>>>> Hello Abdussalam, >>>>>>=20 >>>>>> I didn't see what part of RFC 2501 needed to be revised. >>>>>> Do you have a specific proposal? I think that, before you >>>>>> could expect any discussion on revising that document, >>>>>> you would have to point out what part or parts need >>>>>> work. >>>>>>=20 >>>>>> Regards, >>>>>> Charlie P. >>>>>>=20 >>>>>> On 6/21/2012 9:10 AM, Abdussalam Baryun wrote: >>>>>>>> Could we Update RFC2501? >>>>>>> I see that RFC2501 some how defines MANET technologies, which will >>>>>>> be >>>>>>> a good reference in the draft I am writting of L2 subnets, but maybe= >>>>>>> RFC2501 is enough for the protocols, and no need for a new draft. >>>>>>> However, that will depend on the WG discussion and decision :) >>>>>>>=20 >>>>>>> I got no answer of the question so far, therefore, I will propose it= >>>>>>> to be discussed in the next meeting IETF 84. >>>>>>>=20 >>>>>>> AB >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>>>>> On 6/6/12, Abdussalam Baryun wrote: >>>>>>>> Hi Folks, >>>>>>>>=20 >>>>>>>> the RFC2501 is the best RFC I read and I like it because it is easy= >>>>>>>> to >>>>>>>> read, understandable, and covers solid issues of MANET. I hope the >>>>>>>> authors give us a feedback if they want to make new one as Version >>>>>>>> 2. >>>>>>>>=20 >>>>>>>> I see that it is old (1999), and it may be interesting to update it= >>>>>>>> some how, I hope the authors can update its issues and evaluation, >>>>>>>> now >>>>>>>> we got new RFCs and industries have new needs than 90s, it does not= >>>>>>>> cover different devices constraints as sensors and LLNs, and IPv6, >>>>>>>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 are >>>>>>>> getting renew versions. >>>>>>>>=20 >>>>>>>> As I can see OLSRv2 and AODVv2 are going in progress, why we don't >>>>>>>> try >>>>>>>> to update RFC2501 as well, it will only take few days or a month, >>>>>>>> to >>>>>>>> draft and submit so why leave it old-documents with old >>>>>>>> considerations? Please advise, >>>>>>>>=20 >>>>>>>> Abdussalam Baryun >>>>>>>> University of Glamorgan, UK. >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Regards, >>>>>> Charlie P. >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 From abdussalambaryun@gmail.com Sun Aug 26 23:17:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F188B21F8551 for ; Sun, 26 Aug 2012 23:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEySZ-LRt40K for ; Sun, 26 Aug 2012 23:17:36 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E6E1721F853F for ; Sun, 26 Aug 2012 23:17:35 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4533913vcb.31 for ; Sun, 26 Aug 2012 23:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cMqKNoHa9Mu7HbmdTYlwuemRCA88oNnP6MW+liclJEk=; b=aGZcwhLviiM5xt4ZGvs18lO3csT+9WmQJwd2QlRh3JqWiIvx/kftjNUjdos67uH6vb igkkp56pk6Ah8Q+KaTDggc0Bsvb1Scl8GW6/BnQl6BxZb6kaokrs0iPqDTAA9aBBunvZ oFjLiQ5JNssqXpD/t97nVsAaZMLAyDF4HxSb07pvqx+7dWfRJS4AyZNcVNV5XmoBP4kK DAMGlwvPHSfWp3BcwQRjj8Lb8H+TdW0Tupw92OTOMhpVD5ugS+1EYNUKpQTdhzIBGKu4 c1ULKQkRnU9jk/jvCfSgPOfCbINq+e7UI9ss6ySAYfFAHucV8TZV5BdNve0zv8urzEb1 S3VQ== MIME-Version: 1.0 Received: by 10.58.58.174 with SMTP id s14mr11485864veq.51.1346048255053; Sun, 26 Aug 2012 23:17:35 -0700 (PDT) Received: by 10.220.55.9 with HTTP; Sun, 26 Aug 2012 23:17:34 -0700 (PDT) In-Reply-To: <116CFD27-CAFE-40C9-ABCE-61E6D6A5D2F9@gmail.com> References: <116CFD27-CAFE-40C9-ABCE-61E6D6A5D2F9@gmail.com> Date: Mon, 27 Aug 2012 08:17:34 +0200 Message-ID: From: Abdussalam Baryun To: jpmacker Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Propose update RFC2501 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 06:17:37 -0000 It is an informational, but all standards related to MANET WG point to its information. RFC2501's information can be critical because it describes many issues related to manet-routing which routing-standards refer to. IMHO, informational RFCs need *update* more frequent (if concepts/standards/information are changed in IETF) than standard RFCs, because standards maybe used by the internet industry, but informational-RFCs are used by participants in IETF and are referenced by other RFCs/new-I-Ds. I prefer to reference to updated information if needed. > Many other wg members have expressed > their disagreement to the Proposal as wg activity also. can you accept the > negative wg feedback or not? Yes it is ok/accepted for now, just needed the authors reason, so I can go forward (if I refer or not to it in a work I am doing). However, few wg participants (maybe five) disagreed, and some still did not decide or reply (I MAY understand as agreed with proposal). Thanks, Best Regards, AB --------------------- On 8/26/12, jpmacker wrote: > its an infomational thats not critical to our wg progress right now and does > not need updating in my opinion. Many other wg members have expressed > their disagreement to the Proposal as wg activity also. can you accept the > negative wg feedback or not? > > > Sent from my iPad > > On Aug 26, 2012, at 9:44 AM, Abdussalam Baryun > wrote: > >> ++++++++second reminder++++++++++ >> Hi >> >> could I know why it is bad idea in relation to the reasons of update >> posted? >> >> AB >> --- >> On 8/1/12, Abdussalam Baryun wrote: >>> Hi Joe, >>> >>> Thanks for your comment. could I know the reason please, for the future, >>> >>> AB >>> == >>> On 8/1/12, Joseph Macker wrote: >>>> I responded to you already that I thought it was a bad idea. >>>> >>>> On Wed, Aug 1, 2012 at 12:27 AM, Abdussalam Baryun < >>>> abdussalambaryun@gmail.com> wrote: >>>> >>>>> Hi Joe, >>>>> >>>>> This is a reminder to a post I send before you as one author of >>>>> RFC2501, and the below. I need your respond to my suggestion. I >>>>> thought you will discuss it in the meeting but you did not mention it, >>>>> please comment/advise, >>>>> >>>>> AB >>>>> ==== >>>>> >>>>> On 7/4/12, Abdussalam Baryun wrote: >>>>>> Hi All, >>>>>> >>>>>> I want to propose draft-ietf work to be done on update the RFC2501, >>>>>> which I don't mind doing, on the following issues: >>>>>> >>>>>> 1- to include all active MANET routing RFCs as describing its network >>>>>> characteristics and its network context applicability, as mentioned >>>>>> by >>>>>> section-6. >>>>>> 2- to include the RFC5444 characteristics, or benefits to MANET >>>>>> performance. >>>>>> 3- to include NHDP RFC6130. >>>>>> 4- IPv6 considerations >>>>>> 5- Add more information in characteristic section on issue of >>>>>> reliability and scalability. >>>>>> >>>>>> RFC2501> 3. Characteristics of MANETs >>>>>> MANETs have several salient characteristics: >>>>>> AB>Add> 5) issue of variable E2E delay and node disconnecting from >>>>>> MANET. >>>>>> AB> suggest> to consider LLN >>>>>> >>>>>> 2501> 5. IP-Layer Mobile Routing >>>>>> AB> interfaces as physical layer technology, what about interfaces as >>>>>> logical? in some other parts we read wireless interface >>>>>> >>>>>> 2501> 5>Future interoperability may be achieved using mechanisms >>>>>> other >>>>> than >>>>>> mobile IP. >>>>>> AB> Are we there, could we answer to add some? >>>>>> >>>>>> 2501>5>Supporting these features appears only to require identifying >>>>>> host and router interfaces with IP addresses, identifying a router >>>>>> with a separate Router ID, and permitting routers to have multiple >>>>>> wired and wireless interfaces. >>>>>> AB> replace "host and router" with " router" as it was done in DYMO >>>>>> and >>>>>> OLSRv2 >>>>>> >>>>>> 2501> 4) Proactive operation: The flip-side of demand-based >>>>>> operation. >>>>>> AB> not clear >>>>>> >>>>>> 2501> Section 6.7, Duplex link and bidirectional link >>>>>> AB> why we use *duplex* with *link*, duplex is related to the >>>>>> interface system more than the link, so I recommend only using >>>>>> *bidirectional-link* and replace duplex-link. >>>>>> >>>>>> 2501> The following is a list of quantitative metrics that can be >>>>>> used >>>>>> to >>>>>> assess the performance of any routing protocol. >>>>>> AB> add examples of new metric used in industry or by active manet >>>>>> protocols >>>>>> >>>>>> 2501> 7. Security Considerations >>>>>> AB> Needs to be amended to consider new techniques >>>>>> >>>>>> The purpose of the proposed update, is first because RFC2501 is a >>>>>> reference to many new RFCs and that updates directs progress designs. >>>>>> Please note that I will not do this work until most active >>>>>> participant >>>>>> agree, thanking you, >>>>>> >>>>>> Best Regards >>>>>> Abdussalam >>>>>> >>>>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>> On 6/21/12, Charles E. Perkins wrote: >>>>>>> >>>>>>> Hello Abdussalam, >>>>>>> >>>>>>> I didn't see what part of RFC 2501 needed to be revised. >>>>>>> Do you have a specific proposal? I think that, before you >>>>>>> could expect any discussion on revising that document, >>>>>>> you would have to point out what part or parts need >>>>>>> work. >>>>>>> >>>>>>> Regards, >>>>>>> Charlie P. >>>>>>> >>>>>>> On 6/21/2012 9:10 AM, Abdussalam Baryun wrote: >>>>>>>>> Could we Update RFC2501? >>>>>>>> I see that RFC2501 some how defines MANET technologies, which will >>>>>>>> be >>>>>>>> a good reference in the draft I am writting of L2 subnets, but >>>>>>>> maybe >>>>>>>> RFC2501 is enough for the protocols, and no need for a new draft. >>>>>>>> However, that will depend on the WG discussion and decision :) >>>>>>>> >>>>>>>> I got no answer of the question so far, therefore, I will propose >>>>>>>> it >>>>>>>> to be discussed in the next meeting IETF 84. >>>>>>>> >>>>>>>> AB >>>>>>>> ===================================================== >>>>>>>> On 6/6/12, Abdussalam Baryun wrote: >>>>>>>>> Hi Folks, >>>>>>>>> >>>>>>>>> the RFC2501 is the best RFC I read and I like it because it is >>>>>>>>> easy >>>>>>>>> to >>>>>>>>> read, understandable, and covers solid issues of MANET. I hope the >>>>>>>>> authors give us a feedback if they want to make new one as Version >>>>>>>>> 2. >>>>>>>>> >>>>>>>>> I see that it is old (1999), and it may be interesting to update >>>>>>>>> it >>>>>>>>> some how, I hope the authors can update its issues and evaluation, >>>>>>>>> now >>>>>>>>> we got new RFCs and industries have new needs than 90s, it does >>>>>>>>> not >>>>>>>>> cover different devices constraints as sensors and LLNs, and IPv6, >>>>>>>>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 are >>>>>>>>> getting renew versions. >>>>>>>>> >>>>>>>>> As I can see OLSRv2 and AODVv2 are going in progress, why we don't >>>>>>>>> try >>>>>>>>> to update RFC2501 as well, it will only take few days or a month, >>>>>>>>> to >>>>>>>>> draft and submit so why leave it old-documents with old >>>>>>>>> considerations? Please advise, >>>>>>>>> >>>>>>>>> Abdussalam Baryun >>>>>>>>> University of Glamorgan, UK. >>>>>>>>> ========================================================= >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> manet mailing list >>>>>>>> manet@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> Charlie P. >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > From yi.jiazi@gmail.com Tue Aug 28 03:30:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F21A11E8108 for ; Tue, 28 Aug 2012 03:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYExppMn0hPB for ; Tue, 28 Aug 2012 03:30:47 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id C4D3A11E8101 for ; Tue, 28 Aug 2012 03:30:46 -0700 (PDT) Received: by wibhq12 with SMTP id hq12so6351592wib.1 for ; Tue, 28 Aug 2012 03:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=2EOJG9xzzkc6l3D4rwS9v9gLz+g+jv5ROmcmK/aW558=; b=Ckn/uUDHNt3nvQUZkkJ6BINC2GAun38lEAqVjYYShfs/7mb0zCp7oTESagDTIicsqW 3ynL1QMkunc+Z8M1/1mIBD78Vonkz74VkBdcLOvH16yWF6TQ9pnrheLzLM/HMtyjPhav 8cJxXARqMZfLYtReNWrnALG0Jt0onSrW5OhRi64tNNic6qOEug5TT1O5wIu6MNUgqjcS 1Ikd4NBgjgvgR4PxV80Fd4SlRTXF+pmfEHJXFskUkitYDxTg2kYvOqxUAF31w5zaryMg suX+D30xlG7IeHB0w+sMlO0iq+Um6wzmn+nlUBQhPIXF3fkKLe2kr9r6hDcVHlbsgEuV 6LFg== Received: by 10.216.241.198 with SMTP id g48mr7068609wer.192.1346149845498; Tue, 28 Aug 2012 03:30:45 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id l5sm6434667wix.5.2012.08.28.03.30.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 03:30:42 -0700 (PDT) Sender: Jiazi YI Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Jiazi YI In-Reply-To: Date: Tue, 28 Aug 2012 12:30:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6E0E9E31-A9D4-403E-8F12-85F6EF1E898C@jiaziyi.com> To: Teco Boot X-Mailer: Apple Mail (2.1485) Cc: manet@ietf.org Subject: Re: [manet] NHDP-sec-threats feedback X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 10:30:49 -0000 Dear Teco, Thanks for your detailed comments. Please check the reply inline: On Aug 10, 2012, at 4:35 PM, Teco Boot wrote: >=20 > Op 31 jul. 2012, om 03:17 heeft Jiazi YI het volgende geschreven: >=20 >> No problem, Joe.=20 >> Actually, there is no update since the last IETF in Paris, so just a = few words to be added: >>=20 >> The main comment from the last IETF meeting is regarding the scope of = this document. We have explained our approach/consideration in a = previous mail = (http://www.ietf.org/mail-archive/web/manet/current/msg12897.html ), and = there is no objection of that.=20 >>=20 >> Therefore, we would like ask for WGLC, and comments from the working = group.=20 >=20 > Here some feedback. >=20 > Overall: > I miss a description on what mode we are running in, e.g. closed = network (some security in sub-IP), or attackers within the network, with = or without access to any key material. >=20 > Also, I have often concerns on how well (or bad) security procedures = are forfilled . With a little experience, I came to the conclusion that = only the most easy to implement procedures provides somewhat protection. = In other words: complex security mechanisms is a threat on its own. This nhdp-sec-threat document is based on the assumption that no extra = security mechanism is applied in the IP layer.=20 >=20 > Personal opinion: Why not change all plain text NHDP to crypto text = [RFC6130]?=20 > (better use plain text :-) Yes, we need to be consistent through the document. We can use=20 The Neighborhood Discovery Protocol (NHDP) [RFC6130] allows routers to acquire topological information ... at the beginning, and then NHDP afterwards, for reader-friendly.=20 >=20 >> 4.1. Jamming >>=20 >> One vulnerability, common for all protocols operating a wireless ad >> hoc network, is that of "jamming", i.e., that a device generates >> massive amounts of interfering radio transmissions, which will >> prevent legitimate traffic (e.g.,control traffic as well as data >> traffic) on part of a network. >>=20 >> Depending on lower layers, this may not affect transmissions: HELLO >> messages from an NHDP router with "jammed" interfaces may be = received >> by other NHDP routers. =20 > Is it "this may or may not affect transmissions"? > With CSMA, Tx is blocked. The original sentence in the draft is correct. Depending on the L2, only = reception may be affected, not necessarily transmission.=20 We are going to make the text more clear in the next revision. >=20 > It is not the interfaces that are jammed. The carrier is jammed. Yes >=20 >> As [RFC6130] identifies and uses only bi- >> directional links, > ??? > It uses the transmission channel (either uni or bi-directional to = detect if links are bi-directional. We agree that it's not very clear here. Maybe change it to: As [RFC6130] identifies whether a link to a neighbor is uni-directional = or bi-directional, a routing protocol that uses NHDP for neighborhood = discovery may ignore a link from a jammed NHDP router to a non-jammed = NHDP router. The jammed router would appear simply as "disconnected" for the = un-jammed part of the network - which is able to maintain accurate = topology maps.=20 >=20 >> a link from a jammed NHDP router to a non-jammed >> NHDP router > Again, the carrier is jammed, not the routers. Yes > Although hammers can be used to trash routers. This is a real world = threat too. >=20 >> would not be considered, and the jammed NHDP router >> appear simply as "disconnected" for the un-jammed part of the = network >> - which is able to maintain accurate topology maps. > In general, jamming results in an increase of the noise level. This = leads to a large effect on link quality. The effect is very similar to = other blocking factors, like too long range or obstacles. So for NHDP, = it is nothing special. >=20 >>=20 >> If, due to a jamming attack, a considerable amount of HELLO messages >> are lost or corrupted due to collisions, neighbor NHDP routers are >> not able to establish links between them any more. Thus, NHDP will >> present empty information bases to the protocols using it. > So jamming does not introduce a specific threat on NHDP. >=20 > I suggest removing the RF jamming threat out of this document. It has = little to do with NHDP. > Or why not mention EMP bombs? Or more natural threats, like what water = can do with electronics? >=20 > What can be included: injecting massive amount of hello messages, = which fills the carrier, affects CPU/memory, gets batteries low etc. We agree that jamming is not a particular threat to NHDP. It can be = handled by the detection of unidirectional links.=20 The authors are going to have further discussion on this section.=20 >=20 >>=20 >> 4.2. Eavesdropping >>=20 >> Eavesdropping is a common and easy passive attack in a wireless >> environment. Once a packet is transmitted, any adjacent NHDP router >> can potentially obtain a copy, for immediate or later processing. > Eavesdropping by itself is not a threat on the NHDP protocol.=20 >=20 > One may have problems with leakage of topology information >=20 >> Neither the source nor the intended destination can detect this. A >> malicious NHDP router > (attacker, not malicious NHDP router) >=20 >> can eavesdrop on the NHDP message exchange and >> thus learn the local topology. It may also eavesdrop on data = traffic >> to learn source and destination addresses of data packets, or other >> header information, as well as the packet payload. >=20 >>=20 >> Eavesdropping does not pose a direct threat to the network nor to >> NHDP, in as much as that it does not alter the information recorded >> by NHDP in its information bases and presented to other protocols >> using it, but it can provide network information required for >> enabling other attacks, such as the identity of communicating NHDP >> routers, link characteristic, NHDP router configuration, etc. > So eavesdropping has little to do with threats to NHDP. >=20 > I suggest removing this topic. Or add "Concerns on confidentiality and = privacy". Maybe I didn't get your point very well here.=20 Although it doesn't have *direct* threat to the network, eavesdropping = is an important vector of topology information leakage. In most of the = literatures, it's kind of attack/threat.=20 In fact, in RFC 3532 Guidelines for Writing RFC Text on Security = Considerations, it says:=20 At least the following forms of attack MUST be considered: *eavesdropping*, replay, message insertion, deletion, modification, = and man-in-the-middle.=20 >=20 >=20 >=20 >> 4.3. Incorrect HELLO Message Generation >>=20 >> An NHDP router running [RFC6130] performs two distinct tasks: it >> periodically generates HELLO messages, and it processes incoming >> HELLO messages from neighbor NHDP routers. This section describes >> security attacks involving the HELLO generation. > I don't think there is a threat on message generation, other than = bugs. > I think the focus should be on threats on non-compromised nodes, = processing incoming malicious NHDP messages, sent by attacker. What we are trying to say is generation of *incorrect* HELLO message, = rather than incorrect generation. Maybe change it to Generation of = Malicious HELLO message can be more consistent with other parts of the = draft, and more clear.=20 Furthermore, we actually think incorrect generation of HELLO by = non-compromised routers (for example, because of mis-configuration), can = be a potential threat to the network. This has been addressed in our = previous reply to John Dowdell, which can be discussed in a different = section.=20 >=20 >=20 >> 4.3.1. Identity Spoofing >>=20 >> Identity spoofing implies that a Compromised NHDP router sends HELLO >> messages, pretending to have the identity of another NHDP router. A >> Compromised NHDP router can accomplish this by using another NHDP >> router's IP address in an address block of a HELLO message, and >> associating this address with a LOCAL_IF Address Block TLV. > Spoofing can be done with any IP address, which does not "belong" to = the sender.=20 Agree.=20 >=20 >>=20 >> An NHDP router receiving the HELLO message from a neighbor, will >> assume that it originated from the NHDP router with the spoofed >> interface address. As a consequence, it will add a Link Tuple to >> that neighbor with the spoofed address, and include it in its next >> HELLO messages as a heard neighbor (and possibly as symmetric >> neighbor after another HELLO exchange). >>=20 >> Identity spoofing is particular harmful if a Compromised NHDP router >> spoofs the identity of another NHDP router that exists in the same >> routing domain. With respect to NHDP, such a duplicated, spoofed >> address can lead to an inconsistent state up to two hops from an = NHDP >> router. Figure 1 depicts a simple example. In that example, NHDP >> router A is in radio range of C, but not of the Compromised NHDP >> router X. If X spoofs the address of A, that can lead to conflicts >> for upper-layer routing protocols, > What are upper-layer routing protocols? We are in the IP layer, I = think. The routing protocol that uses NHDP. We will be more precise here.=20 >=20 >> and therefore for wrong path >> calculations as well as incorrect data traffic forwarding. > Could be, but this get not clear in this example. > Isn't this link spoofing? X is spoofing the identify of A, so it's identity spoofing.=20 >=20 >>=20 >> .---. .---. .---. >> | A |----| C |----| X | >> '---' '---' '---' >>=20 >> Figure 1 >>=20 >> Figure 2 depicts another example. In this example, A is two hops >> away from NHDP router C, reachable through NHDP router B. If the >> Compromised NHDP router X spoofs the address of A, C may think that = A >> is indeed reachable through NHDP router D. > Router D is affected first. After link is verified as bi-directional, = C is affected. Yes. >=20 >=20 >> .---. .---. .---. .---. .---. >> | A |----| B |----| C |----| D |----| X | >> '---' '---' '---' '---' '---' >>=20 >> Figure 2 >>=20 >> 4.3.2. Link Spoofing >>=20 >> Similar to identity spoofing, link spoofing implies that a >> Compromised NHDP router sends HELLO messages, signaling an incorrect >> set of neighbors. This may take either of two forms: >>=20 >> o A Compromised NHDP Router can postulate addresses of non-present >> neighbor NHDP routers in an address block of a HELLO, associated >> with LINK_STATUS TLVs. >>=20 >> o A Compromised NHDP router can "ignore" otherwise existing >> neighbors by not advertising them in its HELLO messages. > I can't see why this is forbidden. I don't say "it is nice behavior". >=20 >>=20 >> The effect of link spoofing with respect to NHDP are twofold, >> depending on the two cases mentioned above: If the Compromised NHDP >> router ignores existing neighbors in its advertisements, links will >> be missing in the information bases maintained by other routers, and >> there may not be any connectivity to or from these NHDP routers to >> others NHDP routers in the MANET. > Yes. But why forward packets via a compromised router anyway? Agree.=20 >=20 >> If, on the other hand, the >> Compromised NHDP router advertises non-existing links, this will = lead >> to inclusion of topological information in the information base, >> describing non-existing links in the network (which, then, may be >> used by other protocols using NHDP in place of other, existing, >> links). > Exactly. The effect would be black holes. >=20 >>=20 >> 4.4. Replay Attack >>=20 >> A replay attack implies that control traffic from one region of the >> network is recorded and replayed in a different region (this type of >> attack is also known as the Wormhole attack). > Replay Attack could also be: same place, replayed later in time. Or = even directly in time. > Isn't wormhole: (almost) same time, different place? We mentioned in the parenthesis that it is also known as Wormhole = attack.=20 And we agree with you that just using the word wormhole attack is more = clear here. =20 >=20 >> This may, for example, >> happen when two Compromised NHDP routers collaborate on an attack, >> one recording traffic in its proximity and tunneling it to the other >> Compromised NHDP router, which replays the traffic. In a protocol >> where links are discovered by testing reception, this will result in >> extraneous link creation (basically, a "virtual link between the two >> Compromised NHDP routers will appear in the information bases of >> neighboring NHDP routers). > The packet capture, transfer and inject must be two-way before it has = a practical affect. That depends on the kind of traffic (e.g. UDP without application layer = ACK or response). >=20 >>=20 >> While this situation may result from an attack, it may also be >> intentional: if data-traffic also is relayed over the "virtual" = link, >> the link being detected is indeed valid for use. This is, for >> instance, used in wireless repeaters. If data traffic is not = carried >> over the virtual link, an imaginary, useless, link between the two >> Compromised NHDP routers, has been advertised, and is being recorded >> in the information bases of their neighboring NHDP routers. > Exactly. It is not the repeater characteristic what matters, but the = filters in forwarding. >=20 >>=20 >> Replay attacks can be especially damaging if coupled with spoofing >> and tampering with sequence numbers in the replayed messages, >> potentially destroying some important topology information in NHDP >> routers all over the network, as described in Section 4.5. > I don't see why replay is more damaging than false packet injection. >=20 > The difference is that replay attacks need additional protection = mechanisms (more than just signing). I think you already give a good reason why it's more damaging :-P >=20 >=20 >>=20 >> 4.6. Message Timing Attacks >>=20 >> In [RFC6130], each HELLO message contains a "validity time" and may >> contain an "interval time" field, identifying the time for which >> information in that control message should be considered valid until >> discarded, and the time until the next control message of the same >> type should be expected [RFC5497]. >>=20 >> 4.6.1. Interval Time Attack >>=20 >> A use of the expected interval between two successive HELLO messages >> is for determining the link quality in [RFC6130]: if messages are = not >> received within the expected intervals (e.g., a certain fraction of >> messages are missing), then this may be used to exclude a link from >> being considered as useful, even if (some) bi-directional >> communication has been verified. If a Compromised NHDP router X >> spoofs the identity of an existing NHDP router A, and sends HELLOs >> indicating a low interval time, an NHDP router B receiving this = HELLO >> will expect the following HELLO to arrive within the interval time >> indicated - or otherwise, decrease the link quality for the link = A-B. >> Thus, X may cause NHDP router B's estimate of the link quality for >> the link A-B to fall below the limit, where it is no longer >> considered as useful and, thus, not used. > This needs spoofing, I think. Why would an attacker take such a = difficult approach? It can declare the links as unusable directly. Yes, but sometimes more sophisticated attacks are more difficult to = detect. We don't make a judgement which is the best way to attack, just = try to be exhaustive on different attacks. >=20 >>=20 >> 4.6.2. Validity Time Attack >>=20 >> A Compromised NHDP router X can spoof the identity of an NHDP router >> A and send a HELLO using a low validity time (e.g.,1 ms). A >> receiving NHDP router B will discard the information upon expiration >> of that interval, i.e., a link between NHDP router A and B will be >> "torn down" by X. >=20 > (more general comment) I think the attacker can create messages, or = capture & replay. On the created messages, it can inject whatever. I'm = not sure the listed options are complete. Why such an in detail = description? At least, I would include a "any other false message" = section. We agree that the routers can declare the links as unusable directly.=20 One of the considerations here is the misconfiguration of certain = routers. We will make it more clear here.=20 >=20 >>=20 >> 4.7. Indirect Jamming >>=20 >> Indirect jamming is when a Compromised NHDP router X by its actions >> causes other legitimate NHDP routers to generate inordinate amounts >> of control traffic. This increases channel occupation, and the >> overhead in each receiving NHDP router processing this control >> traffic. With this traffic originating from Legitimate NHDP = routers, >> the malicious device may remain undetected to the wider network. > Yes, it may or may not be detected. I miss the message here :-) >=20 >>=20 >> Figure 3 illustrates indirect jamming of [RFC6130]. A Compromised >> NHDP router X advertises a symmetric spoofed link to the = non-existing >> NHDP router B (at time t0). Router A selects X as MPR upon = reception >> of the HELLO, and will trigger a HELLO at t1. Overhearing this >> triggered HELLO, the attacker sends another HELLO at t2, advertising >> the link to B as lost, which leads to NHDP router A deselecting the >> attacker as MPR, and another triggered message at t3. The cycle may >> be repeated, alternating advertising the link X-B as LOST and SYM. >>=20 >> MPRs(X) MPRs() >> .---. .---. .---. .---. >> | A | | A | | A | | A | >> '---' '---' '---' '---' >> | | | | >> | SYM(B) | | LOST(B) | >> | | | | >> .---. .---. .---. .---. >> | X | | X | | X | | X | >> '---' '---' '---' '---' >> . . >> . . >> . . >> ..... ..... >> . B . . B . >> ..... ..... >>=20 >> t0 t1 t2 t3 >>=20 >> Figure 3 >=20 > I don't get why the channel would be occupied. >=20 > When the attacker spoofs many identities and set up links with extreme = long validity time, the hello messages from affected routers would = increase to huge sizes. In a somewhat dense network, this can easily = overload the network. > Similar approach for TC messages and flooding. This example is not related to message size.=20 The Compromised router keep advertising different topology information = can have two possible results: increase the HELLO message generation = frequency, and additional resources for route calculation.=20 >=20 >>=20 >> 5. Impact of inconsistent Information Bases on Protocols using NHDP >>=20 >> This section describes the impact on protocols, using NHDP, of NHDP >> failing to obtain and represent accurate information, possibly as a >> consequence of the attacks described in Section 4. This description >> emphasizes the impacts on the MANET protocols OLSRv2 [OLSRv2], and >> SMF [SMF]. >>=20 >> 5.1. MPR Calculation > MPR calculation and flooding is not a task of NHDP. yes, that's why this section has the title "Impact of inconsistent = Information Bases on Protocols using NHDP". While MPR calculation and = flooding is not a task of NHDP, attacks on NHDP may have a severe impact = on protocols using it.=20 >=20 >=20 >> 5.1.3. Broadcast Storm > I use broadcast storm for a very different problem (STP problems). >=20 >>=20 >> 5.2. Routing Loops > Set up routes is not a task of NHDP. >=20 >>=20 >> 5.3. Invalid or Non-Existing Paths to Destinations > Set up routes is not a task of NHDP. >=20 >>=20 >> 5.4. Data Sinkhole > Set up routes is not a task of NHDP. This section is related to the scope of this document, which we have = been mentioned in a previous mail: = http://www.ietf.org/mail-archive/web/manet/current/msg12897.html ** The current revision of the document also includes a section for the = impacts on protocols using NHDP. The rationale is that, as a neighbor = discovery protocol, NHDP is used in combination with other protocols = most of the time. Therefore, the document describes how the those = protocols might be disrupted by the misbehavior of NHDP (in common = sense, such as MPR calculation, data sinkhole, etc. ). If we are going = to produce more threats documents in the future, there is no need to = worry about those common ones in NHDP (for example, we probably don't = want to discuss the threats in MPR selection in both SMF-threats and = OLSRv2-threats).=20 ** best Jiazi and Ulrich >=20 > Teco >=20 >=20 >>=20 >> best >>=20 >> Jiazi Yi >>=20 >> http://www.jiaziyi.com >> LIX, Ecole Polytechnique >> Route de Saclay 91128 Palaiseau Cedex France >>=20 >> On Jul 30, 2012, at 5:09 PM, Joseph Macker = wrote: >>=20 >>> I apologize to Jiazi and co-authors as we accidentally skipped one = of the slide sets at this afternoon's meeting. >>>=20 >>> Please review the slides for NHDP-sec-threats located at = http://tools.ietf.org/wg/manet/agenda >>> and see draft-ietf-manet-nhdp-sec-threats-00 >>>=20 >>> The authors are asking for consideration of WG LAST CALL on this = document so please comment. >>>=20 >>> -Joe >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From internet-drafts@ietf.org Tue Aug 28 16:25:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C001311E80E7; Tue, 28 Aug 2012 16:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmpqWiShMx+f; Tue, 28 Aug 2012 16:25:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C92211E810E; Tue, 28 Aug 2012 16:25:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120828232542.22892.6187.idtracker@ietfa.amsl.com> Date: Tue, 28 Aug 2012 16:25:42 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-mib-16.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 23:25:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Definition of Managed Objects for the Neighborhood Disco= very Protocol Author(s) : Ulrich Herberg Robert G. Cole Ian D Chakeres Filename : draft-ietf-manet-nhdp-mib-16.txt Pages : 67 Date : 2012-08-28 Abstract: This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-mib-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-mib-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Aug 28 16:37:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9419C11E811F; Tue, 28 Aug 2012 16:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3rnrHDvDNPW; Tue, 28 Aug 2012 16:37:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6A211E8119; Tue, 28 Aug 2012 16:37:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120828233758.18534.96547.idtracker@ietfa.amsl.com> Date: Tue, 28 Aug 2012 16:37:58 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-mib-17.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 23:37:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Definition of Managed Objects for the Neighborhood Disco= very Protocol Author(s) : Ulrich Herberg Robert G. Cole Ian D Chakeres Filename : draft-ietf-manet-nhdp-mib-17.txt Pages : 67 Date : 2012-08-28 Abstract: This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-mib-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-mib-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From abdussalambaryun@gmail.com Wed Aug 29 01:40:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517E221F8598 for ; Wed, 29 Aug 2012 01:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkUWCorZYnA3 for ; Wed, 29 Aug 2012 01:40:19 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 96DA721F84DA for ; Wed, 29 Aug 2012 01:40:19 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so398746vcb.31 for ; Wed, 29 Aug 2012 01:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=afDqQ86Ee+4swSsaBnyda1vRG+yBFglqwpl3VVBeb68=; b=mqIyYNXKLGkCTpMkkgrvpeZx6P8qJ5oMyUXLZxWYDljX+b3/WYac+/sqbHirVIumsc jYrCM1xyVnsBZaG/7ozz90KozX0qFgT2AlOJmat6zRjH1bbT9esUdEyjdCh9UfOhjJKw N1bynbuO/V7gHfJ1I2BtRFQ6EU5+JcqvNivLmzhGgcxQPK84s2rjXaV88+AcAjyNFI+w uhZJeAut31F46r0yYKPYuseeg/A4tIW0ajLOUifCp831AWR3TbYiWprnwgxODUiI8hDl e5uDvkiW0KYXB8uClxXS66fB59vZkRJThh+TAXp+Pyefr92vW6sQIB5zOszN6IekwhaK vfEg== MIME-Version: 1.0 Received: by 10.220.141.208 with SMTP id n16mr675303vcu.22.1346229618975; Wed, 29 Aug 2012 01:40:18 -0700 (PDT) Received: by 10.220.55.9 with HTTP; Wed, 29 Aug 2012 01:40:18 -0700 (PDT) In-Reply-To: <20120828233758.18534.96547.idtracker@ietfa.amsl.com> References: <20120828233758.18534.96547.idtracker@ietfa.amsl.com> Date: Wed, 29 Aug 2012 10:40:18 +0200 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-mib-17.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 08:40:20 -0000 +1, thanking you, AB On 8/29/12, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of > the IETF. > > Title : Definition of Managed Objects for the Neighborhood > Discovery Protocol > Author(s) : Ulrich Herberg > Robert G. Cole > Ian D Chakeres > Filename : draft-ietf-manet-nhdp-mib-17.txt > Pages : 67 > Date : 2012-08-28 > > Abstract: > This document defines a portion of the Management Information Base > (MIB) for use with network management protocols in the Internet > community. In particular, it describes objects for configuring > parameters of the Neighborhood Discovery Protocol (NHDP) process on a > router. The MIB module defined in this document, denoted NHDP-MIB, > also reports state, performance information and notifications about > NHDP. This additional state and performance information is useful to > troubleshoot problems and performance issues during neighbor > discovery. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-nhdp-mib-17 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-mib-17 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From henning.rogge@fkie.fraunhofer.de Wed Aug 29 02:02:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A11321F849B for ; Wed, 29 Aug 2012 02:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.754 X-Spam-Level: X-Spam-Status: No, score=-3.754 tagged_above=-999 required=5 tests=[AWL=2.495, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynH5DSxlMXyq for ; Wed, 29 Aug 2012 02:02:43 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3610221F8498 for ; Wed, 29 Aug 2012 02:02:43 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1T6eAG-0006Dg-RR for manet@ietf.org; Wed, 29 Aug 2012 11:02:20 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1T6eAG-0005jC-Oq for manet@ietf.org; Wed, 29 Aug 2012 11:02:20 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Aug 2012 11:02:20 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 29 Aug 2012 11:02:20 +0200 Message-ID: <503DDA95.1080500@fkie.fraunhofer.de> Date: Wed, 29 Aug 2012 11:02:13 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060907030105000201060006" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 29 Aug 2012 09:02:20.0588 (UTC) FILETIME=[FF3CEEC0:01CD85C4] X-Virus-Scanned: yes (ClamAV 0.97.5/15306/Tue Aug 28 21:18:12 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8dca1155c9df4b21e398d3fea9a098d5 Subject: Re: [manet] DLEP thoughts/questions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 09:02:46 -0000 --------------ms060907030105000201060006 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 08/20/2012 09:57 PM, Cheng, Bow-Nan - 0665 - MITLL wrote: > Hi all, Hi. There has been quite a lot of discussion about DLEP at Vancouver, Joe=20 Macker is right thats its a good time to get the discussion running on=20 this mailing list again. > I tried to filter through all the MANET list the past few months and > apologize if a few of these have been asked and resolved already.. > We've been working with DLEP and had a few thoughts/questions: > > * Connectionless radios (e.g. CSMA) - Currently DLEP is connection > based and expects the radio to detect link state changes and link > characteristic changes. If the radio does it detect these changes, > there is no session setup and no metrics exchanged. The issue arises > with radios that do not maintain a concept of a "link". For example, > 802.11 only exchanges link information when there's data to be sent. > Is there some thoughts on how to make DLEP more flexible to handle > radios that do not maintain this state, for example 802.11 based > radios. Perhaps, DLEP should be allow the server end to start > neighbor sessions instead of just the radio end. Like we discussed on this list, I think we could simplify DLEP to get=20 rid of the necessary sessions between the radio and the router. In the=20 simplest use-case this might lead to a radio just multicasting its known = data about interfaces and neighbors to the control-plane without even=20 knowing if a router is present. > * Multicast =96 Currently there is no way to handle radios that operate= > at different power/modulation rates for different types of multicast > traffic. At different power rates different multicast packets may be > able to reach different amounts of neighbors. > > In Draft 02, they say that you can use a multicast address to define > a neighbor. The question is do they expect that for every multicast > group in the network, a "neighbor session" will be established? This > can blow up quickly, but it does provide the possibility of doing > radios with multiple power modulation (I.e. Map a mcast group to a > certain power level). I think it might be necessary for DLEP to send a set of data for each=20 MAC address a local router can communicate with, including the default=20 broadcast MAC and optional multicast MAC addresses. This would allow a=20 transparent way to deliver data about multicast rates. > * Flow Control =96 Up until Draft 02 there has been no flow control and= > rate based control was assumed, which does not work well in shared > medium. Draft 02 added a paragraph about an optional credit based > flow control, similar to RFC4978. It is unclear how credit based flow > control will perform for a broadcast medium and some work is needed > to investigate a right approach. Maybe a pause frame flow control or > some sort of a hybrid approach is better suited. It might be a good idea to split the DLEP draft into multiple parts, so=20 we have a core document about "radio discovery and metric=20 transportation" and one about "set neighbor link characteristics and=20 flow control." I think flow control is really useful for DLEP capable radios, because=20 the router will have no information about the outgoing queue on the=20 radio (all data of the router will leave its outgoing queue through the=20 fast/gigabit ethernet interface!). I do not know if RFC 4978 is the=20 right way to do this on shared medium radio. > * Link Metrics - More work is needed on proper link metrics. Maybe > DLEP should be able to provide a core set of link metrics like it > does now but also allow for each radio to provide radio specific > metrics that a routing protocol may chose to take advantage of. Yes, we need a larger set of pre-defined metrics, some of them=20 mandatory, some of them optional. If every radio needs to create lots of = radio specific metrics, the usefulness of DLEP will be much less. > * Data and Control Paths =96 Currently DLEP only allows both data and > DLEP control plane packets to travel over the same interface. DLEP > needs to be more flexible to allow for the cases where data and > control plane need to be separated over different interfaces. I am not sure the current draft-02 talks about how the control path is=20 implemented. One option I had in mind for it was to use a VLAN-tag to=20 separate it from the bridged data path. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms060907030105000201060006 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA4MjkwOTAyMThaMCMGCSqGSIb3DQEJBDEWBBTGLEJ4ANT8f9wBpLHcvT8KxMm2ZzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAwdSzimf4dzbqpQUbNv8WaHiVMi2kE1KUxkCFIbQ/SEZG TAHRBSaLZeNGB+tiXaAi+89/yafj/YzAyX7twILD892gbsOeIdaVjB4NGJJh7imQ8TZDFgVJ mBeXAZzg8pxkcOUk9EtXk8H31HjHFMH9E5e1r9S5Sh+U4IF/vcAG1Ra2wKqtJgkHEBeZmCup E0ytzfY//1cSKzoF16Eq6cmAtcm3yoLRlpOOwPDBI8Qn1a4xDkaIGdXT5UMcQmym82dNyBwB c+xRx3v6kKh5mAo8Azw5A0ypMNAeZop72M4ct4w8GLdUth2xRwR1U5gPd7k9Tu5y+2jpfIjn S/LGbf81jwAAAAAAAA== --------------ms060907030105000201060006-- From abdussalambaryun@gmail.com Wed Aug 29 05:31:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E64821F86B5 for ; Wed, 29 Aug 2012 05:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCJOBwNh803v for ; Wed, 29 Aug 2012 05:31:49 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5215B21F867D for ; Wed, 29 Aug 2012 05:31:49 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so641173vbb.31 for ; Wed, 29 Aug 2012 05:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=n0+qzWpSlYWsiiRD3pBUQ3tz4pvQEIY7D2qkA7u0VQY=; b=QKcu8GZ54554cOjOl4G/Y7TG0jthrtpxr18hDa6WAqTT/yghuBx3mi5VwZonkqPJl4 vAkP/grUeDPg3hG60OOpaxV3MelILOFLedxLcqWtdFFWNAUOJH5Da1/3bhqGSB0qlTq+ MdcOokHJdAc9Q2ZfF7HIEaGK5N32D1jBTEGYG/Q3JEHqlnpsHMysvZ35YbT3q5eUbCpU ASKMHznI/lR9XWsh2dj/ZMI8wS6BwQ9cWs6SCnyM9SCmmQTjUVNI/A18ybpCK5fdsFrn AcdCToDv5RgNitOtVlWj8naMs24/0IKAG/0uBU96rqcHpZZNWX7OYriItFG9qsmsE41x RBuw== MIME-Version: 1.0 Received: by 10.58.89.168 with SMTP id bp8mr1106187veb.20.1346243508659; Wed, 29 Aug 2012 05:31:48 -0700 (PDT) Received: by 10.220.55.9 with HTTP; Wed, 29 Aug 2012 05:31:48 -0700 (PDT) In-Reply-To: <503DDA95.1080500@fkie.fraunhofer.de> References: <503DDA95.1080500@fkie.fraunhofer.de> Date: Wed, 29 Aug 2012 14:31:48 +0200 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] DLEP thoughts/questions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 12:31:50 -0000 Mostly agree with Henning, but not sure when the new draft will be published. I don't think I can discuss further until read new I-D or the authors decide on the WG concerns and many discussions/ideas related on the list. AB On 8/29/12, Henning Rogge wrote: > On 08/20/2012 09:57 PM, Cheng, Bow-Nan - 0665 - MITLL wrote: >> Hi all, > > Hi. > > There has been quite a lot of discussion about DLEP at Vancouver, Joe > Macker is right thats its a good time to get the discussion running on > this mailing list again. > >> I tried to filter through all the MANET list the past few months and >> apologize if a few of these have been asked and resolved already.. >> We've been working with DLEP and had a few thoughts/questions: >> >> * Connectionless radios (e.g. CSMA) - Currently DLEP is connection >> based and expects the radio to detect link state changes and link >> characteristic changes. If the radio does it detect these changes, >> there is no session setup and no metrics exchanged. The issue arises >> with radios that do not maintain a concept of a "link". For example, >> 802.11 only exchanges link information when there's data to be sent. >> Is there some thoughts on how to make DLEP more flexible to handle >> radios that do not maintain this state, for example 802.11 based >> radios. Perhaps, DLEP should be allow the server end to start >> neighbor sessions instead of just the radio end. > > Like we discussed on this list, I think we could simplify DLEP to get > rid of the necessary sessions between the radio and the router. In the > simplest use-case this might lead to a radio just multicasting its known > data about interfaces and neighbors to the control-plane without even > knowing if a router is present. > >> * Multicast =96 Currently there is no way to handle radios that operate >> at different power/modulation rates for different types of multicast >> traffic. At different power rates different multicast packets may be >> able to reach different amounts of neighbors. >> >> In Draft 02, they say that you can use a multicast address to define >> a neighbor. The question is do they expect that for every multicast >> group in the network, a "neighbor session" will be established? This >> can blow up quickly, but it does provide the possibility of doing >> radios with multiple power modulation (I.e. Map a mcast group to a >> certain power level). > > I think it might be necessary for DLEP to send a set of data for each > MAC address a local router can communicate with, including the default > broadcast MAC and optional multicast MAC addresses. This would allow a > transparent way to deliver data about multicast rates. > >> * Flow Control =96 Up until Draft 02 there has been no flow control and >> rate based control was assumed, which does not work well in shared >> medium. Draft 02 added a paragraph about an optional credit based >> flow control, similar to RFC4978. It is unclear how credit based flow >> control will perform for a broadcast medium and some work is needed >> to investigate a right approach. Maybe a pause frame flow control or >> some sort of a hybrid approach is better suited. > > It might be a good idea to split the DLEP draft into multiple parts, so > we have a core document about "radio discovery and metric > transportation" and one about "set neighbor link characteristics and > flow control." > > I think flow control is really useful for DLEP capable radios, because > the router will have no information about the outgoing queue on the > radio (all data of the router will leave its outgoing queue through the > fast/gigabit ethernet interface!). I do not know if RFC 4978 is the > right way to do this on shared medium radio. > >> * Link Metrics - More work is needed on proper link metrics. Maybe >> DLEP should be able to provide a core set of link metrics like it >> does now but also allow for each radio to provide radio specific >> metrics that a routing protocol may chose to take advantage of. > Yes, we need a larger set of pre-defined metrics, some of them > mandatory, some of them optional. If every radio needs to create lots of > radio specific metrics, the usefulness of DLEP will be much less. > >> * Data and Control Paths =96 Currently DLEP only allows both data and >> DLEP control plane packets to travel over the same interface. DLEP >> needs to be more flexible to allow for the cases where data and >> control plane need to be separated over different interfaces. > > I am not sure the current draft-02 talks about how the control path is > implemented. One option I had in mind for it was to use a VLAN-tag to > separate it from the bridged data path. > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > From internet-drafts@ietf.org Thu Aug 30 12:15:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9D521F85A8; Thu, 30 Aug 2012 12:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw7zQO-TV0xJ; Thu, 30 Aug 2012 12:15:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393FA21F8534; Thu, 30 Aug 2012 12:15:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> Date: Thu, 30 Aug 2012 12:15:52 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 19:15:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Dynamic Link Exchange Protocol (DLEP) Author(s) : Stan Ratliff Bo Berry Greg Harrison Darryl Satterwhite Shawn Jury Filename : draft-ietf-manet-dlep-03.txt Pages : 46 Date : 2012-08-30 Abstract: When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make forwarding decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-dlep-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dlep-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From abdussalambaryun@gmail.com Thu Aug 30 13:53:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF83A21F8525 for ; Thu, 30 Aug 2012 13:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ke744j12H-rD for ; Thu, 30 Aug 2012 13:53:44 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7AA21F84F6 for ; Thu, 30 Aug 2012 13:53:44 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2782107vbb.31 for ; Thu, 30 Aug 2012 13:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=daBgaWWfrQu1oillCvo1NM1HHRBFTOr0Q8FX95dTSso=; b=nbklex0eNyzB+FzGxqH7OopdxNykA1Q5tOmEI7qL0DY9o4r71m2pMGadqr9eWbwAS1 H+eOzP7CzIZag1Lat4crFVdmxxwk7VF3SpGhFyYwayVd9GPl1N3Icj9PDYarxojt0OvP vp4bTAk0VwCbgLCwj6nBiy1v6V9WiHNBvn9ixAirDo579T9yn4FyLKCVTIAYm3fQ7Hlr Sd0bBGAsNl/8SYXwaOarWqeo3ZXJpHmnvObXcNwF6RaCBEtdcrmUYR5k2fPDoJ/yHPXe rQrkxnF7A21AOGc4n8OTy8uokl59mSlDX1vTjPl3tV4wwMIZH7kxFhpp6OAiwtc1q+lw AjGw== MIME-Version: 1.0 Received: by 10.52.24.201 with SMTP id w9mr3335309vdf.125.1346360023727; Thu, 30 Aug 2012 13:53:43 -0700 (PDT) Received: by 10.220.55.9 with HTTP; Thu, 30 Aug 2012 13:53:43 -0700 (PDT) In-Reply-To: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> References: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> Date: Thu, 30 Aug 2012 21:53:43 +0100 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: multipart/alternative; boundary=bcaec5016207f43c3f04c881dec6 Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 20:53:46 -0000 --bcaec5016207f43c3f04c881dec6 Content-Type: text/plain; charset=ISO-8859-1 thanks, I will review and send my comments, and happy to discuss our previous issues and new draft. However, it seems that DLEP will not be using RFC5444-packet, AB On Thu, Aug 30, 2012 at 8:15 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of > the IETF. > > Title : Dynamic Link Exchange Protocol (DLEP) > Author(s) : Stan Ratliff > Bo Berry > Greg Harrison > Darryl Satterwhite > Shawn Jury > Filename : draft-ietf-manet-dlep-03.txt > Pages : 46 > Date : 2012-08-30 > > Abstract: > When routing devices rely on modems to effect communications over > wireless links, they need timely and accurate knowledge of the > characteristics of the link (speed, state, etc.) in order to make > forwarding decisions. In mobile or other environments where these > characteristics change frequently, manual configurations or the > inference of state through routing or transport protocols does not > allow the router to make the best decisions. A bidirectional, event- > driven communication channel between the router and the modem is > necessary. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-dlep-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --bcaec5016207f43c3f04c881dec6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
thanks, I will review and send my comments, and happy to discuss our p= revious issues and new draft. However, it seems that DLEP will not be using= RFC5444-packet,
=A0
AB

On Thu, Aug 30, 2012 at 8:15 PM, <internet-drafts@ietf.org>= wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Mobile Ad-hoc Networks Working Group of= the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Dynamic Link Exchange Protocol = (DLEP)
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Stan Ratliff
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bo Berry
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Greg Harrison
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Darryl Satterwhite
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Shawn Jury
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-manet-dlep-03.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 46
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-08-30

Abstract:
=A0 =A0When routing devices rely on modems to effect communications over =A0 =A0wireless links, they need timely and accurate knowledge of the
=A0 =A0characteristics of the link (speed, state, etc.) in order to make =A0 =A0forwarding decisions. In mobile or other environments where these =A0 =A0characteristics change frequently, manual configurations or the
=A0 =A0inference of state through routing or transport protocols does not =A0 =A0allow the router to make the best decisions. A bidirectional, event-=
=A0 =A0driven communication channel between the router and the modem is
=A0 =A0necessary.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-dlep-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dlep-03<= /a>


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--bcaec5016207f43c3f04c881dec6-- From abdussalambaryun@gmail.com Fri Aug 31 17:48:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE0A21F8472 for ; Fri, 31 Aug 2012 17:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vmCgYO8HZz6 for ; Fri, 31 Aug 2012 17:48:13 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 43C7921F8435 for ; Fri, 31 Aug 2012 17:48:13 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4304213vbb.31 for ; Fri, 31 Aug 2012 17:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=0j3cd5dDi0nKTWp+ojFpZ0X2e4Kqi+/6udUZ9zurGh0=; b=HzlifJTzHCrf5HihRJV48IvNj5gzRjFo1T0m2eMWVuG9NIZccx0jypAdDRBtILUsrA l5LOD0pBO9GNXeq0gqktKg4fcjFS7z0WSPWWjgygCDQgm70neQtFX8Us43gjC9Zw6k54 DJ7W7lReRSXqDXJ1JR3iDb0KQnSyH4DIJmiXuJxWU8kgCzcIZ8uRt9UAhZl1BpTfWyz8 sfH2c3rS2FEcG16D3sYfMOlPq/ZOKFOPwgaZyMd+MIyHE/YpuivABDveEPkvaULahdq+ 7H/TGh0ZAJs9kIzixjClXnHReVIGkYptkfavDcTzzF1t7XEOZO4uiMVZVgdbnGBDKWWj w87g== MIME-Version: 1.0 Received: by 10.221.10.13 with SMTP id oy13mr6970531vcb.14.1346460492611; Fri, 31 Aug 2012 17:48:12 -0700 (PDT) Received: by 10.220.55.9 with HTTP; Fri, 31 Aug 2012 17:48:12 -0700 (PDT) Date: Sat, 1 Sep 2012 02:48:12 +0200 Message-ID: From: Abdussalam Baryun To: ietf@thomasclausen.org Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Discussing LOADng suggestions/Reminder X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 00:48:14 -0000 +++++++++++++++ Third Reminder ++++++++++++++++ Hi Thomas, I have two emails (on 30 May and on 31 July, as below) of suggestions and questions not responded to, please your respond is important for progress and discussion on the list. I beleive the issue was also raised in the last WG meeting on 30 July, and the WG agrees to see discussion. Not sure if the authors are willing change the draft or not. AB === On 7/31/12, Abdussalam Baryun wrote: > Hi Thomas and All > > I am interested in LOADng and did discuss about it from May 2012 until > now. I gave comments [1] on LOADng but no respond so far, I asked from > before for more discussion but there was no, and hope that we don't > forget the past comments on any document in ietf. The LOADng SHOULD > specify use case that are related to MANET not LLN. I suggest that the > word LLN taken out of the name as well and specify mobility [1-2]. > > IMHO this protocol was intended as for ROLL WG not for MANET WG, but > then changed its direction to MANET [3]. However, please note that > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That > said, LOADng SHOULD specfy where is its limits. Then we can discuss > adoption. > > [1] http://www.ietf.org/mail-archive/web/manet/current/msg12924.html > [2] http://www.ietf.org/mail-archive/web/manet/current/msg12928.html > [3] http://www.ietf.org/mail-archive/web/manet/current/msg12933.html > > thanking you, > AB >> On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun >> wrote: >>> On 5/29/12, JP Vasseur wrote: >>>> >>>> We already have two different WG: MANET and ROLL. >>>> >>> >>> Yes we know. That is why LOADng authors should choose either to serve >>> LLN that is considered by ROLL WG or they choose serving MANET, and it >>> is considered by MANET WG. But the question is which suggestion option >>> do you think is better for LOADng-draft? >>> >>>>MANET is tasked, amongst other, to publish a reactive >>>>routing protocol. >>> >>> MANET is tasked to publish routing protocols that serve the MANET >>> network. IMO, MANET-WG is not tasked to publish protocols serving only >>> LLN just because the protocol is reactive. Please note that LOADng >>> protocol does not even mention MANET nor mobile routers in its draft, >>> which confuses its purpose, the authors should look into that. >>> >>> Abdussalam Baryun >> > From ietf@thomasclausen.org Fri Aug 31 18:06:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC5721F84F8 for ; Fri, 31 Aug 2012 18:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.068 X-Spam-Level: X-Spam-Status: No, score=-1.068 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxPlvx15vEyd for ; Fri, 31 Aug 2012 18:06:25 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 04FD821F84C5 for ; Fri, 31 Aug 2012 18:06:25 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 8CBEC558463 for ; Fri, 31 Aug 2012 18:06:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 060EA1C054F; Fri, 31 Aug 2012 18:06:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 7E58C1C04BC; Fri, 31 Aug 2012 18:06:22 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Sat, 1 Sep 2012 03:06:20 +0200 To: Abdussalam Baryun Cc: manet Subject: Re: [manet] Discussing LOADng suggestions/Reminder X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 01:06:25 -0000 You address me nominatively so I will respond - but, note that I am but one a= mong the authors. I believe that all the various feedback currently is being digested by the a= uthors - but, do not forget that August is vacation-week in good parts of Eu= rope, and some of us are only just coming back to the office. Best, Thomas --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees On 1 Sep 2012, at 02:48, Abdussalam Baryun wrot= e: > +++++++++++++++ Third Reminder ++++++++++++++++ >=20 > Hi Thomas, >=20 > I have two emails (on 30 May and on 31 July, as below) of suggestions > and questions not responded to, please your respond is important for > progress and discussion on the list. I beleive the issue was also > raised in the last WG meeting on 30 July, and the WG agrees to see > discussion. Not sure if the authors are willing change the draft or > not. >=20 > AB > =3D=3D=3D > On 7/31/12, Abdussalam Baryun wrote: >> Hi Thomas and All >>=20 >> I am interested in LOADng and did discuss about it from May 2012 until >> now. I gave comments [1] on LOADng but no respond so far, I asked from >> before for more discussion but there was no, and hope that we don't >> forget the past comments on any document in ietf. The LOADng SHOULD >> specify use case that are related to MANET not LLN. I suggest that the >> word LLN taken out of the name as well and specify mobility [1-2]. >>=20 >> IMHO this protocol was intended as for ROLL WG not for MANET WG, but >> then changed its direction to MANET [3]. However, please note that >> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >> said, LOADng SHOULD specfy where is its limits. Then we can discuss >> adoption. >>=20 >> [1] http://www.ietf.org/mail-archive/web/manet/current/msg12924.html >> [2] http://www.ietf.org/mail-archive/web/manet/current/msg12928.html >> [3] http://www.ietf.org/mail-archive/web/manet/current/msg12933.html >>=20 >> thanking you, >> AB >>> On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun >>> wrote: >>>> On 5/29/12, JP Vasseur wrote: >>>>>=20 >>>>> We already have two different WG: MANET and ROLL. >>>>>=20 >>>>=20 >>>> Yes we know. That is why LOADng authors should choose either to serve >>>> LLN that is considered by ROLL WG or they choose serving MANET, and it >>>> is considered by MANET WG. But the question is which suggestion option >>>> do you think is better for LOADng-draft? >>>>=20 >>>>> MANET is tasked, amongst other, to publish a reactive >>>>> routing protocol. >>>>=20 >>>> MANET is tasked to publish routing protocols that serve the MANET >>>> network. IMO, MANET-WG is not tasked to publish protocols serving only >>>> LLN just because the protocol is reactive. Please note that LOADng >>>> protocol does not even mention MANET nor mobile routers in its draft, >>>> which confuses its purpose, the authors should look into that. >>>>=20 >>>> Abdussalam Baryun >>>=20 >>=20


=
=A0
However, some specifics relating to sequenc= e numbers.
=A0
If the attacking node sent control packets wit= h random sequence numbers,