From root@core3.amsl.com Fri May 1 14:45:01 2009 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 374103A6C1C; Fri, 1 May 2009 14:45:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090501214501.374103A6C1C@core3.amsl.com> Date: Fri, 1 May 2009 14:45:01 -0700 (PDT) Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-smf-mib-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 21:45:01 -0000 --NextPart 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 Manet Simplified Multicast Framework Relay Set Process Author(s) : R. Cole, J. Macker, B. Adamson, S. Harnedy Filename : draft-ietf-manet-smf-mib-00.txt Pages : 44 Date : 2009-4-24 This memo 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 aspects of the Simplified Multicast Forwarding (SMF) process. The SMF MIB also reports state information, performance metrics, and notifications. In addition to configuration, this additional state and performance information is useful to management stations troubleshooting multicast forwarding problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-mib-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-manet-smf-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-5-1144405.I-D@ietf.org> --NextPart-- From ogier@earthlink.net Fri May 1 15:00:15 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8933A6D96 for ; Fri, 1 May 2009 15:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.595, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHYGVGIPv4Wu for ; Fri, 1 May 2009 15:00:13 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 924B63A6929 for ; Fri, 1 May 2009 15:00:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=e0zUI/Wx4nkjJ/3xlNVg3inmw6HO0SWJ+nRxjWDw2jTnqJh6Nfl0CqL13jYp+bUs; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.222.138] by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M00nQ-0003ni-9f; Fri, 01 May 2009 18:01:30 -0400 Message-ID: <49FB71FE.3090708@earthlink.net> Date: Fri, 01 May 2009 15:04:46 -0700 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Teco Boot References: <004c01c9c3fb$ac973c90$05c5b5b0$@nl> <000b01c9c899$a52e0d60$ef8a2820$@nl> In-Reply-To: <000b01c9c899$a52e0d60$ef8a2820$@nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478594a5b3a834a310eccfd30f602cf0a5a7005d68ee1e768b9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.222.138 Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] OLSRv2 - suggestions for enhancing message forwarding X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 22:00:15 -0000 Teco Boot wrote: >On the second case, think of: > - There is no symmetric neighbor on this interface > - There is only one symmetric neighbor on this interface, > and the to be relayed message was received on this interface > - All neighbors on this interface report full connectivity > to all other neighbors on this interface, and the to be > relayed message was received on this interface >The check is: does relay the message on this interface results to >reception on a node, that did not received the message before? >If the answer is no, the message SHOULD NOT be relayed on this >interface. Looks like a no-brainer to me. > > Indeed this is a no-brainer, and OSPF-MDR does this. At first, I didn't think it would help much with MPRs, since no MPRs would be selected in the cases you mention above if there is only a single interface. However, if there are two interfaces then there can be lots of MPRs. For example, suppose a MANET has 100 nodes that are all neighbors of each other, and suppose each node also has another interface that is connected to a local network. Then the MPR properties in Section 14 imply that every node must select every other node as an MPR! Furthermore, if one of the nodes originates a TC message, then the other 99 nodes must forward the TC message on both interfaces! Wow. It's good that you pointed this out before the RFC is published. Obviously something needs to be changed. Personally, I prefer your scheme that uses multiple MPR types, so that in the above example, all MPRs would be of type MPR_other_interfaces. But the above check should be done anyway, in case some routers choose not to use multiple MPR types. Richard >There is no need for mathematical proof for the enhanced MPR >selection mechanism, as it complies with the MPR selection >criteria. It is just more selective. > > >>For each OLSRv2 interface a router MUST select a set of MPRs. This >>set MUST have the properties that: >> >>o All of the selected MPRs are willing symmetric 1-hop neighbors, >> AND; >> >>o If the selecting router sends a message on that OLSRv2 interface, >> and that message is successfully forwarded by all of the selected >> MPRs for that interface, then all symmetric strict 2-hop neighbors >> of the selecting router through that OLSRv2 interface will receive >> that message on a symmetric link. >> >> > >Maybe there is an additional requirement for MPR selection that I am >not aware of. In that case, it shall be added in the draft. > >If not, I prefer modifying the OLSRv2 mechanism for supporting the 4 mode >MPR selection status. Nodes are free to use it or not; i.e. use only the >no_MPR and >MPR_all_interfaces. >Populating the Advertised Neighbor Set is not affected, all MPR selectors >must be included; i.e. MPR_this_interface, MPR_other_interfaces and >MPR_all_interfaces. > > >Teco. > > >| >|I'm afraid I'm not going to work through your second case. >|I'm not interested in ad hoc "this might work" modifications >|of the MPR flooding until backed by a mathematical proof that >|there are no problems. We've seen enough examples of ideas >|that look plausible but actually fail. >| >|-- >|Christopher Dearlove >|Technology Leader, Communications Group >|Networks, Security and Information Systems Department >|BAE Systems Advanced Technology Centre >|West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >|Tel: +44 1245 242194 Fax: +44 1245 242124 >| >|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 Teco Boot >|Sent: 23 April 2009 11:10 >|To: manet@ietf.org >|Subject: [manet] OLSRv2 - suggestions for enhancing message forwarding >| >| >| *** WARNING *** >| >| This message has originated outside your organisation, >| either from an external partner or the Global Internet. >| Keep this in mind if you answer this message. >| >| >|Here two suggestions for enhancing message forwarding: >| >| >|Missed 1-hop TC: >|================ >| >|If the following condition for a received message is true: >| >| msg-orig-addr is a MPR selector, >| source address of message is not MPR selector, >| message is not seen before, >| >|the message is discarded. However, this is a message that >|should have been received, or is to be received soon. Repair >|of loss of messages sent from a first hop neighbors could be >|beneficial for loop prevention. >| >|Suggested change: relay such a message. >| >| >| >|Eliminate useless relaying: >|=========================== >| >|If the relaying node has the same set of symmetric neighbors >|or a subset symmetric neighbors on this link than the MPR >|selector, relaying messages received from this MPR selector >|on this link is not useful. >| >|Suggested change: Do not relay messages from such a MPR >|selector on the link which the message was received on. >| >|Alternative approach: >| o Introduce manually configured interface type: >| full-connected [ no | yes ] >| o Enhance MPR selection and signaling algorithm, >| with MPR types: >| [ no_MPR | MPR_this_interface | >| MPR_other_interfaces | MPR_all_interfaces ] >| MPR selection shall guarantee that all 2-hop neighbors >| receive the message at least once. >| >|Here a scenario where the enhanced MPR selection would >|benefit a lot: >| >| >| **R7 >| * >| ________R4 >| / / >| R1-----------R2-------\ >|** \ |* | >|* \ | *R10 | >|* \ | | >|* -----R3-------R5**R8 >|R9 * >| **R6 >| >|Lines: low bandwidth - long reach, e.g. UHF low >|Asterisks: high bandwidth - short range, e.g. UHF high >| >|On |-segment, R1 selects R2 as MPR_all_interfaces and (R4, R3) as >|MPR_other_interfaces. R2 selects (R1, R3, R4, R5) as >|MPR_other_interfaces. >| >|Scenario: R9 sends TC message. >|R1 relays TC. >|R4, R2 and R3 receive this TC in parallel, all relay >| on *-interface. Only R2 relays on |-interface. >|R5 receives TC from R2 and relays on *-interface only. >| >|The TC is sent 2 times (instead of 5) on the |-segment. >| >| >|Thoughts? >| >|Teco. >| >| >| >|_______________________________________________ >|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 teco@inf-net.nl Sat May 2 00:27:42 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F52C3A6B06 for ; Sat, 2 May 2009 00:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZEU5KhMFxge for ; Sat, 2 May 2009 00:27:41 -0700 (PDT) Received: from CPSMTPM-EML105.kpnxchange.com (cpsmtpm-eml105.kpnxchange.com [195.121.3.9]) by core3.amsl.com (Postfix) with ESMTP id 9F8443A6CFD for ; Sat, 2 May 2009 00:26:35 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML105.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Sat, 2 May 2009 09:27:57 +0200 From: "Teco Boot" To: "'Richard Ogier'" References: <004c01c9c3fb$ac973c90$05c5b5b0$@nl> <000b01c9c899$a52e0d60$ef8a2820$@nl> <49FB71FE.3090708@earthlink.net> In-Reply-To: <49FB71FE.3090708@earthlink.net> Date: Sat, 2 May 2009 09:27:46 +0200 Message-ID: <004001c9caf7$7df682d0$79e38870$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnKqIdMveO97cjwSOaUX/HBVIQ9gAAThkCA Content-Language: nl X-OriginalArrivalTime: 02 May 2009 07:27:58.0746 (UTC) FILETIME=[849E27A0:01C9CAF7] Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] OLSRv2 - suggestions for enhancing message forwarding X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 07:27:42 -0000 Thanks for the support. Yes, in some scenarios the enhancement is very helpful. I think it is important. FYI, recent olsr.org code supports a manual configured interface type, similar to ospf interface types "manet" and "broadcast". My proposal does not need configuration and works better. At cost of (optional) slightly increased signaling and the logic for selecting the 3 types of MPRs (also optional). Teco. |-----Oorspronkelijk bericht----- |Van: Richard Ogier [mailto:ogier@earthlink.net] |Verzonden: zaterdag 2 mei 2009 0:05 |Aan: Teco Boot |CC: 'Dearlove, Christopher (UK)'; manet@ietf.org |Onderwerp: Re: [manet] OLSRv2 - suggestions for enhancing message |forwarding | |Teco Boot wrote: | |>On the second case, think of: |> - There is no symmetric neighbor on this interface |> - There is only one symmetric neighbor on this interface, |> and the to be relayed message was received on this interface |> - All neighbors on this interface report full connectivity |> to all other neighbors on this interface, and the to be |> relayed message was received on this interface |>The check is: does relay the message on this interface results to |>reception on a node, that did not received the message before? |>If the answer is no, the message SHOULD NOT be relayed on this |>interface. Looks like a no-brainer to me. |> |> | |Indeed this is a no-brainer, and OSPF-MDR does this. At first, I didn't |think it would help much with MPRs, since no MPRs would be selected in |the cases you mention above if there is only a single interface. |However, if there are two interfaces then there can be lots of MPRs. |For example, suppose a MANET has 100 nodes that are all neighbors |of each other, and suppose each node also has another interface that |is connected to a local network. Then the MPR properties in Section 14 |imply that every node must select every other node as an MPR! |Furthermore, if one of the nodes originates a TC message, then the |other 99 nodes must forward the TC message on both interfaces! |Wow. It's good that you pointed this out before the RFC is published. | |Obviously something needs to be changed. Personally, I prefer your |scheme that uses multiple MPR types, so that in the above example, |all MPRs would be of type MPR_other_interfaces. But the above |check should be done anyway, in case some routers choose not to |use multiple MPR types. | |Richard | |>There is no need for mathematical proof for the enhanced MPR |>selection mechanism, as it complies with the MPR selection |>criteria. It is just more selective. |> |> |>>For each OLSRv2 interface a router MUST select a set of MPRs. This |>>set MUST have the properties that: |>> |>>o All of the selected MPRs are willing symmetric 1-hop neighbors, |>> AND; |>> |>>o If the selecting router sends a message on that OLSRv2 interface, |>> and that message is successfully forwarded by all of the selected |>> MPRs for that interface, then all symmetric strict 2-hop neighbors |>> of the selecting router through that OLSRv2 interface will receive |>> that message on a symmetric link. |>> |>> |> |>Maybe there is an additional requirement for MPR selection that I am |>not aware of. In that case, it shall be added in the draft. |> |>If not, I prefer modifying the OLSRv2 mechanism for supporting the 4 |mode |>MPR selection status. Nodes are free to use it or not; i.e. use only |the |>no_MPR and |>MPR_all_interfaces. |>Populating the Advertised Neighbor Set is not affected, all MPR |selectors |>must be included; i.e. MPR_this_interface, MPR_other_interfaces and |>MPR_all_interfaces. |> |> |>Teco. |> |> |>| |>|I'm afraid I'm not going to work through your second case. |>|I'm not interested in ad hoc "this might work" modifications |>|of the MPR flooding until backed by a mathematical proof that |>|there are no problems. We've seen enough examples of ideas |>|that look plausible but actually fail. |>| |>|-- |>|Christopher Dearlove |>|Technology Leader, Communications Group |>|Networks, Security and Information Systems Department |>|BAE Systems Advanced Technology Centre |>|West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK |>|Tel: +44 1245 242194 Fax: +44 1245 242124 |>| |>|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 Teco Boot |>|Sent: 23 April 2009 11:10 |>|To: manet@ietf.org |>|Subject: [manet] OLSRv2 - suggestions for enhancing message forwarding |>| |>| |>| *** WARNING *** |>| |>| This message has originated outside your organisation, |>| either from an external partner or the Global Internet. |>| Keep this in mind if you answer this message. |>| |>| |>|Here two suggestions for enhancing message forwarding: |>| |>| |>|Missed 1-hop TC: |>|================ |>| |>|If the following condition for a received message is true: |>| |>| msg-orig-addr is a MPR selector, |>| source address of message is not MPR selector, |>| message is not seen before, |>| |>|the message is discarded. However, this is a message that |>|should have been received, or is to be received soon. Repair |>|of loss of messages sent from a first hop neighbors could be |>|beneficial for loop prevention. |>| |>|Suggested change: relay such a message. |>| |>| |>| |>|Eliminate useless relaying: |>|=========================== |>| |>|If the relaying node has the same set of symmetric neighbors |>|or a subset symmetric neighbors on this link than the MPR |>|selector, relaying messages received from this MPR selector |>|on this link is not useful. |>| |>|Suggested change: Do not relay messages from such a MPR |>|selector on the link which the message was received on. |>| |>|Alternative approach: |>| o Introduce manually configured interface type: |>| full-connected [ no | yes ] |>| o Enhance MPR selection and signaling algorithm, |>| with MPR types: |>| [ no_MPR | MPR_this_interface | |>| MPR_other_interfaces | MPR_all_interfaces ] |>| MPR selection shall guarantee that all 2-hop neighbors |>| receive the message at least once. |>| |>|Here a scenario where the enhanced MPR selection would |>|benefit a lot: |>| |>| |>| **R7 |>| * |>| ________R4 |>| / / |>| R1-----------R2-------\ |>|** \ |* | |>|* \ | *R10 | |>|* \ | | |>|* -----R3-------R5**R8 |>|R9 * |>| **R6 |>| |>|Lines: low bandwidth - long reach, e.g. UHF low |>|Asterisks: high bandwidth - short range, e.g. UHF high |>| |>|On |-segment, R1 selects R2 as MPR_all_interfaces and (R4, R3) as |>|MPR_other_interfaces. R2 selects (R1, R3, R4, R5) as |>|MPR_other_interfaces. |>| |>|Scenario: R9 sends TC message. |>|R1 relays TC. |>|R4, R2 and R3 receive this TC in parallel, all relay |>| on *-interface. Only R2 relays on |-interface. |>|R5 receives TC from R2 and relays on *-interface only. |>| |>|The TC is sent 2 times (instead of 5) on the |-segment. |>| |>| |>|Thoughts? |>| |>|Teco. |>| |>| |>| |>|_______________________________________________ |>|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 hrogge@googlemail.com Sat May 2 00:33:12 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83A9F3A6C43 for ; Sat, 2 May 2009 00:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9jibL4QuoqA for ; Sat, 2 May 2009 00:33:11 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 5CF133A689B for ; Sat, 2 May 2009 00:33:10 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so639801eyd.31 for ; Sat, 02 May 2009 00:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=VugxXL59QPxO23hti9MWqqvyPT/RKdp5y5TjlfkIkAc=; b=vXYt7XDLhouwHp7L+ohyA0Cqvz0zIMimuSVXj3zvivjau3uvOrmLMmdMfNlldb+iAg O3Tu2MT1itIwyLdGSy1aVl+JEE1ypdaDgm0NY3KZfA8TcL7shFnzHmRaF0HSY8EJZJxC UCyiOK06dDaDKM0xwBkT+JS1S/uK81/vLhJ8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=I/pvArfKgYOdWJ2YYrQFxrnQhilzbh8pi9kRPjIHMZQAS1m/W5Z3YulwoP+iaP889d GLUwQhlUG2Ibe8KoJ1e8ufsBEHud3C3k3fDDJKWlU+g4kbCHjBOUm5+RynO5qDeYp+On 472DY1bVtnQWGesvaCKqPUV9cbqu0G1wzwiKQ= Received: by 10.210.51.18 with SMTP id y18mr444726eby.22.1241249674434; Sat, 02 May 2009 00:34:34 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 28sm7155317eye.6.2009.05.02.00.34.33 (version=SSLv3 cipher=RC4-MD5); Sat, 02 May 2009 00:34:33 -0700 (PDT) From: Henning Rogge To: manet@ietf.org Date: Sat, 2 May 2009 09:34:27 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.29-gentoo-r1; KDE/4.2.2; x86_64; ; ) References: <004c01c9c3fb$ac973c90$05c5b5b0$@nl> <49FB71FE.3090708@earthlink.net> <004001c9caf7$7df682d0$79e38870$@nl> In-Reply-To: <004001c9caf7$7df682d0$79e38870$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart37617735.UqILPhc8Le"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200905020934.32666.hrogge@googlemail.com> Cc: "'Dearlove, Christopher \(UK\)'" , 'Richard Ogier' Subject: Re: [manet] OLSRv2 - suggestions for enhancing message forwarding X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 07:33:12 -0000 --nextPart37617735.UqILPhc8Le Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Samstag 02 Mai 2009 09:27:46 Teco Boot wrote: > Thanks for the support. > Yes, in some scenarios the enhancement is very helpful. I think it is > important. > FYI, recent olsr.org code supports a manual configured interface type, > similar to ospf interface types "manet" and "broadcast". > My proposal does not need configuration and works better. At cost of > (optional) slightly increased signaling and the logic for selecting the 3 > types of MPRs (also optional). > Teco. The idea behind this "interface mode" is that Freifunk/Funkfeuer networks=20 often have several 1-mac80211-interface routers connected by ethernet. Beca= use=20 ethernet has a closed broadcast domain, you don't need to send a received O= LSR=20 package from the ethernet interface back into it (everyone already got it). Henning --nextPart37617735.UqILPhc8Le Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkn794gACgkQcenvcwAcHWdl0ACeP0B636LBFP+iBvJnm650N/cH SzUAn1ppkLCGPLxlZzh5Tj+A0QoHsqX5 =aiRp -----END PGP SIGNATURE----- --nextPart37617735.UqILPhc8Le-- From teco@inf-net.nl Sat May 2 03:36:08 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D1F28C22D for ; Sat, 2 May 2009 03:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsWKvsRuE3l6 for ; Sat, 2 May 2009 03:36:07 -0700 (PDT) Received: from CPSMTPM-EML104.kpnxchange.com (cpsmtpm-eml104.kpnxchange.com [195.121.3.8]) by core3.amsl.com (Postfix) with ESMTP id 667253A6C62 for ; Sat, 2 May 2009 03:35:36 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Sat, 2 May 2009 12:36:53 +0200 From: "Teco Boot" To: "'Henning Rogge'" , References: <004c01c9c3fb$ac973c90$05c5b5b0$@nl> <49FB71FE.3090708@earthlink.net> <004001c9caf7$7df682d0$79e38870$@nl> <200905020934.32666.hrogge@googlemail.com> In-Reply-To: <200905020934.32666.hrogge@googlemail.com> Date: Sat, 2 May 2009 12:36:42 +0200 Message-ID: <004801c9cb11$e2ed12c0$a8c73840$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnK+INHCSMh22j1SyG7Eo/uqTEgagAGBC2Q Content-Language: nl X-OriginalArrivalTime: 02 May 2009 10:36:54.0908 (UTC) FILETIME=[E97F33C0:01C9CB11] Cc: "'Dearlove, Christopher \(UK\)'" , 'Richard Ogier' Subject: Re: [manet] OLSRv2 - suggestions for enhancing message forwarding X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 10:36:08 -0000 This is the classical "back-to-back radio relay" topology, that is often used in military networks. The enhancement is not that important for Ethernets, as there would not be a constraint in capacity. Where a wireless segment connects many of these clustered routers, all routers on the segment become MPR, for both the Ethernet and "back to the wireless segment" interfaces. Here, the unneeded overhead is unacceptable, especially where low capacity - long range radios are used in a segment with large number of the clustered routers. My proposal makes the "interface type" self-learning. Teco. |-----Oorspronkelijk bericht----- |Van: Henning Rogge [mailto:hrogge@googlemail.com] |Verzonden: zaterdag 2 mei 2009 9:34 |Aan: manet@ietf.org |CC: Teco Boot; 'Richard Ogier'; 'Dearlove, Christopher (UK)' |Onderwerp: Re: [manet] OLSRv2 - suggestions for enhancing message |forwarding | |On Samstag 02 Mai 2009 09:27:46 Teco Boot wrote: |> Thanks for the support. |> Yes, in some scenarios the enhancement is very helpful. I think it is |> important. |> FYI, recent olsr.org code supports a manual configured interface type, |> similar to ospf interface types "manet" and "broadcast". |> My proposal does not need configuration and works better. At cost of |> (optional) slightly increased signaling and the logic for selecting |the 3 |> types of MPRs (also optional). |> Teco. |The idea behind this "interface mode" is that Freifunk/Funkfeuer |networks |often have several 1-mac80211-interface routers connected by ethernet. |Because |ethernet has a closed broadcast domain, you don't need to send a |received OLSR |package from the ethernet interface back into it (everyone already got |it). | |Henning From ogier@earthlink.net Sat May 2 10:20:31 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5CFD3A6DB1 for ; Sat, 2 May 2009 10:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pZaUSwk7a1M for ; Sat, 2 May 2009 10:20:31 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 6B07528C1AF for ; Sat, 2 May 2009 10:20:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=XmEnhxwNRD7CAKUJqvkEv0EmgdKuDACSBjwgSeHQeAGncfjvTUEZF/yorst3NxCB; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.219.237] by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M0IuI-0005yv-RQ; Sat, 02 May 2009 13:21:47 -0400 Message-ID: <49FC81F2.40809@earthlink.net> Date: Sat, 02 May 2009 10:25:06 -0700 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Teco Boot References: <004c01c9c3fb$ac973c90$05c5b5b0$@nl> <49FB71FE.3090708@earthlink.net> <004001c9caf7$7df682d0$79e38870$@nl> <200905020934.32666.hrogge@googlemail.com> <004801c9cb11$e2ed12c0$a8c73840$@nl> In-Reply-To: <004801c9cb11$e2ed12c0$a8c73840$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478594a5b3a834a310e9e7088c528b19def88c5e02fb7e58e86350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.219.237 Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] OLSRv2 - suggestions for enhancing message forwarding X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 17:20:31 -0000 Teco Boot wrote: >This is the classical "back-to-back radio relay" topology, >that is often used in military networks. The enhancement >is not that important for Ethernets, as there would not be >a constraint in capacity. >Where a wireless segment connects many of these clustered >routers, all routers on the segment become MPR, for both >the Ethernet and "back to the wireless segment" interfaces. >Here, the unneeded overhead is unacceptable, especially where >low capacity - long range radios are used in a segment with >large number of the clustered routers. > >My proposal makes the "interface type" self-learning. > Absolutely. Often it won't be known in advance whether a MANET will form a single hop network (with diameter 1). But even if the MANET has diameter 2, routers that are not on the edge will still have a neighbor set that includes all other routers on the MANET segment, so both of the proposed modifications will still help a lot. Moreover, the scheme with multiple MPR types can be very helpful even if the MANET segment has a large diameter. This is because each MANET router will still select all MANET neighbors as MPRs (because of the Ethernet interfaces). With the proposed scheme, only a few of these neighbors will be of type MPR_all_interfaces, and the rest will be of type MPR_other_interfaces. Richard From Chris.Dearlove@baesystems.com Tue May 5 01:29:59 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DBE3A700C for ; Tue, 5 May 2009 01:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.785 X-Spam-Level: X-Spam-Status: No, score=-3.785 tagged_above=-999 required=5 tests=[AWL=-2.675, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KirkwOtRT1+9 for ; Tue, 5 May 2009 01:29:58 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 790123A6C2E for ; Tue, 5 May 2009 01:29:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,296,1238972400"; d="scan'208";a="803739" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 05 May 2009 09:31:24 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n458VNYY019596; Tue, 5 May 2009 09:31:23 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 09:31:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 5 May 2009 09:31:09 +0100 Message-ID: In-Reply-To: <49FB71FE.3090708@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - suggestions for enhancing message forwarding Thread-Index: AcnKqGdsM8mVbQzyQnOyPTL9eM2PxQCsrqNw References: <004c01c9c3fb$ac973c90$05c5b5b0$@nl> <000b01c9c899$a52e0d60$ef8a2820$@nl> <49FB71FE.3090708@earthlink.net> From: "Dearlove, Christopher (UK)" To: "Richard Ogier" , "Teco Boot" X-OriginalArrivalTime: 05 May 2009 08:31:23.0481 (UTC) FILETIME=[DFA7E490:01C9CD5B] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - suggestions for enhancing message forwarding X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 08:29:59 -0000 > For example, suppose a MANET has 100 nodes that are all neighbors > of each other, and suppose each node also has another interface that > is connected to a local network. Then the MPR properties in Section 14 > imply that every node must select every other node as an MPR! Nonsense. Each node advertises that local interface as a local non-MANET interface, and then no node has any strict two hop neighbours, and no MPRs are selected. ******************************************************************** 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 Tue May 5 23:18:19 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69BF3A6B0F for ; Tue, 5 May 2009 23:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOvVAzz0Ib0y for ; Tue, 5 May 2009 23:18:18 -0700 (PDT) Received: from CPSMTPM-EML103.kpnxchange.com (cpsmtpm-eml103.kpnxchange.com [195.121.3.7]) by core3.amsl.com (Postfix) with ESMTP id 926403A6A08 for ; Tue, 5 May 2009 23:18:17 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML103.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 6 May 2009 08:19:44 +0200 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" References: <004c01c9c3fb$ac973c90$05c5b5b0$@nl> <000b01c9c899$a52e0d60$ef8a2820$@nl> <49FB71FE.3090708@earthlink.net> In-Reply-To: Date: Wed, 6 May 2009 08:19:38 +0200 Message-ID: <009801c9ce12$a26570e0$e73052a0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnKqGdsM8mVbQzyQnOyPTL9eM2PxQCsrqNwAC2Jo7A= Content-Language: nl X-OriginalArrivalTime: 06 May 2009 06:19:44.0072 (UTC) FILETIME=[A5A77C80:01C9CE12] Cc: 'Richard Ogier' , manet@ietf.org Subject: Re: [manet] OLSRv2 - suggestions for enhancing message forwarding X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 06:18:19 -0000 |> For example, suppose a MANET has 100 nodes that are all neighbors |> of each other, and suppose each node also has another interface that |> is connected to a local network. Then the MPR properties in Section 14 |> imply that every node must select every other node as an MPR! | |Nonsense. Each node advertises that local interface as a local |non-MANET interface, and then no node has any strict two hop |neighbours, and no MPRs are selected. It depends. When the local interface is used for attachment of other MANET routers, then of course it shall be configured as a MANET interface. If it is a MANET interface, and no other MANET router is attached, there is no 2-hop neighbor on it and thus it does not affect MPR selection. Why did you think so? This MANET interface without a connected MANET router is an example of useless relaying, when the MANET router was selected as MPR. I suggested an enhancement that relaying only takes place to MANET interfaces that have symmetric neighbor(s). Teco. From Chris.Dearlove@baesystems.com Wed May 6 01:34:22 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D8F53A6D85 for ; Wed, 6 May 2009 01:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.493 X-Spam-Level: X-Spam-Status: No, score=-4.493 tagged_above=-999 required=5 tests=[AWL=-1.894, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjeNRHW8y0c8 for ; Wed, 6 May 2009 01:34:21 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id B3F313A6E1C for ; Wed, 6 May 2009 01:33:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,301,1238972400"; d="scan'208";a="1010537" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 06 May 2009 09:35:06 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n468Z6fl031884; Wed, 6 May 2009 09:35:06 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 09:35:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 6 May 2009 09:34:33 +0100 Message-ID: In-Reply-To: <009801c9ce12$a26570e0$e73052a0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - suggestions for enhancing message forwarding Thread-Index: AcnKqGdsM8mVbQzyQnOyPTL9eM2PxQCsrqNwAC2Jo7AABPSmsA== References: <004c01c9c3fb$ac973c90$05c5b5b0$@nl> <000b01c9c899$a52e0d60$ef8a2820$@nl><49FB71FE.3090708@earthlink.net> <009801c9ce12$a26570e0$e73052a0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" X-OriginalArrivalTime: 06 May 2009 08:35:06.0341 (UTC) FILETIME=[8EE76150:01C9CE25] Cc: Richard Ogier , manet@ietf.org Subject: Re: [manet] OLSRv2 - suggestions for enhancing message forwarding X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 08:34:22 -0000 >|> For example, suppose a MANET has 100 nodes that are all neighbors >|> of each other, and suppose each node also has another interface that >|> is connected to a local network. Then the MPR properties in Section 14 >|> imply that every node must select every other node as an MPR! >| >|Nonsense. Each node advertises that local interface as a local >|non-MANET interface, and then no node has any strict two hop >|neighbours, and no MPRs are selected. > > It depends. When the local interface is used for attachment of > other MANET routers, then of course it shall be configured as > a MANET interface. That's not the scenario I commented on, which says "local network". Another MANET router is not a local network. > If it is a MANET interface, and no other MANET router is attached, > there is no 2-hop neighbor on it and thus it does not affect MPR > selection. Why did you think so? I didn't. I pointed out that the sensible configuration involves no MPRs. ******************************************************************** 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 ogier@earthlink.net Wed May 6 23:21:38 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94D603A7078 for ; Wed, 6 May 2009 23:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5Erx-NGc--N for ; Wed, 6 May 2009 23:21:37 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 304933A6F15 for ; Wed, 6 May 2009 23:20:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Q3K/7dK/gwSFGIVd5XL/3n552RkBhyAXAJoBmjqyO5ZiOe10zUoGSDZsb1tpPazd; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.219.149] by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M1wzw-0003Ct-Qf; Thu, 07 May 2009 02:22:25 -0400 Message-ID: <4A027EF6.5060409@earthlink.net> Date: Wed, 06 May 2009 23:25:58 -0700 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <004c01c9c3fb$ac973c90$05c5b5b0$@nl> <000b01c9c899$a52e0d60$ef8a2820$@nl><49FB71FE.3090708@earthlink.net> <009801c9ce12$a26570e0$e73052a0$@nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478594a5b3a834a310e21dcbecbb5043e707225168afb2bbc17350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.219.149 Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - suggestions for enhancing message forwarding X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 06:21:38 -0000 Dearlove, Christopher (UK) wrote: >>|> For example, suppose a MANET has 100 nodes that are all neighbors >>|> of each other, and suppose each node also has another interface that >>|> is connected to a local network. Then the MPR properties in Section >> >> >14 > > >>|> imply that every node must select every other node as an MPR! >>| >>|Nonsense. Each node advertises that local interface as a local >>|non-MANET interface, and then no node has any strict two hop >>|neighbours, and no MPRs are selected. >> >>It depends. When the local interface is used for attachment of >>other MANET routers, then of course it shall be configured as >>a MANET interface. >> >> > >That's not the scenario I commented on, which says "local network". >Another MANET router is not a local network. > > OK, we are using the term "local" in different ways. It is easy to modify the scenario slightly to make the same point. Just replace "local network" with a short-range MANET segment. Thus, there is a long-range MANET segment, and each router attached to this segment is also attached to a short-range segment. More specifically, consider a MANET with two segments: short range and long range. All nodes have a short-range interface, but only half the nodes have a long-range interface. The long-range segment has diameter 1, and the short-range segment has a much larger diameter (and might not be connected). Each node with a long-range interface will select a large number of neighbors as MPRs, to cover all 2-hop neighbors that do not have a long-range interface. These MPRs will forward each TC message on *both* interfaces, even though all neighbors on the long-range interface already received the message. With Teco's proposal, all MPRs on the long-range interface will be of type MPR_other_interfaces, thus avoiding this unnecessary flooding. As already mentioned, the proposed scheme can greatly improve efficiency even if the diameter of the long-range segment is greater than 1. Richard >>If it is a MANET interface, and no other MANET router is attached, >>there is no 2-hop neighbor on it and thus it does not affect MPR >>selection. Why did you think so? >> >> > >I didn't. I pointed out that the sensible configuration involves >no MPRs. > >******************************************************************** >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 philippe.jacquet@inria.fr Thu May 7 04:33:31 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17903A67FC for ; Thu, 7 May 2009 04:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.063 X-Spam-Level: X-Spam-Status: No, score=-6.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8Ee0WZVvDmr for ; Thu, 7 May 2009 04:33:30 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 4C3E23A6B4E for ; Thu, 7 May 2009 04:33:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,309,1238968800"; d="scan'208";a="25770569" Received: from mp-41039.rocq.inria.fr (HELO [128.93.41.39]) ([128.93.41.39]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 May 2009 13:34:56 +0200 Message-ID: <4A02C760.9080009@inria.fr> Date: Thu, 07 May 2009 13:34:56 +0200 From: Philippe Jacquet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Richard Ogier References: <004c01c9c3fb$ac973c90$05c5b5b0$@nl> <000b01c9c899$a52e0d60$ef8a2820$@nl><49FB71FE.3090708@earthlink.net> <009801c9ce12$a26570e0$e73052a0$@nl> <4A027EF6.5060409@earthlink.net> In-Reply-To: <4A027EF6.5060409@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] OLSRv2 - suggestions for enhancing message forwarding X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 11:33:31 -0000 Hello, We are no longer discussing MPR per node versus interface? It seems to me that the discussion is now clearly in favor of per interface selection, or am I wrong? I don't understand well the example of Richard, because I didn't follow well the thread. If nodes are in different segments, then we have a MANET as a transit network, and there will be default routes toward each segment, no needs to share TC's between the segments. If nodes are systematically connected to two segments, then wouldn't it be equivalent to have a single MANET with two kinds of interfaces? And in this case the MPRs that cover the two hop neighbors on the slow interface will likely cover the two hop neighbors on the fast interface and there is an advantage to retransmit on both interfaces. In the exotic case of a MANET with several distinct segments within which we would like to anyhow share TC's, there could be some economy in distinguishing MPR wrt to output interface, in the case where one neighbor is the only neighbor to a two hop neighbor and this on another interface. That means that we would like to tell a node that it is a kind of restricted MPR, by identifying the interface(s) where it is authorized to retransmit, or conversely where it should not retransmit. It seems this may introduce an increasing signaling complexity for some non scalable cases. We could also complicate the problem by distinguishing the retransmission with respect to the input interface and notify to the selected MPR the rule of retransmission as a boolean matrix of input interfaces and output interfaces. Best regards, Philippe Richard Ogier a écrit : > Dearlove, Christopher (UK) wrote: > >>> |> For example, suppose a MANET has 100 nodes that are all neighbors >>> |> of each other, and suppose each node also has another interface that >>> |> is connected to a local network. Then the MPR properties in Section >>> >> 14 >> >> >>> |> imply that every node must select every other node as an MPR! >>> | >>> |Nonsense. Each node advertises that local interface as a local >>> |non-MANET interface, and then no node has any strict two hop >>> |neighbours, and no MPRs are selected. >>> >>> It depends. When the local interface is used for attachment of other >>> MANET routers, then of course it shall be configured as >>> a MANET interface. >>> >> >> That's not the scenario I commented on, which says "local network". >> Another MANET router is not a local network. >> >> > > OK, we are using the term "local" in different ways. It is easy to > modify the scenario slightly to make the same point. Just replace > "local network" with a short-range MANET segment. Thus, there is > a long-range MANET segment, and each router attached to this > segment is also attached to a short-range segment. > > More specifically, consider a MANET with two segments: short range > and long range. All nodes have a short-range interface, > but only half the nodes have a long-range interface. > The long-range segment has diameter 1, and the short-range > segment has a much larger diameter (and might not be connected). > Each node with a long-range interface will select a large number > of neighbors as MPRs, to cover all 2-hop neighbors that do not > have a long-range interface. These MPRs will forward each > TC message on *both* interfaces, even though all neighbors > on the long-range interface already received the message. > With Teco's proposal, all MPRs on the long-range interface > will be of type MPR_other_interfaces, thus avoiding this > unnecessary flooding. > > As already mentioned, the proposed scheme can greatly improve > efficiency even if the diameter of the long-range segment is > greater than 1. > > Richard > > >>> If it is a MANET interface, and no other MANET router is attached, >>> there is no 2-hop neighbor on it and thus it does not affect MPR >>> selection. Why did you think so? >>> >> >> I didn't. I pointed out that the sensible configuration involves >> no MPRs. >> >> ******************************************************************** >> 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 nhv@crhc.uiuc.edu Thu May 7 15:18:04 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4856C3A659C for ; Thu, 7 May 2009 15:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk9Zm6ByD7qn for ; Thu, 7 May 2009 15:18:03 -0700 (PDT) Received: from expredir7.cites.uiuc.edu (expredir7.cites.uiuc.edu [128.174.5.168]) by core3.amsl.com (Postfix) with ESMTP id 4ABB53A68A3 for ; Thu, 7 May 2009 15:18:03 -0700 (PDT) Received: from darwin.crhc.uiuc.edu (darwin.crhc.uiuc.edu [130.126.142.206]) by expredir7.cites.uiuc.edu (8.14.2/8.14.2) with ESMTP id n47MJUmX010218 for ; Thu, 7 May 2009 17:19:30 -0500 (CDT) Date: Thu, 7 May 2009 17:19:30 -0500 (CDT) From: "Nitin H. Vaidya" X-X-Sender: nhv@darwin.crhc.illinois.edu To: manet@ietf.org Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [manet] Post-doc position @ UIUC - Wireless Networking X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Nitin H. Vaidya" List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 22:18:04 -0000 1 year post-doc position in "protocols for wireless networks" available starting around July-August 2009. Requirements include strong research record in wireless networking. If interested, please send your vitae (in PDF or plain-text) to nhv@illinois.edu. ----------------------------------------------------------------------- Nitin Vaidya Professor, Electrical and Computer Eng. & Coordinated Science Lab. Director, Illinois Center for Wireless Systems University of Illinois at Urbana-Champaign Mailing address: Phone: 217-265-5414 Coordinated Science Laboratory E-mail: nhv@illinois.edu 1308 W. Main Street Fax: 217-244-5685 Urbana, IL 61801 www.crhc.illinois.edu/wireless ----------------------------------------------------------------------- From ogier@earthlink.net Fri May 8 00:11:41 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E533A6820 for ; Fri, 8 May 2009 00:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgfw2pS+e1Mp for ; Fri, 8 May 2009 00:11:40 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 0BB753A6E3D for ; Fri, 8 May 2009 00:10:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=aKLjDNNej94GrpdRzqg5Nv1sIFu/uQDXx46zeaB7d7k/mWRDALeZE0T8FjvPtljs; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.222.194] by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M2KFl-0005TH-12; Fri, 08 May 2009 03:12:18 -0400 Message-ID: <4A03DC26.6030506@earthlink.net> Date: Fri, 08 May 2009 00:15:50 -0700 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philippe Jacquet References: <004c01c9c3fb$ac973c90$05c5b5b0$@nl> <000b01c9c899$a52e0d60$ef8a2820$@nl><49FB71FE.3090708@earthlink.net> <009801c9ce12$a26570e0$e73052a0$@nl> <4A027EF6.5060409@earthlink.net> <4A02C760.9080009@inria.fr> In-Reply-To: <4A02C760.9080009@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478594a5b3a834a310e91fba0b555c845aaf87bef09308422d8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.222.194 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] OLSRv2 - suggestions for enhancing message forwarding X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 07:11:41 -0000 Philippe Jacquet a écrit: > Hello, > > We are no longer discussing MPR per node versus interface? It seems to > me that the discussion is now clearly in favor of per interface > selection, or am I wrong? I think that OLSRv2 should allow the option of selecting MPRs without requiring 2-hop neighbors to be redundantly covered by MPRs on all possible interfaces. Thus, I don't think that the router should be required to select a *complete* set of MPRs for each interface. There is still a (possibly incomplete) set of MPRs for each interface. One reason given for this requirement was the race condition, but there are other ways to avoid this problem (e.g., using jitter or giving priority to "better" interfaces), so it should be possible to remove this requirement and thus avoid redundant flooding over multiple interfaces. > > I don't understand well the example of Richard, because I didn't > follow well the thread. If nodes are in different segments, then we > have a MANET as a transit network, and there will be default routes > toward each segment, no needs to share TC's between the segments. I am using Teco's definition of a MANET segment (repeated below). A segment is associated with a single interface. A node that has two interfaces belongs to two segments. Both segments in my example are part of a transit MANET. If you prefer, the short-range segment can be divided into multiple local MANET segments/clusters, one for each router in the long-range segment. However, I am assuming that the union of all segments forms a single MANET, so TC messages are flooded to all routers. Also, it is possible for a router to move from one cluster to another without changing its IP address. Thus, each cluster may not have its own prefix. This is just one example that shows the inefficiency of having each MPR forward each TC message on *all* interfaces, and how the simple scheme proposed by Teco can improve efficiency by using different MPR types. In general there may not be "clusters". Instead, there is a single MANET in which every router has a short-range interface and only some routers have a long-range interface. Surely, you would like OLSRv2 to be efficient in this case. > > If nodes are systematically connected to two segments, then wouldn't > it be equivalent to have a single MANET with two kinds of interfaces? > And in this case the MPRs that cover the two hop neighbors on the slow > interface will likely cover the two hop neighbors on the fast > interface and there is an advantage to retransmit on both interfaces. In my example, there is a short-range interface and a long-range interface, so the above does not apply. In my example, there is never any need to retransmit on the long-range interface. > > In the exotic case of a MANET with several distinct segments within > which we would like to anyhow share TC's, there could be some economy > in distinguishing MPR wrt to output interface, in the case where one > neighbor is the only neighbor to a two hop neighbor and this on > another interface. > > That means that we would like to tell a node that it is a kind of > restricted MPR, by identifying the interface(s) where it is authorized > to retransmit, or conversely where it should not retransmit. It seems > this may introduce an increasing signaling complexity for some non > scalable cases. > > We could also complicate the problem by distinguishing the > retransmission with respect to the input interface and notify to the > selected MPR the rule of retransmission as a boolean matrix of input > interfaces and output interfaces. Yes, I mentioned something similar in my message on 4/29: "I think that maximum efficiency would require somehow indicating exactly which of the n interfaces the packet should be forwarded on. But of course this is more complex." But Teco's scheme seems to be a good compromise between efficiency and simplicity. He defines 3 MPR types: MPR_this_interface: Forward only on the same interface MPR_other_interfaces: Forward on all other interfaces. MPR_all_interfaces: Forward on all interfaces. Richard MANET segment Wireless communication facility which may interconnect MANET interfaces, when within radio range to each other. A MANET interface connects a MANET router to a single MANET segment. > > Best regards, > Philippe > > Richard Ogier a écrit : > >> Dearlove, Christopher (UK) wrote: >> >>>> |> For example, suppose a MANET has 100 nodes that are all neighbors >>>> |> of each other, and suppose each node also has another interface >>>> that >>>> |> is connected to a local network. Then the MPR properties in Section >>>> >>> >>> 14 >>> >>> >>>> |> imply that every node must select every other node as an MPR! >>>> | >>>> |Nonsense. Each node advertises that local interface as a local >>>> |non-MANET interface, and then no node has any strict two hop >>>> |neighbours, and no MPRs are selected. >>>> >>>> It depends. When the local interface is used for attachment of >>>> other MANET routers, then of course it shall be configured as >>>> a MANET interface. >>>> >>> >>> >>> That's not the scenario I commented on, which says "local network". >>> Another MANET router is not a local network. >>> >>> >> >> OK, we are using the term "local" in different ways. It is easy to >> modify the scenario slightly to make the same point. Just replace >> "local network" with a short-range MANET segment. Thus, there is >> a long-range MANET segment, and each router attached to this >> segment is also attached to a short-range segment. >> >> More specifically, consider a MANET with two segments: short range >> and long range. All nodes have a short-range interface, >> but only half the nodes have a long-range interface. >> The long-range segment has diameter 1, and the short-range >> segment has a much larger diameter (and might not be connected). >> Each node with a long-range interface will select a large number >> of neighbors as MPRs, to cover all 2-hop neighbors that do not >> have a long-range interface. These MPRs will forward each >> TC message on *both* interfaces, even though all neighbors >> on the long-range interface already received the message. >> With Teco's proposal, all MPRs on the long-range interface >> will be of type MPR_other_interfaces, thus avoiding this >> unnecessary flooding. >> >> As already mentioned, the proposed scheme can greatly improve >> efficiency even if the diameter of the long-range segment is >> greater than 1. >> >> Richard >> >> >>>> If it is a MANET interface, and no other MANET router is attached, >>>> there is no 2-hop neighbor on it and thus it does not affect MPR >>>> selection. Why did you think so? >>>> >>> >>> >>> I didn't. I pointed out that the sensible configuration involves >>> no MPRs. >>> >>> ******************************************************************** >>> 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 teco@inf-net.nl Fri May 8 01:04:44 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279F23A704D for ; Fri, 8 May 2009 01:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTDV5vQ0+HTG for ; Fri, 8 May 2009 01:04:43 -0700 (PDT) Received: from CPSMTPM-EML104.kpnxchange.com (cpsmtpm-eml104.kpnxchange.com [195.121.3.8]) by core3.amsl.com (Postfix) with ESMTP id 25C6F3A6E95 for ; Fri, 8 May 2009 01:04:42 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 8 May 2009 10:06:10 +0200 From: "Teco Boot" To: "'Richard Ogier'" , "'Philippe Jacquet'" References: <004c01c9c3fb$ac973c90$05c5b5b0$@nl> <000b01c9c899$a52e0d60$ef8a2820$@nl><49FB71FE.3090708@earthlink.net> <009801c9ce12$a26570e0$e73052a0$@nl> <4A027EF6.5060409@earthlink.net> <4A02C760.9080009@inria.fr> <4A03DC26.6030506@earthlink.net> In-Reply-To: <4A03DC26.6030506@earthlink.net> Date: Fri, 8 May 2009 10:06:09 +0200 Message-ID: <002601c9cfb3$d8bdc1e0$8a3945a0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnPrLQepmxfZhnRQHuw23HFlCRvrgAAmwzw Content-Language: nl X-OriginalArrivalTime: 08 May 2009 08:06:10.0229 (UTC) FILETIME=[D8ED3650:01C9CFB3] Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] OLSRv2 - suggestions for enhancing message forwarding X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 08:04:44 -0000 Reading back my definition on MANET segment: | MANET segment | | Wireless communication facility which may interconnect | MANET interfaces, when within radio range to each other. | A MANET interface connects a MANET router to a single | MANET segment. In fact, the communication facility does not have to be wireless. Cabled links can be MANET segments also. Question here is: What is a MANET interface? It is used for two different things: a) Interface to a wireless communication facility that may suffer time varying connectivity, asymmetry and non-transitivity. b) Interface with a MANET protocol active on it. I think a MANET segment is part of a MANET routing domain and can be wired or wireless. New attempt for definitions: **** MANET segment Sub-IP layer communication facility which may interconnect MANET interfaces. A MANET interface connects a MANET router to a single MANET segment. MANET segments may use wireless or wired communication facilities and may suffer time varying connectivity, asymmetry and non-transitivity. MANET interface Interface with a MANET protocol active on it. **** I am aware I am flip-flopping on definition for MANET interface constantly. For this reason, I retrigger this discussion over and over, hopefully resulting in convergence some day. Problem here is OSPF-MANET, where OSPF_Interface_Type = MANET is definition a) **and** b), where in the MANET WG discussions definition b) is meant. In Autoconf WG, we flip-flop day to day. Teco. From root@core3.amsl.com Tue May 12 11:45:01 2009 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 384C828C1B6; Tue, 12 May 2009 11:45:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090512184501.384C828C1B6@core3.amsl.com> Date: Tue, 12 May 2009 11:45:01 -0700 (PDT) Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-nhdp-mib-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 18:45:01 -0000 --NextPart 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) : R. Cole, I. Chakeres Filename : draft-ietf-manet-nhdp-mib-00.txt Pages : 48 Date : 2009-5-3 This memo 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 aspects of the Neighborhood Discovery Protocol (NHDP) process on a router. The NHDP MIB also reports state information, performance information and notifications. This additional state and performance information is useful to management stations troubleshooting neighbor discovery problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-mib-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-manet-nhdp-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-5-12114434.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue May 12 12:00:01 2009 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C6DFE3A6C4F; Tue, 12 May 2009 12:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090512190001.C6DFE3A6C4F@core3.amsl.com> Date: Tue, 12 May 2009 12:00:01 -0700 (PDT) Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-olsrv2-mib-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 19:00:01 -0000 --NextPart 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 MANET Optimized Link State Routing Protocol version 2 Author(s) : T. Clausen, R. Cole Filename : draft-ietf-manet-olsrv2-mib-00.txt Pages : 45 Date : 2009-5-3 This memo 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 and managing aspects of the Optimized Link State Routing protocol version 2. The Optimized Link State Routing MIB also reports state information, performance metrics, and notifications. In addition to configuration, this additional state and performance information is useful to management stations troubleshooting Mobile Ad-Hoc Networks routing problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-mib-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-manet-olsrv2-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-5-12114800.I-D@ietf.org> --NextPart-- From obli.olsr@gmail.com Fri May 15 01:39:09 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2F33A6768 for ; Fri, 15 May 2009 01:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.809 X-Spam-Level: X-Spam-Status: No, score=-0.809 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLYOG8bLD8GU for ; Fri, 15 May 2009 01:39:08 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 1C4453A685F for ; Fri, 15 May 2009 01:39:07 -0700 (PDT) Received: by fxm2 with SMTP id 2so1775074fxm.37 for ; Fri, 15 May 2009 01:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=iMXM5jmpwlB/btWnnCnmcKXKahBDCCOZEz2N3vlWVKc=; b=lMobcn4yAJYllPyVeDsqmw33ow+tOJwiVtPwzTdK4e/NS68CxAHCT/ecXByFbYcFyS R8eB5MGFa+j3QglGfX8pnJxoRv+ro6i9nv1qVlU2TXfrlaTi4UGVlkvU6DGTBThiheOu KPXQy0T5ulpOy/mMlTbFUqROcla4DoV/2EcXw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=shTWPeVv/47KLSYmCa9jym/EMK+XnDcYn1o+Rd80Jp9CQ+j28OxxX5WyjvKJ5pwwRU eUt/p/sJp4+VChixc5XkBKoCbjPLhnarE44lX8AsVSFaC66JfEmLnbQj/7rsB6hqRBXG 9El1+k0pZXzImlChzcltACGfYDucnIBmMpVOw= MIME-Version: 1.0 Received: by 10.204.121.131 with SMTP id h3mr3094572bkr.66.1242376838857; Fri, 15 May 2009 01:40:38 -0700 (PDT) Date: Fri, 15 May 2009 10:40:38 +0200 Message-ID: <28f06f0b0905150140n5a0334c9u23db8d2f9a1361e9@mail.gmail.com> From: =?ISO-8859-1?Q?Aur=E9lien_Ribon?= To: manet@ietf.org Content-Type: multipart/alternative; boundary=001636c5a4af2842b90469ef66a1 Subject: [manet] OLSR v1 - Question about the symmetric 1-hop neighborhood X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 08:39:09 -0000 --001636c5a4af2842b90469ef66a1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, I am currently writing a full hardware implementation of OLSR v1 on a FPGA. Everything is going well but there is one point that is not totally clear i= n my mind. When the draft says (for TC, MID and HNA message processing) : 1 If the sender interface (NB: not originator) of this message is not in the symmetric 1-hop neighborhood of this node, the message MUST be discarded. Does it mean : Look in the Link Set and see if there is a tuple where L_neighbor_iface_addr =3D=3D sender iface addr AND L_SYM_time >=3D currentTime ? Thanks, Aur=E9lien Ribon --001636c5a4af2842b90469ef66a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I am currently writing a full hardware implementation of OLSR= v1 on a FPGA.
Everything is going well but there is one point that is n= ot totally clear in my mind.

When the draft says (for TC, MID and HN= A message processing) :

   =
  1    If the sender interface (NB: not originator) of this message
    =
      is not in the symmetric 1-hop neighborhood of this node, the
     =
     message MUST be discarded.

Does it mean :

Look in the Link Set and see if there is a tuple where

L_neighbor_iface_addr = =3D=3D sender iface addr
AND
L_SYM_time >=3D current= Time

?

Thanks,
Aur=E9lien Ribon
--001636c5a4af2842b90469ef66a1-- From Chris.Dearlove@baesystems.com Fri May 15 08:54:14 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD6903A6E41 for ; Fri, 15 May 2009 08:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.223 X-Spam-Level: X-Spam-Status: No, score=-4.223 tagged_above=-999 required=5 tests=[AWL=-1.924, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYQn0gBJ079Z for ; Fri, 15 May 2009 08:54:13 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 9D18D3A6C2E for ; Fri, 15 May 2009 08:54:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,200,1241391600"; d="scan'208";a="2550687" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 15 May 2009 16:55:46 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n4FFtjdj022523; Fri, 15 May 2009 16:55:45 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 May 2009 16:55:45 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 15 May 2009 16:55:42 +0100 Message-ID: In-Reply-To: <28f06f0b0905150140n5a0334c9u23db8d2f9a1361e9@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSR v1 - Question about the symmetric 1-hop neighborhood Thread-Index: AcnVONn6HXM7KHbmS8aQsZZwnisTyAAOy1qg References: <28f06f0b0905150140n5a0334c9u23db8d2f9a1361e9@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: =?iso-8859-1?Q?Aur=E9lien_Ribon?= , X-OriginalArrivalTime: 15 May 2009 15:55:45.0771 (UTC) FILETIME=[9BBFFBB0:01C9D575] Subject: Re: [manet] OLSR v1 - Question about the symmetric 1-hop neighborhood X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 15:54:14 -0000 Two points: =20 I think the L_neighbor_iface_addr condition should also include that L_local_iface_addr (of the same tuple) is the local interface address on which the message (packet) was received. Agreed that may not be exactly what it says, but as you say, it's not quite clear. But I think that's theoretically better. But in almost all cases it's not going to make much difference, and in most cases none at all. =20 I also think your >=3D should be >. =20 OK, in practice that may make little or no difference. But for expiry times you want to remove at the time (removing "at the first time after that time= " is not well-defined) and you want to do the same for other timers for consistency I think. =20 Now I have to admit I haven't checked the second point with RFC 3626. I am fairly sure OLSRv2 adopts the above approach (but OLSRv2 is in general tigh= ter on these sorts of things - on link quality thresholds for example). It also handles the first point subtly differently too. -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 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 ________________________________ From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= ur=E9lien Ribon Sent: 15 May 2009 09:41 To: manet@ietf.org Subject: [manet] OLSR v1 - Question about the symmetric 1-hop neighborhood *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message. Hello, I am currently writing a full hardware implementation of OLSR v1 on a FPGA. Everything is going well but there is one point that is not totally clear i= n my mind. When the draft says (for TC, MID and HNA message processing) : 1 If the sender interface (NB: not originator) of this message is not in the symmetric 1-hop neighborhood of this node, the message MUST be discarded. Does it mean : Look in the Link Set and see if there is a tuple where L_neighbor_iface_addr =3D=3D sender iface addr AND L_SYM_time >=3D currentTime ? Thanks, Aur=E9lien Ribon ******************************************************************** 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 haas@ece.cornell.edu Mon May 18 07:43:38 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4CB3A6B97 for ; Mon, 18 May 2009 07:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-kXvcL4sqLF for ; Mon, 18 May 2009 07:43:37 -0700 (PDT) Received: from smtp.ece.cornell.edu (odin.ece.cornell.edu [128.84.81.19]) by core3.amsl.com (Postfix) with ESMTP id DA04F28C2B9 for ; Mon, 18 May 2009 07:43:36 -0700 (PDT) Received: from localhost (rh-128-84-94-70.ece.cornell.edu [128.84.94.70]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.ece.cornell.edu (Postfix) with ESMTP id EEF9D54001E; Mon, 18 May 2009 10:45:11 -0400 (EDT) Date: Mon, 18 May 2009 10:45:06 -0400 (Eastern Daylight Time) From: haas To: Vaibhav_Kumar@Dell.com In-Reply-To: Message-ID: References: X-X-Sender: haas@imap.ece.cornell.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: sami.samiksha@gmail.com, manet@ietf.org Subject: Re: [manet] Regarding ZRP trace file X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 14:43:38 -0000 Dear Vaibhav, We do not support this software anymore ... it was developed for an older version of NS-2. We may be replacing it with a new software, but it will not be done before the Fall semester. If we do, we will be positing it on our (updated-by-then) web pages. Zygmunt Haas. ===--==-=-=-=== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ Dr. Zygmunt J. Haas http://people.ece.cornell.edu/haas Professor School of Electrical Engineering Wireless Networks Laboratory, Director http://wnl.ece.cornell.edu Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 U.S.A e-mail: haas(at)ece(dot)cornell(dot)edu WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ "I would found an institution where any person could find instruction in any study." - Ezra Cornell, 1868 On Mon, 18 May 2009, Vaibhav_Kumar@Dell.com wrote: => Date: Mon, 18 May 2009 20:07:13 +0530 => From: Vaibhav_Kumar@Dell.com => To: haas@ee.cornell.edu, haas@ece.cornell.edu => Cc: sami.samiksha@gmail.com, manet@ietf.org => Subject: Regarding ZRP trace file => => Hi, => => The ZRP code present at the following location => => http://wnl.ece.cornell.edu/wnlprojects.html#adhoc_software => => => was successfully installed in Redhat 7.3 using ns-2.1b6a. (I followed => the README instructions). After executing the command 'ns example.tcl' => pktdemo.tr file was generated. => => But when I analyzed the file using a awk file (attached), I got PDF as => 0.0. It seems no packets were received. => => Please let me know how to get a valid PDF value. => => <> <> => => Regards => -Vaibhav => From themq15@yahoo.com Mon May 18 12:09:47 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 049823A6B15 for ; Mon, 18 May 2009 12:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.799 X-Spam-Level: * X-Spam-Status: No, score=1.799 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DN3n5I-YGV7P for ; Mon, 18 May 2009 12:09:46 -0700 (PDT) Received: from n68.bullet.mail.sp1.yahoo.com (n68.bullet.mail.sp1.yahoo.com [98.136.44.44]) by core3.amsl.com (Postfix) with SMTP id 4B4D43A68B4 for ; Mon, 18 May 2009 12:09:46 -0700 (PDT) Received: from [216.252.122.218] by n68.bullet.mail.sp1.yahoo.com with NNFMP; 18 May 2009 19:11:21 -0000 Received: from [69.147.65.152] by t3.bullet.sp1.yahoo.com with NNFMP; 18 May 2009 19:11:21 -0000 Received: from [127.0.0.1] by omp400.mail.sp1.yahoo.com with NNFMP; 18 May 2009 19:11:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 131085.77101.bm@omp400.mail.sp1.yahoo.com Received: (qmail 78296 invoked by uid 60001); 18 May 2009 19:11:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242673880; bh=IE0S5XKw0oqMIMcfqekNnVFERZjvgMfySiVugB/kMEw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=pg02mZSSi1Qi3YrRWKUfPaG8SbsqqookOr1pAgoOKUDV/Uf9+KZgXNzncO/blt6BzhWy1MjxTFzPKwCnFqQ024DVpw+MqDYSYeAN2DCgynwrPNrClPVR/xjQbeRnRKOOq03na/SgSMDo9NbfaCNbmjJXInrsdCxMTQmTMayTrts= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=xK6K/fshHaKrJbcdgjKMwQFAdpTiCRrzKRyChAEfhU9Fx6t/EfKf9WsZBbLwdCqF70Vyrnq17tW3HxeTWv49l9mvBujZzztP9rYVGXcoO/ybRzPNf7H5sbnMRwS0XRxR62GXdATuGkfDrI3+zwtIrvTWov475zJ5lNVZMXcDsTs=; Message-ID: <754569.78257.qm@web43406.mail.sp1.yahoo.com> X-YMail-OSG: J03P_5wVM1ndvD97nY3YrvqGpE3e0s9yF7JmGJ7tq8scnNNzB86nddxO6h0HaupWnol_ChA_CciMn8hSDdT1lWrN1OpFYi9NRvl6MMGP.xItbwCOkjpvs8._LNDUM2p8gUmlM_r0UOYLjZ2de.Op3qRtOWKnnM03Gpn9c_218hnez4NTsFnef_xPnVTkKBaXN5s6uOFVryjiNvllbYE3zjPz4j3agkooM3Sx0E7N0UNpeJrQnaSXXxkECAnnkaFewiUJlOiUYn_tJm6E6DV8Cf2mMEoa8LJKV5lVDBdh8Ym1TfKwSrHyNWksNcRIuDWxtASsgaFTGlNLhBA- Received: from [116.71.215.137] by web43406.mail.sp1.yahoo.com via HTTP; Mon, 18 May 2009 12:11:19 PDT X-Mailer: YahooMailClassic/5.3.9 YahooMailWebService/0.7.289.10 Date: Mon, 18 May 2009 12:11:19 -0700 (PDT) From: Bringo Shawn To: IETFManet MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-800993155-1242673879=:78257" Subject: [manet] On Demand and Hello messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 19:09:47 -0000 --0-800993155-1242673879=:78257 Content-Type: text/plain; charset=us-ascii Hi there.I am studing on demand (reactive protocols). Please tell me if I am wrong:A protocol that sends hello messages periodically MAY or MAY NOT be a reactive or on demand protocol but a protocol that plays its role only when it is needed such as a route to some node is required, must be a reactive or on demand protocol. Am I righ? --0-800993155-1242673879=:78257 Content-Type: text/html; charset=us-ascii
Hi there.
I am studing on demand (reactive protocols). Please tell me if I am wrong:
A protocol that sends hello messages periodically MAY or MAY NOT be a reactive or on demand protocol but a protocol that plays its role only when it is needed such as a route to some node is required, must be a reactive or on demand protocol. Am I righ?

--0-800993155-1242673879=:78257-- From charles.perkins@earthlink.net Mon May 18 12:17:35 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97A73A6892 for ; Mon, 18 May 2009 12:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qSc+HDLf5WD for ; Mon, 18 May 2009 12:17:35 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id B45C03A6809 for ; Mon, 18 May 2009 12:17:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=UjMiNXJPT3BZm5P39NELVqdJJeDoHddsC/Om18/BH0y03zlI0mizxpfGGGKZVqk8; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.96.10.141] (helo=[192.168.1.108]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1M68Mg-0003Ys-NL; Mon, 18 May 2009 15:19:10 -0400 Message-ID: <4A11B4AD.2080204@earthlink.net> Date: Mon, 18 May 2009 12:19:09 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Bringo Shawn References: <754569.78257.qm@web43406.mail.sp1.yahoo.com> In-Reply-To: <754569.78257.qm@web43406.mail.sp1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52541fca5c4ff15321aaf0359489474c0d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.96.10.141 Cc: IETFManet Subject: Re: [manet] On Demand and Hello messages X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 19:17:35 -0000 Hello, Yes, this is right. But maybe it is better to not enforce allegiance to this definitional characterization. If periodic HELLO messages make the protocol work better, it doesn't matter whether that violates any measure of protocol purity. Unfortunately, it's usually not so easy measuring "better" unless you have a goal -- say, reducing latency. Then, whether or not to proactively carry out neighborhood discovery would be determined by checking what is needed to meet your goals. Regards, Charlie P. Bringo Shawn wrote: > Hi there. > I am studing on demand (reactive protocols). Please tell me if I am wrong: > A protocol that sends hello messages periodically MAY or MAY NOT be a > reactive or on demand protocol but a protocol that plays its role only > when it is needed such as a route to some node is required, must be a > reactive or on demand protocol. Am I righ? > > > ------------------------------------------------------------------------ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From bms@incunabulum.net Tue May 19 02:57:10 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642F13A6991 for ; Tue, 19 May 2009 02:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXn1bCU6G1Ob for ; Tue, 19 May 2009 02:57:09 -0700 (PDT) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id 94C283A6C52 for ; Tue, 19 May 2009 02:57:09 -0700 (PDT) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id BCF9031E242; Tue, 19 May 2009 05:58:45 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 19 May 2009 05:58:45 -0400 X-Sasl-enc: clJoncxMZLlnBZCvK2sbH9bzqxrjco/M0qtKEOc0XEdT 1242727125 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 49C9B25B4E; Tue, 19 May 2009 05:58:45 -0400 (EDT) Message-ID: <4A1282D3.9020100@incunabulum.net> Date: Tue, 19 May 2009 10:58:43 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Aur=E9lien_Ribon?= References: <28f06f0b0905150140n5a0334c9u23db8d2f9a1361e9@mail.gmail.com> In-Reply-To: <28f06f0b0905150140n5a0334c9u23db8d2f9a1361e9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: manet@ietf.org Subject: Re: [manet] OLSR v1 - Question about the symmetric 1-hop neighborhood X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 09:57:10 -0000 Aurélien Ribon wrote: > I am currently writing a full hardware implementation of OLSR v1 on a > FPGA. > Everything is going well but there is one point that is not totally > clear in my mind. > > When the draft says (for TC, MID and HNA message processing) : > > 1 If the sender interface (NB: not originator) of this message > is not in the symmetric 1-hop neighborhood of this node, the > message MUST be discarded. > > Look here in method TopologyManager::event_receive_tc() :- http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/xorp/contrib/olsr/topology.cc?rev=1.5 and look here in method Neighborhood::is_sym_neighbor_addr() :- http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/xorp/contrib/olsr/neighborhood.cc?rev=1.4 Of course, that lookup could probably get speeded up if the interface ID where the message was received is known. cheers, BMS From obli.olsr@gmail.com Tue May 19 05:07:35 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1BF13A6B17 for ; Tue, 19 May 2009 05:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bunfodUQ1YuN for ; Tue, 19 May 2009 05:07:34 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 4D17C3A6B10 for ; Tue, 19 May 2009 05:07:34 -0700 (PDT) Received: by fxm2 with SMTP id 2so3824392fxm.37 for ; Tue, 19 May 2009 05:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=4dv38i03b88CXyb1rWsIff2HgRIEWVWk2TrjXyBSesc=; b=V3QgNMLdPqXyvWMQTIY+ygc5BK86UwjEq52eH9Sk3rScRWB2P+2TZr9zXqTGntBpMc X86+4amdO/TsT1dJaaf15dLewiB3u7H9xFc5JxbF04YPZ7ciKfWpo/cBZ29EEZ2C2voy Cx5I8bv3HhWqqmagi70DMCChQiiDppZei/lIo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LKgiDz59oSfGoRB1tKmyDeIVC05wOlV2n2BQAx3DL15zWa5ps1+WDA6CMX2VY6dnLU EVkrVPvhN+NOGFEEa8l+Hvf4gLr3wzpo5veow+GQC6vpvo8NxSvZ8vglIGZyPcqZum2k fiS2wJNmOCFSOKjhFcf7RZOO2NJiJ6f3zMZ0o= MIME-Version: 1.0 Received: by 10.204.57.81 with SMTP id b17mr7759761bkh.212.1242734946664; Tue, 19 May 2009 05:09:06 -0700 (PDT) In-Reply-To: <4A1282D3.9020100@incunabulum.net> References: <28f06f0b0905150140n5a0334c9u23db8d2f9a1361e9@mail.gmail.com> <4A1282D3.9020100@incunabulum.net> Date: Tue, 19 May 2009 14:09:06 +0200 Message-ID: <28f06f0b0905190509ma83d76emb37d923873cd08f5@mail.gmail.com> From: =?ISO-8859-1?Q?Aur=E9lien_Ribon?= To: Bruce Simpson Content-Type: multipart/alternative; boundary=00504502b6300bc017046a42c7fb Cc: manet@ietf.org Subject: Re: [manet] OLSR v1 - Question about the symmetric 1-hop neighborhood X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 12:07:35 -0000 --00504502b6300bc017046a42c7fb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thank you all for your answers. But that leave me with one more question. Chris, you said : * * > * I think the L_neighbor_iface_addr condition should also include* > * that L_local_iface_addr (of the same tuple) is the local interface* > * address on which the message (packet) was received.* > > * Agreed that may not be exactly what it says, but as you say, it's* > * not quite clear. But I think that's theoretically better. But in* > * almost all cases it's not going to make much difference, and in most* > * cases none at all.* > I agree with you, but Bruce said : *Look here in method TopologyManager::event_**receive_tc() :-* > * > http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/xorp/contrib/olsr/topology.cc?rev=1.5 > * > > * and look here in method Neighborhood::is_sym_neighbor_**addr() :-* > * > http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/xorp/contrib/olsr/neighborhood.cc?rev=1.4 > * > So, that means that we should test the neighbor tuple and not the link tuple. But the draft do mention that : 1 If the sender interface (NB: not originator) of this message is not in the symmetric 1-hop neighborhood of this node, the message MUST be discarded. Wouldn't the "not originator" expression mean that we only do care about the connectivity of only one interface ? Looking at the neighbor tuple is the same as evaluating all the interfaces at the same time, since a neighbor tuple is updated on every associated link tuple update/record, am I wrong ? --00504502b6300bc017046a42c7fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you all for your answers. But that leave me with one more question.
Chris, you said :


I think the L_neighbor_iface_addr condition should also include
that L_local_iface_addr (of the same tuple) is the local interface
<= i> address on which the message (packet) was received.

Agreed that may not be exactly what it says, but as you say, it's not quite clear. But I think that's theoretically better. But in almost all cases it's not going to make much difference, and in most
cases none at all.


I agree with you, but Bruce = said :


Look here in method =A0TopologyManager::event_receive_tc() :-=
http://cvsweb.xorp.org/cgi-bin/= cvsweb.cgi/xorp/contrib/olsr/topology.cc?rev=3D1.5

and look here in method Neighborhood::is_sym_neighbor_addr() :-<= br>http://cvsweb.xorp.org/cgi-b= in/cvsweb.cgi/xorp/contrib/olsr/neighborhood.cc?rev=3D1.4


So, that means that we should test the neighbor tuple and not the link = tuple. But the draft do mention that :
     1    If the sender interface (NB: n=
ot originator) of this message

          is not in the symmetric 1-hop neighborhood of this node, the
 =
         message MUST be discarded.
Wouldn't the "not = originator" expression mean that we only do care about the connectivit= y of only one interface ?
Looking at the neighbor tuple is the same as evaluating all the interfaces = at the same time, since a neighbor tuple is updated on every associated lin= k tuple update/record, am I wrong ?
--00504502b6300bc017046a42c7fb-- From Chris.Dearlove@baesystems.com Wed May 20 01:44:56 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4CC83A69FE for ; Wed, 20 May 2009 01:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=-2.645, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brbd9HauavAG for ; Wed, 20 May 2009 01:44:51 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 53BCE28C20C for ; Wed, 20 May 2009 01:44:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,220,1241391600"; d="scan'208";a="3157698" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 20 May 2009 09:46:28 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n4K8kRMv006252; Wed, 20 May 2009 09:46:27 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 09:46:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Date: Wed, 20 May 2009 09:46:26 +0100 Message-ID: In-Reply-To: <28f06f0b0905190509ma83d76emb37d923873cd08f5@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSR v1 - Question about the symmetric 1-hopneighborhood thread-index: AcnYeso4dyNy/6H2Qt+ZdT1l3ByDAQAqegfw References: <28f06f0b0905150140n5a0334c9u23db8d2f9a1361e9@mail.gmail.com><4A1282D3.9020100@incunabulum.net> <28f06f0b0905190509ma83d76emb37d923873cd08f5@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: =?iso-8859-1?Q?Aur=E9lien_Ribon?= , "Bruce Simpson" X-OriginalArrivalTime: 20 May 2009 08:46:27.0564 (UTC) FILETIME=[76BA42C0:01C9D927] Cc: manet@ietf.org Subject: Re: [manet] OLSR v1 - Question about the symmetric 1-hopneighborhood X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 08:44:57 -0000 > So, that means that we should test the neighbor tuple and not the link tuple. But the draft do mention that : > > 1 If the sender interface (NB: not originator) of this message > is not in the symmetric 1-hop neighborhood of this node, the > message MUST be discarded. > > Wouldn't the "not originator" expression mean that we only do care > about the connectivity of only one interface ? The "not originator" refers to something else - to that when a message goes from A to B to C its originator is A, but C cares about B, not A. That doesn't make the conclusion above right or wrong. > Looking at the neighbor tuple is the same as evaluating all the > interfaces at the same time, since a neighbor tuple is updated > on every associated link tuple update/record, am I wrong ? The Neighbour Tuple is updated each time. (The very precise details I'd have to check up on, as it's OLSRv2's behaviour that I'm now most familiar with.) But the subtlety happens in cases such as the following. (a) A has interfaces A1, A2, B has interfaces B1, B2. There's a symmetric link from A1 to B1 and an asymmetric link from A2 to B2. You receive a TC message at B2 from A2, should you discard it? (b) A has interfaces A1, A2, B has interface B1. There's a symmetric link from A1 to B1 and an asymmetric link from A2 to B1. You receive a TC message at B1 from A2, should you discard it? (c) A has interface A1, B has interfaces B1, B2. There's a symmetric link from A1 to B1 and an asymmetric link from A1 to B2. You receive a TC message at B2 from A1, should you discard it? I wouldn't incidentally rely on any specific implementation as defining the right answer, although of course it can be useful. ******************************************************************** 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 delta@net.ie.niigata-u.ac.jp Tue May 26 02:29:09 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E319128C1E5 for ; Tue, 26 May 2009 02:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.51 X-Spam-Level: ** X-Spam-Status: No, score=2.51 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAqh9aqpx3LB for ; Tue, 26 May 2009 02:28:47 -0700 (PDT) Received: from mxav02.cc.niigata-u.ac.jp (mxav02.cc.niigata-u.ac.jp [133.35.17.130]) by core3.amsl.com (Postfix) with ESMTP id 445EA28C1BD for ; Tue, 26 May 2009 02:28:03 -0700 (PDT) Received: from mxav02.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C413745427E for ; Tue, 26 May 2009 18:29:37 +0900 (JST) Received: from ms01.net.ie.niigata-u.ac.jp (ms01.net.ie.niigata-u.ac.jp [133.35.156.1]) by mxav02.cc.niigata-u.ac.jp (Postfix) with ESMTP id B932A4541ED for ; Tue, 26 May 2009 18:29:37 +0900 (JST) Received: from msq82.net.ie.niigata-u.ac.jp (ms05.net.ie.niigata-u.ac.jp [133.35.156.5]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id 7EE7E11DCB for ; Tue, 26 May 2009 18:29:33 +0900 (JST) Message-ID: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> Date: Tue, 26 May 2009 18:24:50 +0900 From: Lee Speakman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 09:29:10 -0000 Dear MANET WG members, we at Niigata University have implemented and tested the OLSRv2 protocol according to a recent draft. The implementation has been put to use in simulation and real world physical nodes. Simulation under various scenarios indicate that the use of LLN (Link Layer Notification) leads to a looping packets becoming a problem in the network. In larger networks where the TTL or Hop Count cannot be kept small, and particularly at higher loads, the problem of looping packets become more significant. To this end we put forward an Internet draft available in the following link: http://www.ietf.org/internet-drafts/draft-speakman-manet-looping-issue-00.txt We'd be grateful for your consideration and input. Regards, Lee Speakman Research Center for Natural Hazard and Disaster Recovery, Niigata, Japan Kenichi Mase Graduate School of Science and Technology, Niigata University, Japan From ulrich@herberg.name Tue May 26 04:46:37 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75853A6F11 for ; Tue, 26 May 2009 04:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDfgAMWnknzX for ; Tue, 26 May 2009 04:46:36 -0700 (PDT) Received: from mail-fx0-f168.google.com (mail-fx0-f168.google.com [209.85.220.168]) by core3.amsl.com (Postfix) with ESMTP id 5A2DC3A6B20 for ; Tue, 26 May 2009 04:46:35 -0700 (PDT) Received: by fxm12 with SMTP id 12so1964932fxm.37 for ; Tue, 26 May 2009 04:45:27 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.60.148 with SMTP id p20mr8035808bkh.165.1243338326809; Tue, 26 May 2009 04:45:26 -0700 (PDT) In-Reply-To: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> Date: Tue, 26 May 2009 13:45:26 +0200 X-Google-Sender-Auth: 4e67ca1a94b49740 Message-ID: <25c114b90905260445y54449801v4398e1bdf51ad07b@mail.gmail.com> From: Ulrich Herberg To: Lee Speakman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 11:46:37 -0000 Dear Lee, I have some questions about your draft. Citing a part of Section 5: =A0 The effect of this is to cause the Link Set in the node that has the =A0 LLN to change the link over which the packet was dropped from =A0 Symmetric to Lost ahead of the symmetric link timeouts between the =A0 nodes. =A0The surrounding nodes will still have knowledge of the =A0 existence of this link, and the link will still exist in the Topology =A0 Sets in the rest of the network for some time, possibly leading to =A0 the formation of a loop. Well, as soon as the link has been set to LOST by the LLN, a HELLO will be triggered and the neighbors are informed that this link is indeed lost. This is not different than using "plain" OLSRv2, only that the time the link is advertized (even though it's already gone) is reduced. I don't understand why that should speed up temporary routing loop forming. =A0The effect of LLN is to ultimately speed =A0 the process by which a routing loop forms. =A0Node 3 or node 4 in =A0 Figure 1 may not have to wait for a full three times the Hello =A0 Interval before the Link Set changes its state from Symmetric. =A0 As LLN is triggered on the failure of a data packet to be forwarded =A0 over a link Probably, the LLN should not be triggered if only a single packet is lost. Rather, decrease the Link Quality of that link using some sort of "smooth" function as described in the OLSRv2 draft. =A0 and the number of LLNs increases with the amount of =A0 traffic in the network, the number of routing loops also increases =A0 with the amount traffic in the network. Why is this a logical implication? =A0 Furthermore, as LLN results =A0 in the removal of links at a rate over and above that by timeouts in =A0 'plain' OLSRv2, the total number of links in the network is further =A0 reduced thus increasing the average distance from any source to =A0 destination. The links that "plain" OLSRv2 keeps while they would be dropped when using LLNs, are not "valid" any more. So in "plain" OLSRv2 packets using such links would be dropped. Using LLN, the convergence time will be decreased, so that a path from the source to the destination can be recalculated faster. =A0 A larger number of the packets remain in the network, =A0 taking a longer route, thus adding extra to the network load, While it is true there may be more packets in the network, the statement "[they] take a longer route" is not really accurate. Without LLN, the packets would have been dropped during the time OLSRv2 needs to converge. You could say that this is a very short path -- right away into the trash can ;-) =A0 impacting the surrounding traffic within interference range of the =A0 loop, and further encouraging a higher chance of an LLN occurring in =A0 a node along the route supporting the traffic by collision. =A0The =A0 negative effect of increased packet looping caused by LLN works =A0 against the gains from avoiding dropping packets over broken links =A0 that plagues 'plain' OLSRv2. The negative effect as load increases =A0 may exceed the gains, thus causing a greater overall loss. Hmm, sorry, but I really don't understand how you would have more loops by using L2 notifications. I am also running my own OLSRv2 implementation (JOLSRv2) with L2 notifications on Ns2, and I did not experience loops. Maybe you could explain using your example, where exactly you would have routing loops. My intuition is that using L2 notifications might even reduce the number of temporary loops, since the convergence time is decreased. Best regards, Ulrich On Tue, May 26, 2009 at 11:24 AM, Lee Speakman wrote: > > Dear MANET WG members, > > we at Niigata University have implemented and tested the OLSRv2 protocol > according to a recent draft. > > The implementation has been put to use in simulation and real world > physical nodes. > > Simulation under various scenarios indicate that the use of LLN (Link > Layer Notification) leads to a looping packets becoming a problem in the > network. > > In larger networks where the TTL or Hop Count cannot be kept small, and > particularly at higher loads, the problem of looping packets become more > significant. > > To this end we put forward an Internet draft available in the following > link: > > http://www.ietf.org/internet-drafts/draft-speakman-manet-looping-issue-00= .txt > > > We'd be grateful for your consideration and input. > > > Regards, > Lee Speakman > Research Center for Natural Hazard and Disaster Recovery, Niigata, Japan > > Kenichi Mase > Graduate School of Science and Technology, Niigata University, Japan > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From delta@net.ie.niigata-u.ac.jp Thu May 28 03:06:21 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 203BD3A6A13 for ; Thu, 28 May 2009 03:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.139 X-Spam-Level: ** X-Spam-Status: No, score=2.139 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIubzJD8Yu2J for ; Thu, 28 May 2009 03:06:19 -0700 (PDT) Received: from mxav01.cc.niigata-u.ac.jp (mxav01.cc.niigata-u.ac.jp [133.35.17.129]) by core3.amsl.com (Postfix) with ESMTP id 7F72E3A68E7 for ; Thu, 28 May 2009 03:06:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BB9164F42AC; Thu, 28 May 2009 19:06:46 +0900 (JST) Received: from ms01.net.ie.niigata-u.ac.jp (ms01.net.ie.niigata-u.ac.jp [133.35.156.1]) by mxav01.cc.niigata-u.ac.jp (Postfix) with ESMTP id 4CDC94F42AC; Thu, 28 May 2009 19:06:39 +0900 (JST) Received: from msq82.net.ie.niigata-u.ac.jp (ms05.net.ie.niigata-u.ac.jp [133.35.156.5]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id EB37D11DE4; Thu, 28 May 2009 19:06:35 +0900 (JST) Message-ID: <4A1E6110.7030305@net.ie.niigata-u.ac.jp> Date: Thu, 28 May 2009 19:01:52 +0900 From: Lee Speakman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Ulrich Herberg References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <25c114b90905260445y54449801v4398e1bdf51ad07b@mail.gmail.com> In-Reply-To: <25c114b90905260445y54449801v4398e1bdf51ad07b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mase , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 10:06:21 -0000 Dear Ulrich, thank you for your comments, replies inline... > > The effect of this is to cause the Link Set in the node that has the > LLN to change the link over which the packet was dropped from > Symmetric to Lost ahead of the symmetric link timeouts between the > nodes. The surrounding nodes will still have knowledge of the > existence of this link, and the link will still exist in the Topology > Sets in the rest of the network for some time, possibly leading to > the formation of a loop. > > > Well, as soon as the link has been set to LOST by the LLN, a HELLO > will be triggered and the neighbors are informed that this link is > indeed lost. This is not different than using "plain" OLSRv2, only > that the time the link is advertized (even though it's already gone) > is reduced. I don't understand why that should speed up temporary > routing loop forming. > Yes, the change of state is not different between plain OLSRv2 and OLSRv2 with LLN. Only the time at which a link state may change to LOST under "plain" OLSRv2 is three times the Hello Period of the last received Hello Packet from the respective node, as opposed to OLSRv2 with LLN which may change the link state shortly after the link is established and confirmed by Hello. The way the change of link state in the next Hello Packet is advertised is the same between the two. As such, loops have been seen to form under "plain" OLSRv2, however, they are much fewer than the loops under OLSRv2-LLN. In the paper [6] referred to in the draft, we consider a set time and explain how a loop forms naturally for a short "transient" time and then is naturally dissolved as the routing protocol communicates the latest link state information with the rest of nodes in the network. With LLN, the rate at which these transient routing loops are dissolved is not changed, however, the changes in link state occur much more frequently as it caused by the non-delivery of packets to the next hop. > > The effect of LLN is to ultimately speed > the process by which a routing loop forms. Node 3 or node 4 in > Figure 1 may not have to wait for a full three times the Hello > Interval before the Link Set changes its state from Symmetric. > > As LLN is triggered on the failure of a data packet to be forwarded > over a link > > > Probably, the LLN should not be triggered if only a single packet is > lost. Rather, decrease the Link Quality of that link using some sort > of "smooth" function as described in the OLSRv2 draft. > Even if the LLN is only triggered after dropping three consecutive packets forwarded at the network layer, the action of the LLN is to make link-state changes over and above the link-state changes that occur simply from links timing out after not receiving a Hello for some time. For every link-state change that occurs in node, there is a likelihood that a routing loop will be created, which can only be corrected when the in-node link-state is advertised in its following control packets. This document describes the routing loop and packet looping issues in mobile ad hoc network (MANET) running proactive routing protocols using hop count metric. Using Link Hysteresis with OLSRv2 with the Link Quality based on the Hellos received, we have found improvement in performance upon OLSRv2, but not nearly as much as that provided by OLSRv2 with LLN with a Packet Discard on Looping Packet Detection, as OLSRv2 with LH (Link Hysteresis) still has the problem of forwarded packets over physically dead links. Using a Path Metric may also help reduce the number of loops, but an accurate Path Metric takes time to create and is limited by node mobility. > > and the number of LLNs increases with the amount of > traffic in the network, the number of routing loops also increases > with the amount traffic in the network. > > > Why is this a logical implication? > An LLN only occurs on the failure of a unicast data packet to be forwarded from one node to the next. If the traffic is increased, the likelihood of collisions and interference is also increased leading to the increased likelihood that a unicast data packet will fail to be forwarded to the next hop, thus leading to a LLN (after several attempts at forwarding) and a change of link-state of that link to LOST. > > Furthermore, as LLN results > in the removal of links at a rate over and above that by timeouts in > 'plain' OLSRv2, the total number of links in the network is further > reduced thus increasing the average distance from any source to > destination. > > > The links that "plain" OLSRv2 keeps while they would be dropped when > using LLNs, are not "valid" any more. So in "plain" OLSRv2 packets > using such links would be dropped. Using LLN, the convergence time > will be decreased, so that a path from the source to the destination > can be recalculated faster. > Total convergence time is decreased as in OLSRv2 with LLN non-performing links are removed, but if the network is continually changing, perhaps due to mobility, a number of "convergences" are caused by LLNs removing non-performing links, in an equivalent period in which plain OLSRv2 would simply have been forwarding the packet over the original non-performing link. > > A larger number of the packets remain in the network, > taking a longer route, thus adding extra to the network load, > > > While it is true there may be more packets in the network, the > statement "[they] take a longer route" is not really accurate. Without > LLN, the packets would have been dropped during the time OLSRv2 needs > to converge. You could say that this is a very short path -- right > away into the trash can ;-) > That's right, with plain OLSRv2, some of the perceived routes lead to packets being continually forwarded over a non-performing link for the duration of the existence of that link being Symmetric in the forwarding node's Link Set. With LLN, it is observed that end-to-end delivered packets on average take a longer route, so this ignores these short routes which are incapable of delivering packets to the destination. However we have seen another effect as given in the paper. The effect of transient looping packets is to increase the effective load on the network and in the medium, increasing the likelihood that this extra load will have collision with existing traffic, thus causing some of this surrounding traffic to be dropped, leading to LLNs and more links being removed from the link sets. This results in slightly longer routes to the destination, also further leading to an increased effective load in the network. > > impacting the surrounding traffic within interference range of the > loop, and further encouraging a higher chance of an LLN occurring in > a node along the route supporting the traffic by collision. The > negative effect of increased packet looping caused by LLN works > against the gains from avoiding dropping packets over broken links > that plagues 'plain' OLSRv2. The negative effect as load increases > may exceed the gains, thus causing a greater overall loss. > > > Hmm, sorry, but I really don't understand how you would have more > loops by using L2 notifications. I am also running my own OLSRv2 > implementation (JOLSRv2) with L2 notifications on Ns2, and I did not > experience loops. Maybe you could explain using your example, where > exactly you would have routing loops. My intuition is that using L2 > notifications might even reduce the number of temporary loops, since > the convergence time is decreased. > We found, as given in figure 2, that LLN improves over "plain" OLSRv2, but as the load is increased, the number of routing loops increases and soon falls to below the performance (PDR) of plain OLSRv2. The cause of this, as found by packet traces, was due to looping packets. This was further confirmed by setting up a looping packet detection technique and discarding looping packets, which resulted in the PDR being significantly improved. Simulations were performed in Qualnet 4 with 60 nodes, The load was controlled by using CBR applications and changing the number of applications. At very low loads there are no loops. Less loops are also seen at higher node- or link-density. But we still observe looping packets at moderate loads and link densities. The example in section 4 and 5 of the draft is taken from the paper in [6] with the help of a time chart and there is another earlier example we expressed in the IEEE CQR Workshop, 2008. In your simulation for increasing offered load do you find a much more rapidly decreasing performance in OLSRv2 with LLN over that for plain OLSRv2 similar to figure 2 in the draft? Thanks for your comments. Cheers, Lee -S- Lee Speakman, Research Center for Natural Hazard and Disaster Recovery, Niigata, Japan Ref. http://www.ietf.org/internet-drafts/draft-speakman-manet-looping-issue-00.txt From Chris.Dearlove@baesystems.com Fri May 29 05:35:10 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 589233A6E22 for ; Fri, 29 May 2009 05:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.317 X-Spam-Level: X-Spam-Status: No, score=-4.317 tagged_above=-999 required=5 tests=[AWL=-1.718, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqoOOXpDVEdi for ; Fri, 29 May 2009 05:35:09 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 4B36F3A6C09 for ; Fri, 29 May 2009 05:35:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,271,1241391600"; d="scan'208";a="4645360" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 29 May 2009 13:28:59 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n4TCSx5j021508; Fri, 29 May 2009 13:28:59 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 May 2009 13:28:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 29 May 2009 13:28:59 +0100 Message-ID: In-Reply-To: <4A1E6110.7030305@net.ie.niigata-u.ac.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" thread-index: AcnffEVd0cm5NQPxQ+y1+WWO/jfRugA3CQ9w References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp><25c114b90905260445y54449801v4398e1bdf51ad07b@mail.gmail.com> <4A1E6110.7030305@net.ie.niigata-u.ac.jp> From: "Dearlove, Christopher (UK)" To: "Lee Speakman" , "Ulrich Herberg" X-OriginalArrivalTime: 29 May 2009 12:28:59.0183 (UTC) FILETIME=[0AA163F0:01C9E059] Cc: mase , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 12:35:10 -0000 > An LLN only occurs on the failure of a unicast data packet to be > forwarded from one node to the next. Note that this is not a specification of OLSRv2. OLSRv2 specifies that if you have link layer information, you can use it. But it doesn't specify anything about whether to use unicast data packets or not. Our implementation of OLSR, which uses link layer information is not specified as you have it above. I would like to know if this is simply the work previously presented at the IETF. That work was demonstrably flawed - as could be seen from the stationary case, and discussions then indicated a poor LLN approach. ******************************************************************** 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 philippe.jacquet@inria.fr Fri May 29 06:20:36 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76CDE28C14F for ; Fri, 29 May 2009 06:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRK+uPzDZI7o for ; Fri, 29 May 2009 06:20:33 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id DB2B528C173 for ; Fri, 29 May 2009 06:20:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,271,1241388000"; d="scan'208";a="27023271" Received: from sphinx.lix.polytechnique.fr (HELO mp-r8.local) ([129.104.11.1]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 May 2009 15:21:15 +0200 Message-ID: <4A1FE2EC.5060406@inria.fr> Date: Fri, 29 May 2009 15:28:12 +0200 From: jacquet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Lee Speakman References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> In-Reply-To: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 13:20:36 -0000 Seems interesting. I remember that with old RFC 3626 we assumed that a node which detects a link failure, either by LLN or by hello loss, should immediately issue: 1. a hello with lost indication 2. a TC with a new MPR selector set number since one MPR selector is down. A loop could only happen after the loss detection, during the jitter time of notification hellos and/or TC's. Here I don't see how the LLN option could bring a significant distortion. Philippe Lee Speakman a écrit : > Dear MANET WG members, > > we at Niigata University have implemented and tested the OLSRv2 protocol > according to a recent draft. > > The implementation has been put to use in simulation and real world > physical nodes. > > Simulation under various scenarios indicate that the use of LLN (Link > Layer Notification) leads to a looping packets becoming a problem in the > network. > > In larger networks where the TTL or Hop Count cannot be kept small, and > particularly at higher loads, the problem of looping packets become more > significant. > > To this end we put forward an Internet draft available in the following > link: > > http://www.ietf.org/internet-drafts/draft-speakman-manet-looping-issue-00.txt > > > We'd be grateful for your consideration and input. > > > Regards, > Lee Speakman > Research Center for Natural Hazard and Disaster Recovery, Niigata, Japan > > Kenichi Mase > Graduate School of Science and Technology, Niigata University, Japan > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > From hrogge@googlemail.com Fri May 29 06:55:15 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F47A3A69B2 for ; Fri, 29 May 2009 06:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2+5J5g4vmNr for ; Fri, 29 May 2009 06:55:14 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id D8D663A6810 for ; Fri, 29 May 2009 06:55:13 -0700 (PDT) Received: by ewy24 with SMTP id 24so6279072ewy.37 for ; Fri, 29 May 2009 06:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=D4OkPavhczootsaA5zdmcjrwz3ozHjJzKlY5hTJ2QPc=; b=kIvo6YAQQHkqy4oRngJ0UKKa6vGOGM9aSppxNp4hTnw3f8Owq6IS215n/8z5aqYvvM rWdnNqMWx1uSGSOeStWyxr2EGgeKq04J6zmPZnVgoltgb8yn7+xtedpbu/X6lkFCBQ1D JUB+ci+Lwj3T1fKdJKjsfDc/3Pkt1GYYKjrX8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=q6qg8mpn+lVt4mtbbOkZz3BDLhdqwkb7XwBPQ1oe0LD8KXc8LW5WpPtVB+YjXouwYS R2/DVTJuhtsfp9oLmiFk/hNExYeViCqLWf4/v3Vqg5jOg7xSOpa+t/EIo9cW4iXbfmPE GYXW1BuuGnA0RZgbu9UOy+F5K6dij8VmK6TvA= Received: by 10.210.115.17 with SMTP id n17mr1513727ebc.86.1243605250970; Fri, 29 May 2009 06:54:10 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 28sm2651621eye.16.2009.05.29.06.54.09 (version=SSLv3 cipher=RC4-MD5); Fri, 29 May 2009 06:54:09 -0700 (PDT) From: Henning Rogge To: manet@ietf.org Date: Fri, 29 May 2009 15:54:03 +0200 User-Agent: KMail/1.11.3 (Linux/2.6.29-gentoo-r5; KDE/4.2.3; x86_64; ; ) References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> In-Reply-To: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3526998.8GaTmnC6uj"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200905291554.08786.hrogge@googlemail.com> Cc: Lee Speakman Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 13:55:15 -0000 --nextPart3526998.8GaTmnC6uj Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Am Dienstag 26 Mai 2009 11:24:50 schrieb Lee Speakman: > Dear MANET WG members, > > we at Niigata University have implemented and tested the OLSRv2 protocol > according to a recent draft. > > The implementation has been put to use in simulation and real world > physical nodes. > > Simulation under various scenarios indicate that the use of LLN (Link > Layer Notification) leads to a looping packets becoming a problem in the > network. > > In larger networks where the TTL or Hop Count cannot be kept small, and > particularly at higher loads, the problem of looping packets become more > significant. I would be interested in the radio model you used for your simulations. Henning Rogge --nextPart3526998.8GaTmnC6uj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkof6QAACgkQcenvcwAcHWeo7wCdGnSf9qwERaD7IFvE217irf2q iewAn3ZvKre7esIlVB42VxYnPhuYjT4A =MZLs -----END PGP SIGNATURE----- --nextPart3526998.8GaTmnC6uj--