From kavithaammayappan@gmail.com Thu Apr 2 04:27:24 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 DA0253A69EA for ; Thu, 2 Apr 2009 04:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 KEZigzkYDvYT for ; Thu, 2 Apr 2009 04:27:24 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 2135E3A680F for ; Thu, 2 Apr 2009 04:27:24 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so508452rvb.49 for ; Thu, 02 Apr 2009 04:28:25 -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=Jc//CPJExO32Mqp4WKYDhcC/ZDjX1J6C9ixFmREdV3M=; b=clDT3oE3B6DTli+Sn8CAEii4MKQm4KClmWK1f0GzZhCaAwjCUZce52D1yAu0HtUDMj VfCi6V+juDwChYDuIhO7JwK5QcLdNybz++aSI8z4VVvJojh2NMt2FCDPiRBsMkT9zfuV G6nd5jaNg/530gg5HGD4G2IXB9mTqNxuEVq1c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Ez7y95EJyobeQQKPlhaUa33hCMxjZ62V1wjqKV0Xv07EJFutAATC8sABxUmxne4D3D RqFM7YYTD9UAkBpyAWu7YP4CgBLGRQ9qrzUiE5q+j75rkSJA79i3ZIQwWRnjLXKNGM81 0ovJ3cVTOTIDKVsk5MQl/VPow6waAAqIEgQA8= MIME-Version: 1.0 Received: by 10.141.87.13 with SMTP id p13mr4521683rvl.166.1238671705568; Thu, 02 Apr 2009 04:28:25 -0700 (PDT) Date: Thu, 2 Apr 2009 16:58:25 +0530 Message-ID: <87772ea0904020428h4e72f542hc3ba112d1ee29493@mail.gmail.com> From: Kavitha Ammayappan To: manet@ietf.org Content-Type: multipart/alternative; boundary=000e0cd1519a00f6c3046690bb09 Subject: [manet] can anybody clarify the meaning of node compromise 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, 02 Apr 2009 11:27:25 -0000 --000e0cd1519a00f6c3046690bb09 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear All Could anybody calrify the node compromise in mobile ad hoc network scenario? Regards Kavitha -- "Every one is the architect of his own fortune." Mathurin Regnier --000e0cd1519a00f6c3046690bb09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All
=C2=A0
Could anybody calrify the node compromise in mobile ad hoc network sce= nario?
=C2=A0
=C2=A0
=C2=A0
Regards
Kavitha

--
"Every one is the architect = of his own fortune." =C2=A0 Mathurin Regnier
--000e0cd1519a00f6c3046690bb09-- From jfdsmit@gmail.com Thu Apr 2 04:29: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 CE9AB3A694F for ; Thu, 2 Apr 2009 04:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH8TmNSPmgaf for ; Thu, 2 Apr 2009 04:29:22 -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 E531D3A67FA for ; Thu, 2 Apr 2009 04:29:21 -0700 (PDT) Received: by fxm2 with SMTP id 2so471052fxm.37 for ; Thu, 02 Apr 2009 04:30:22 -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 :content-transfer-encoding; bh=bZV28tBKN9Y2zRbk2bVapD8PIFeQOKH7nqYzbGIVXNM=; b=wnyJMDxrFBQ850SjJQpPzQ1kNp1JeJV+5BiOUhfhey1BxeeQzOkMcWvLmEhZOgy4nv bixSRs42HSaHW7iWJ71bneydUH0UCjbC4c2eMqX5anflX38mvd8RkPtzSYqLZN6T7R+b WpicEj8RD1TRldAdNJcGihVI57I+SsOjMZ1ZI= 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:content-transfer-encoding; b=ORaMA8rJ2nM1w4T2TqqxYcDywvRTa6p5SzeFa8zoQjwVhv66QpVt/6jaTyR/rYoYUF AmiBwhTmP/5/dtqzT7sgudJ1Hk3++NuRkxCBsBW1u6aL2q0KyaFLJm9DtTiXwImvF7ZJ aQo8jFJXsDLe5kvGBV7p1gtj36rqheDpSuxxo= MIME-Version: 1.0 Received: by 10.223.122.15 with SMTP id j15mr7195893far.10.1238671822159; Thu, 02 Apr 2009 04:30:22 -0700 (PDT) In-Reply-To: <87772ea0904020428h4e72f542hc3ba112d1ee29493@mail.gmail.com> References: <87772ea0904020428h4e72f542hc3ba112d1ee29493@mail.gmail.com> Date: Thu, 2 Apr 2009 13:30:22 +0200 Message-ID: From: Jens de Smit To: Kavitha Ammayappan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: manet@ietf.org Subject: Re: [manet] can anybody clarify the meaning of node compromise 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, 02 Apr 2009 11:29:22 -0000 2009/4/2 Kavitha Ammayappan : > Dear All > > Could anybody calrify the node compromise in mobile ad hoc network scenario? You hack a node any way possible and use it to mess up the network by misbehaving. Regards, Jens From teco@inf-net.nl Thu Apr 2 05:24:26 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 0A9E83A6A11 for ; Thu, 2 Apr 2009 05:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=0.528, 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 0KVL8JJyRSWV for ; Thu, 2 Apr 2009 05:24:25 -0700 (PDT) Received: from CPSMTPM-EML108.kpnxchange.com (Cpsmtpm-eml108.kpnxchange.com [195.121.3.12]) by core3.amsl.com (Postfix) with ESMTP id 9D4393A68E4 for ; Thu, 2 Apr 2009 05:24:23 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML108.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Thu, 2 Apr 2009 14:25:20 +0200 From: "Teco Boot" To: "'manet'" Date: Thu, 2 Apr 2009 14:25:24 +0200 Message-ID: <00c701c9b38e$18e7eb70$4ab7c250$@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: Acmzjhiu+S5GKrDTRq+BhF9qRRbt7Q== Content-Language: nl X-OriginalArrivalTime: 02 Apr 2009 12:25:20.0820 (UTC) FILETIME=[16EE1740:01C9B38E] Subject: [manet] OLSRv2 - RouterID 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, 02 Apr 2009 12:24:26 -0000 Dear OLSRv2 design team, I have a question on: > OLSRv2 does not make any assumption about router addresses, other > than that each router is assumed to have at least one unique and > routable IP address for each interface that it has which participates > in the MANET. Why is this? It excludes usage of link local addresses. I do not see a hard reason not using LLs, as long as they are unique in the MANET Routing Domain. And LLs are not routable. More important: IPv6 LL addresses are mandatory for IPv6 router interfaces (RFC4861). Currently, LLs that are not MANET-wide unique may not be used by NHDP / OLSRv2. Why isn't there a router identifier? OLSRv1 had this: > main address > The main address of a node, which will be used in OLSR control > traffic as the "originator address" of all messages emitted by > this node. It is the address of one of the OLSR interfaces of > the node. This is removed in OLSRv2. Now it is harder to recognize routers because there is no single router identifier anymore. Interfaces may go up and down or temporally addresses may be used, and as a result the identity changes over time. A scenario that introduces problems: Assume a router with multiple layer-2 Ethernet to 802.11 bridges attached, using VLANs. IPv6 is used, with "default" EUI-64 addressing. The MAC address of a VLAN logical interfaces is the same for all on the same physical interface, and thus the EUI-64 interface-IDs are the same. Uniqueness on each link is OK, assume the MAC address for the physical interface is globally unique. Currently, NHDP does not send the msg-orig-addr but instead sends sets with **all** addresses, for itself and for all neighbors. Moreover, addresses may be identifiers **or** locators. Locators change when an MANET Router moves within the topology (result of definition of locator, as used in IRTF RRG). For SPF calculation, only identifiers for the nodes and their links are needed. A straightforward approach would be unique router identifiers within the routing domain and unique interface identifiers within the scope of each router. For the latter, ifIndex could be used and single octet provides namespace for 256 interfaces using continuous numbering. One may think of extended numbering. A link is identified by a 4-tuple of RouterID and a interface identifier, for itself and the neighbor. I don't think the interface identifiers are needed in the NHDP and OLSRv2 messages. I think the problems can be circumvented by using the following information bases, for NHDP and OLSRv2: (to be verified) Local Information Base Local Interface Set ifIndex # added I_local_iface_addr # I_manet Removed Interface Address Set ifIndex # added IR_local_iface_addr IR_time Originator Set # not required if orig_addr is stable O_orig_addr O_time Local Attached Network Set AL_net_addr AL_dist Interface Information Bases Link Set ifIndex # added L_orig_addr # L_ifIndex # needed ?? L_HEARD_time L_SYM_time L_quality L_pending L_lost L_time 2-Hop Set ifIndex # added N2_orig_addr # L_ifIndex # needed ?? N2_2H_orig_addr N2_time Neighbor Information Base Neighbor Set N_orig_addr # N_symmetric N_willingness N_mpr N_mpr_selector Lost Neighbor Set NL_orig_addr # NL_time Topology Information Base Advertised Neighbor Set A_orig_addr # Advertising Remote Router Set AR_orig_addr # AR_seq_number AR_time Topology Set T_dest_orig_addr # T_orig_addr T_seq_number T_time Attached Network Set AN_net_addr AN_orig_addr AN_dist AN_seq_number AN_time Routing Set R_dest_addr R_next_iface_addr R_dist R_local_ifIndex # Processing and Forwarding Information Base Received Set RX_type RX_orig_addr RX_seq_number RX_time Processed Set P_type P_orig_addr P_seq_number P_time Forwarded Set F_type F_orig_addr F_seq_number F_time Relay Set RY_neighbor_orig_addr # As a result, the NHDP hello messages must contain msg-orig-addr (may be suppressed if IP header source address is msg-orig-addr). This may be a small increase of the size of the packets. But other messages would be largely reduced in size, as not ALL addresses are advertized anymore. Each router identifier (orig-addr) represents all addresses of all interfaces of the router. Also unidirectional links become available for routing, as long as there is a pair of unidirectional links (in opposite directions). This is desirable qualitative properties #7 of MANET routing protocols (RFC2501). I discussed this with Thomas Clausen in SF last week. His first response was that I was somewhat late with this enhancement. I have to agree. But I think it is worth to consider. Better late than never. Teco. From Rogge@fgan.de Thu Apr 2 05:43: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 EB4513A6827 for ; Thu, 2 Apr 2009 05:43: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_DE=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 SRAS2owQJMBO for ; Thu, 2 Apr 2009 05:43:35 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 3F5C53A67AC for ; Thu, 2 Apr 2009 05:43:35 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1LpMHb-0005QC-Ai; Thu, 02 Apr 2009 14:44:35 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1LpMHa-000360-W8; Thu, 02 Apr 2009 14:44:35 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 14:44:34 +0200 From: Henning Rogge To: manet@ietf.org Date: Thu, 2 Apr 2009 14:44:28 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.26-1-openvz-686; KDE/4.1.4; i686; ; ) References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> In-Reply-To: <00c701c9b38e$18e7eb70$4ab7c250$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10500254.ZHTSTaUpo7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904021444.34251.rogge@fgan.de> X-OriginalArrivalTime: 02 Apr 2009 12:44:34.0749 (UTC) FILETIME=[C6B9AED0:01C9B390] X-Virus-Scanned: yes (ClamAV 0.94.2/9198/Thu Apr 2 08:50:41 2009) by mailguard.fgan.de X-Scan-Signature: b1815913409d069caac6ebf7e977740c Subject: Re: [manet] OLSRv2 - RouterID 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, 02 Apr 2009 12:43:37 -0000 --nextPart10500254.ZHTSTaUpo7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Thursday 02 April 2009 14:25:24 schrieb Teco Boot: > Dear OLSRv2 design team, > > I have a question on: > > OLSRv2 does not make any assumption about router addresses, other > > than that each router is assumed to have at least one unique and > > routable IP address for each interface that it has which participates > > in the MANET. > > Why is this? It excludes usage of link local addresses. I do not see a ha= rd > reason not using LLs, as long as they are unique in the MANET Routing > Domain. And LLs are not routable. > > More important: IPv6 LL addresses are mandatory for IPv6 router interfaces > (RFC4861). > > Currently, LLs that are not MANET-wide unique may not be used by NHDP / > > OLSRv2. Why isn't there a router identifier? OLSRv1 had this: > > main address > > The main address of a node, which will be used in OLSR control > > traffic as the "originator address" of all messages emitted by > > this node. It is the address of one of the OLSR interfaces of > > the node. > > This is removed in OLSRv2. Now it is harder to recognize routers because > there is no single router identifier anymore. Interfaces may go up and do= wn > or temporally addresses may be used, and as a result the identity changes > over time. I have to agree to this (and was in the process writing a similar mail). It's not necessary for OLSR to use interface IPs in TCs and Hellos, a singl= e=20 "Originator IP" for the router instance would be enough to calculate the=20 route. > A scenario that introduces problems: > Assume a router with multiple layer-2 Ethernet to 802.11 bridges attached, > using VLANs. IPv6 is used, with "default" EUI-64 addressing. > The MAC address of a VLAN logical interfaces is the same for all on the > same physical interface, and thus the EUI-64 interface-IDs are the same. > Uniqueness on each link is OK, assume the MAC address for the physical > interface is globally unique. > > Currently, NHDP does not send the msg-orig-addr but instead sends sets wi= th > **all** addresses, for itself and for all neighbors. Moreover, addresses > may be identifiers **or** locators. Locators change when an MANET Router > moves within the topology (result of definition of locator, as used in IR= TF > RRG). > > For SPF calculation, only identifiers for the nodes and their links are > needed. A straightforward approach would be unique router identifiers > within the routing domain and unique interface identifiers within the sco= pe > of each router. For the latter, ifIndex could be used and single octet > provides namespace for 256 interfaces using continuous numbering. One may > think of extended numbering. A link is identified by a 4-tuple of RouterID > and a interface identifier, for itself and the neighbor. I don't think the > interface identifiers are needed in the NHDP and OLSRv2 messages. > > I think the problems can be circumvented by using the following informati= on > bases, for NHDP and OLSRv2: > (to be verified) > > Local Information Base > Local Interface Set > ifIndex # added > I_local_iface_addr # > I_manet > Removed Interface Address Set > ifIndex # added > IR_local_iface_addr > IR_time > Originator Set # not required if orig_addr is stable > O_orig_addr > O_time > Local Attached Network Set > AL_net_addr > AL_dist > > Interface Information Bases > Link Set > ifIndex # added > L_orig_addr # > L_ifIndex # needed ?? > L_HEARD_time > L_SYM_time > L_quality > L_pending > L_lost > L_time > 2-Hop Set > ifIndex # added > N2_orig_addr # > L_ifIndex # needed ?? > N2_2H_orig_addr > N2_time > > Neighbor Information Base > Neighbor Set > N_orig_addr # > N_symmetric > N_willingness > N_mpr > N_mpr_selector > Lost Neighbor Set > NL_orig_addr # > NL_time > > Topology Information Base > Advertised Neighbor Set > A_orig_addr # > Advertising Remote Router Set > AR_orig_addr # > AR_seq_number > AR_time > Topology Set > T_dest_orig_addr # > T_orig_addr > T_seq_number > T_time > Attached Network Set > AN_net_addr > AN_orig_addr > AN_dist > AN_seq_number > AN_time > Routing Set > R_dest_addr > R_next_iface_addr > R_dist > R_local_ifIndex # > > Processing and Forwarding Information Base > Received Set > RX_type > RX_orig_addr > RX_seq_number > RX_time > Processed Set > P_type > P_orig_addr > P_seq_number > P_time > Forwarded Set > F_type > F_orig_addr > F_seq_number > F_time > Relay Set > RY_neighbor_orig_addr # > I don't think using an interface index would be a good idea, because it's O= S=20 dependent how this ids are handled (and what happens when an interface is=20 down). We used a similar idea in the OLSR.org implementation and had/have=20 lot's of trouble when interfaces are down for a moment (because you cannot= =20 convert the interface index into the interface data during this time !) I think it would be easier if each NHDP link has stored a "next hop" IP in= =20 addition to the originator IP of the other side of the link. This way the=20 local node can forward packages to the interface IP of the other side witho= ut=20 advertising this IPs at all. The topology database does not need to know about the interfaces between=20 distant nodes at all, only that there is a connection between the nodes. Th= is=20 way we could reduce the amount of change OLSRv2 and NHDP need. > As a result, the NHDP hello messages must contain msg-orig-addr (may be > suppressed if IP header source address is msg-orig-addr). This may be a > small increase of the size of the packets. But other messages would be > largely reduced in size, as not ALL addresses are advertized anymore. Each > router identifier (orig-addr) represents all addresses of all interfaces = of > the router. > > Also unidirectional links become available for routing, as long as there = is > a pair of unidirectional links (in opposite directions). This is desirable > qualitative properties #7 of MANET routing protocols (RFC2501). Using unidirectional links is not a good idea in my oppinion, especially on= =20 wireless links. Some layer 2 technologies (like 802.11) cannot send unicast= =20 traffic on unidirectional links. My proposal would be to allow NHDP and OLSRv2 to send an unique router-id (= ip=20 address) instead of interface IPs. The only difficulty in this approach is= =20 that a node receiving a NHDP package would have to discover the interface I= P=20 of the originator of this package. This could be done either done by using= =20 information from lower protocol layers (IP source address of the incoming=20 broadcast) or the interface IP would have to be included into the NHDP=20 package. Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart10500254.ZHTSTaUpo7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAknUsywACgkQRIfGfFXsz+B6qQCgrGO1en1TaWqxvfwd+xkyaRxK AKAAoJZnCYYBIa6zk3uLKFTrE80uzPi8 =Cr2U -----END PGP SIGNATURE----- --nextPart10500254.ZHTSTaUpo7-- From sratliff@cisco.com Thu Apr 2 05:53: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 CDD8F3A684B for ; Thu, 2 Apr 2009 05:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 85glChseZIEe for ; Thu, 2 Apr 2009 05:53:18 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 394983A6885 for ; Thu, 2 Apr 2009 05:53:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,314,1235952000"; d="scan'208";a="40767695" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 02 Apr 2009 12:54:18 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n32CsI43006608; Thu, 2 Apr 2009 08:54:18 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n32CsIWP012725; Thu, 2 Apr 2009 12:54:18 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 08:54:18 -0400 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: quoted-printable Date: Thu, 2 Apr 2009 08:54:17 -0400 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76407ED9012@xmb-rtp-208.amer.cisco.com> In-Reply-To: <00c701c9b38e$18e7eb70$4ab7c250$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acmzjhiu+S5GKrDTRq+BhF9qRRbt7QAA6Vhg References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> From: "Stan Ratliff (sratliff)" To: "Teco Boot" , "manet" X-OriginalArrivalTime: 02 Apr 2009 12:54:18.0926 (UTC) FILETIME=[22EC04E0:01C9B392] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6269; t=1238676858; x=1239540858; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[manet]=20OLSRv2=20-=20RouterID |Sender:=20 |To:=20=22Teco=20Boot=22=20,=20=22manet=22 =20; bh=6ZhSS1PQ9mTWjMfEOrg7Op3snKk9TQ7o3tzrWo5mz4A=; b=KKQDeiOVx7UeN8fz+sl1BSRbjfdLHcZt/6zI8cNL1fktiCeLLQIw2uYiAZ TuD5gfp5HAM0dh2ejEo0FLuVeJDy7LS7aFap4Sb07Ypst8fL3/C6Unn5gvYh aMKmBinVzh; Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [manet] OLSRv2 - RouterID 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, 02 Apr 2009 12:53:19 -0000 Teco,=20 One question inline.=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org]=20 > On Behalf Of Teco Boot > Sent: Thursday, April 02, 2009 8:25 AM > To: 'manet' > Subject: [manet] OLSRv2 - RouterID >=20 > Dear OLSRv2 design team, >=20 > I have a question on: >=20 > > OLSRv2 does not make any assumption about router addresses,=20 > other than=20 > > that each router is assumed to have at least one unique and=20 > routable=20 > > IP address for each interface that it has which participates in the=20 > > MANET. >=20 > Why is this? It excludes usage of link local addresses. I do=20 > not see a hard reason not using LLs, as long as they are=20 > unique in the MANET Routing Domain. And LLs are not routable. >=20 > More important: IPv6 LL addresses are mandatory for IPv6=20 > router interfaces (RFC4861). >=20 > Currently, LLs that are not MANET-wide unique may not be used=20 > by NHDP / OLSRv2. Why isn't there a router identifier? OLSRv1=20 > had this: >=20 > > main address > > The main address of a node, which will be used in OLSR control > > traffic as the "originator address" of all messages emitted by > > this node. It is the address of one of the OLSR interfaces of > > the node. >=20 > This is removed in OLSRv2. Now it is harder to recognize=20 > routers because there is no single router identifier anymore.=20 > Interfaces may go up and down or temporally addresses may be=20 > used, and as a result the identity changes over time.=20 >=20 > A scenario that introduces problems: > Assume a router with multiple layer-2 Ethernet to 802.11=20 > bridges attached, using VLANs. IPv6 is used, with "default"=20 > EUI-64 addressing. > The MAC address of a VLAN logical interfaces is the same for=20 > all on the same physical interface, and thus the EUI-64=20 > interface-IDs are the same. > Uniqueness on each link is OK, assume the MAC address for the=20 > physical interface is globally unique. >=20 > Currently, NHDP does not send the msg-orig-addr but instead=20 > sends sets with > **all** addresses, for itself and for all neighbors.=20 > Moreover, addresses may be identifiers **or** locators.=20 > Locators change when an MANET Router moves within the=20 > topology (result of definition of locator, as used in IRTF RRG). >=20 > For SPF calculation, only identifiers for the nodes and their=20 > links are needed. A straightforward approach would be unique=20 > router identifiers within the routing domain and unique=20 > interface identifiers within the scope of each router. For=20 > the latter, ifIndex could be used and single octet provides=20 > namespace for 256 interfaces using continuous numbering. One=20 > may think of extended numbering. A link is identified by a=20 > 4-tuple of RouterID and a interface identifier, for itself=20 > and the neighbor. I don't think the interface identifiers are=20 > needed in the NHDP and OLSRv2 messages. >=20 Forgive me if this is a silly question, but how would you use a 4-tuple on a multi-access link like an Ethernet? replicate the local information for each OLSR neighbor? Regards, Stan > I think the problems can be circumvented by using the=20 > following information bases, for NHDP and OLSRv2: > (to be verified) > =09 > Local Information Base =09 > Local Interface Set=09 > ifIndex # added > I_local_iface_addr #=20 > I_manet > Removed Interface Address Set=09 > ifIndex # added > IR_local_iface_addr > IR_time > Originator Set # not required if orig_addr is stable > O_orig_addr =20 > O_time > Local Attached Network Set=09 > AL_net_addr > AL_dist > =09 > Interface Information Bases =09 > Link Set=09 > ifIndex # added > L_orig_addr # > L_ifIndex # needed ?? > L_HEARD_time > L_SYM_time > L_quality > L_pending > L_lost > L_time > 2-Hop Set=09 > ifIndex # added > N2_orig_addr # > L_ifIndex # needed ?? > N2_2H_orig_addr > N2_time > =09 > Neighbor Information Base =09 > Neighbor Set =09 > N_orig_addr # > N_symmetric > N_willingness > N_mpr > N_mpr_selector > Lost Neighbor Set > NL_orig_addr # > NL_time >=20 > Topology Information Base =09 > Advertised Neighbor Set =09 > A_orig_addr # > Advertising Remote Router Set=09 > AR_orig_addr # > AR_seq_number > AR_time > Topology Set =09 > T_dest_orig_addr # > T_orig_addr =20 > T_seq_number > T_time > Attached Network Set=09 > AN_net_addr > AN_orig_addr > AN_dist > AN_seq_number > AN_time > Routing Set=09 > R_dest_addr > R_next_iface_addr > R_dist > R_local_ifIndex # > =09 > Processing and Forwarding Information Base =09 > Received Set=09 > RX_type > RX_orig_addr > RX_seq_number > RX_time > Processed Set=09 > P_type > P_orig_addr > P_seq_number > P_time > Forwarded Set=09 > F_type > F_orig_addr > F_seq_number > F_time > Relay Set =09 > RY_neighbor_orig_addr # >=20 >=20 > As a result, the NHDP hello messages must contain=20 > msg-orig-addr (may be suppressed if IP header source address=20 > is msg-orig-addr). This may be a small increase of the size=20 > of the packets. But other messages would be largely reduced=20 > in size, as not ALL addresses are advertized anymore. Each=20 > router identifier (orig-addr) represents all addresses of all=20 > interfaces of the router.=20 >=20 > Also unidirectional links become available for routing, as=20 > long as there is a pair of unidirectional links (in opposite=20 > directions). This is desirable qualitative properties #7 of=20 > MANET routing protocols (RFC2501). >=20 > I discussed this with Thomas Clausen in SF last week. His=20 > first response was that I was somewhat late with this=20 > enhancement. I have to agree. But I think it is worth to=20 > consider. Better late than never. >=20 >=20 > Teco.=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 From chris.dearlove@baesystems.com Thu Apr 2 05:58:16 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 0AA123A683D for ; Thu, 2 Apr 2009 05:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.633 X-Spam-Level: X-Spam-Status: No, score=-6.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, 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 6FhoQl9z7gZM for ; Thu, 2 Apr 2009 05:58:15 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id A75CE28C201 for ; Thu, 2 Apr 2009 05:58:03 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n32Cx3SA005342 for ; Thu, 2 Apr 2009 13:59:03 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n32Cx3Kn029007 for ; Thu, 2 Apr 2009 13:59:03 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 02 Apr 2009 13:59:02 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.100]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 2 Apr 2009 13:59:02 +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: quoted-printable Date: Thu, 2 Apr 2009 13:59:00 +0100 Message-ID: In-Reply-To: <200904021444.34251.rogge@fgan.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: AcmzkNCOzdYrrp+NQ8CFAkxSkzD+JAAAD/+g References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 02 Apr 2009 12:59:02.0557 (UTC) FILETIME=[CBFAACD0:01C9B392] Subject: Re: [manet] OLSRv2 - RouterID 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, 02 Apr 2009 12:58:16 -0000 > It's not necessary for OLSR to use interface IPs in TCs and Hellos, a single=20 > "Originator IP" for the router instance would be enough to calculate the=20 > route. I'm afraid that is not true. In HELLOs at least you need interface addresses in order for per interface MPR selection to work correctly. And the current design of TC messages is part of how we abolished MID messages from OLSR - and that's a major win in efficiency because MID message forced all multiple addressed nodes to transmit them, while TC messages are only required by MPRs. In addition coordintion between differently timed MID and TC messages is not at all nice, while the current processing is simpler in this regard. I believe these suggestions are failing to appreciate these details. And the serious revision that would be required is exactly what is not what we need at this time. Looking back over drafts, this has been stable in this form since 2006. ******************************************************************** 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 Rogge@fgan.de Thu Apr 2 06:10:01 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 3B0C528C16C for ; Thu, 2 Apr 2009 06:10:01 -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_DE=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 EXPltXpibuqw for ; Thu, 2 Apr 2009 06:09:59 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 6BC073A6452 for ; Thu, 2 Apr 2009 06:09:59 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1LpMh9-0006Mw-MK; Thu, 02 Apr 2009 15:10:59 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1LpMh9-0003IB-8z; Thu, 02 Apr 2009 15:10:59 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 15:10:59 +0200 From: Henning Rogge To: "Dearlove, Christopher (UK)" Date: Thu, 2 Apr 2009 15:10:53 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.26-1-openvz-686; KDE/4.1.4; i686; ; ) References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3443769.MathbZYq1C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904021510.58935.rogge@fgan.de> X-OriginalArrivalTime: 02 Apr 2009 13:10:59.0183 (UTC) FILETIME=[771F1FF0:01C9B394] X-Virus-Scanned: yes (ClamAV 0.94.2/9198/Thu Apr 2 08:50:41 2009) by mailguard.fgan.de X-Scan-Signature: 902864caa043fb1a4eecc12540b64fa7 Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 02 Apr 2009 13:10:01 -0000 --nextPart3443769.MathbZYq1C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Thursday 02 April 2009 14:59:00 schrieb Dearlove, Christopher (UK): > > It's not necessary for OLSR to use interface IPs in TCs and Hellos, a > > single "Originator IP" for the router instance would be enough to > > calculate > > the route. > > I'm afraid that is not true. In HELLOs at least you need interface > addresses in order for per interface MPR selection to work correctly. I'm not sure about this. If each OLSR node does know the interface IPs of it's one hop neighbors thi= s=20 should be enough to calculate the MPR set, because the LOCAL_IF tlv tells i= t=20 which of the two-hop-neighbors are connected to this node through the same= =20 interface (value THIS_IF). > And the current design of TC messages is part of how we abolished MID > messages from OLSR If each OLSR node does only have one routable IP for "long range" (more tha= n=20 2-hop) traffic, MIDs are not necessary. > - and that's a major win in efficiency because MID message forced all > multiple addressed nodes to transmit them, while TC messages are only > required by MPRs. MIDs are necessary to solve map the multiple identities of OLSR interface I= Ps=20 to a single OLSR node. Without multiple IPs for the same router in TCs, the= re=20 is no need for MIDs too. Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart3443769.MathbZYq1C Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAknUuV4ACgkQRIfGfFXsz+AOAQCePBPZRGYinqWAANxhCj+1/3Jt oK8AnizbDVnh281Cdx8ex+QjjUosgBK7 =2O1N -----END PGP SIGNATURE----- --nextPart3443769.MathbZYq1C-- From teco@inf-net.nl Thu Apr 2 06:10:24 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 1CD7028C1E4 for ; Thu, 2 Apr 2009 06:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.516, 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 X3admpCheRfL for ; Thu, 2 Apr 2009 06:10:22 -0700 (PDT) Received: from CPSMTPM-EML109.kpnxchange.com (Cpsmtpm-eml109.kpnxchange.com [195.121.3.13]) by core3.amsl.com (Postfix) with ESMTP id 2EA333A6452 for ; Thu, 2 Apr 2009 06:10:21 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML109.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Thu, 2 Apr 2009 15:11:22 +0200 From: "Teco Boot" To: "'Henning Rogge'" References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> In-Reply-To: <200904021444.34251.rogge@fgan.de> Date: Thu, 2 Apr 2009 15:11:25 +0200 Message-ID: <00d001c9b394$86cb1e40$94615ac0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmzkOvUV7yKhE34SLuBX+23+HTMSwAArH3A Content-Language: nl X-OriginalArrivalTime: 02 Apr 2009 13:11:22.0495 (UTC) FILETIME=[850440F0:01C9B394] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 02 Apr 2009 13:10:24 -0000 Inline. |-----Oorspronkelijk bericht----- |Van: Henning Rogge [mailto:rogge@fgan.de] |Verzonden: donderdag 2 april 2009 14:44 |Aan: manet@ietf.org |CC: Teco Boot |Onderwerp: Re: [manet] OLSRv2 - RouterID | |Am Thursday 02 April 2009 14:25:24 schrieb Teco Boot: |> Dear OLSRv2 design team, |> |> I have a question on: |> > OLSRv2 does not make any assumption about router addresses, other |> > than that each router is assumed to have at least one unique and |> > routable IP address for each interface that it has which |participates |> > in the MANET. |> |> Why is this? It excludes usage of link local addresses. I do not see = a |hard |> reason not using LLs, as long as they are unique in the MANET Routing |> Domain. And LLs are not routable. |> |> More important: IPv6 LL addresses are mandatory for IPv6 router |interfaces |> (RFC4861). |> |> Currently, LLs that are not MANET-wide unique may not be used by NHDP |/ |> |> OLSRv2. Why isn't there a router identifier? OLSRv1 had this: |> > main address |> > The main address of a node, which will be used in OLSR control |> > traffic as the "originator address" of all messages emitted by |> > this node. It is the address of one of the OLSR interfaces of |> > the node. |> |> This is removed in OLSRv2. Now it is harder to recognize routers |because |> there is no single router identifier anymore. Interfaces may go up = and |down |> or temporally addresses may be used, and as a result the identity |changes |> over time. |I have to agree to this (and was in the process writing a similar = mail). | |It's not necessary for OLSR to use interface IPs in TCs and Hellos, a |single |"Originator IP" for the router instance would be enough to calculate = the |route. This is exactly what I propose !! |> A scenario that introduces problems: |> Assume a router with multiple layer-2 Ethernet to 802.11 bridges |attached, |> using VLANs. IPv6 is used, with "default" EUI-64 addressing. |> The MAC address of a VLAN logical interfaces is the same for all on |the |> same physical interface, and thus the EUI-64 interface-IDs are the |same. |> Uniqueness on each link is OK, assume the MAC address for the = physical |> interface is globally unique. |> |> Currently, NHDP does not send the msg-orig-addr but instead sends = sets |with |> **all** addresses, for itself and for all neighbors. Moreover, |addresses |> may be identifiers **or** locators. Locators change when an MANET |Router |> moves within the topology (result of definition of locator, as used = in |IRTF |> RRG). |> |> For SPF calculation, only identifiers for the nodes and their links |are |> needed. A straightforward approach would be unique router identifiers |> within the routing domain and unique interface identifiers within the |scope |> of each router. For the latter, ifIndex could be used and single = octet |> provides namespace for 256 interfaces using continuous numbering. One |may |> think of extended numbering. A link is identified by a 4-tuple of |RouterID |> and a interface identifier, for itself and the neighbor. I don't = think |the |> interface identifiers are needed in the NHDP and OLSRv2 messages. |> |> I think the problems can be circumvented by using the following |information |> bases, for NHDP and OLSRv2: |> (to be verified) |> |> Local Information Base |> Local Interface Set |> ifIndex # added |> I_local_iface_addr # |> I_manet |> Removed Interface Address Set |> ifIndex # added |> IR_local_iface_addr |> IR_time |> Originator Set # not required if orig_addr is stable |> O_orig_addr |> O_time |> Local Attached Network Set |> AL_net_addr |> AL_dist |> |> Interface Information Bases |> Link Set |> ifIndex # added |> L_orig_addr # |> L_ifIndex # needed ?? |> L_HEARD_time |> L_SYM_time |> L_quality |> L_pending |> L_lost |> L_time |> 2-Hop Set |> ifIndex # added |> N2_orig_addr # |> L_ifIndex # needed ?? |> N2_2H_orig_addr |> N2_time |> |> Neighbor Information Base |> Neighbor Set |> N_orig_addr # |> N_symmetric |> N_willingness |> N_mpr |> N_mpr_selector |> Lost Neighbor Set |> NL_orig_addr # |> NL_time |> |> Topology Information Base |> Advertised Neighbor Set |> A_orig_addr # |> Advertising Remote Router Set |> AR_orig_addr # |> AR_seq_number |> AR_time |> Topology Set |> T_dest_orig_addr # |> T_orig_addr |> T_seq_number |> T_time |> Attached Network Set |> AN_net_addr |> AN_orig_addr |> AN_dist |> AN_seq_number |> AN_time |> Routing Set |> R_dest_addr |> R_next_iface_addr |> R_dist |> R_local_ifIndex # |> |> Processing and Forwarding Information Base |> Received Set |> RX_type |> RX_orig_addr |> RX_seq_number |> RX_time |> Processed Set |> P_type |> P_orig_addr |> P_seq_number |> P_time |> Forwarded Set |> F_type |> F_orig_addr |> F_seq_number |> F_time |> Relay Set |> RY_neighbor_orig_addr # |> | |I don't think using an interface index would be a good idea, because |it's OS |dependent how this ids are handled (and what happens when an interface |is |down).=20 ifIndex is a SNMP / MIP id, and I think management MIBsis required for a = std track protocol. In short, ifIndex is as stable as possible. |We used a similar idea in the OLSR.org implementation and |had/have |lot's of trouble when interfaces are down for a moment (because you |cannot |convert the interface index into the interface data during this time !) ifIndex should not dependent of addresses. It is simply a number. |I think it would be easier if each NHDP link has stored a "next hop" IP |in |addition to the originator IP of the other side of the link. This way |the |local node can forward packages to the interface IP of the other side |without |advertising this IPs at all. The "next hop" would be the IP header address. |The topology database does not need to know about the interfaces = between |distant nodes at all, only that there is a connection between the = nodes. |This |way we could reduce the amount of change OLSRv2 and NHDP need. Yes, this is my proposal. Teco. |> As a result, the NHDP hello messages must contain msg-orig-addr (may |be |> suppressed if IP header source address is msg-orig-addr). This may be |a |> small increase of the size of the packets. But other messages would = be |> largely reduced in size, as not ALL addresses are advertized anymore. |Each |> router identifier (orig-addr) represents all addresses of all |interfaces of |> the router. |> |> Also unidirectional links become available for routing, as long as |there is |> a pair of unidirectional links (in opposite directions). This is |desirable |> qualitative properties #7 of MANET routing protocols (RFC2501). |Using unidirectional links is not a good idea in my oppinion, = especially |on |wireless links. Some layer 2 technologies (like 802.11) cannot send |unicast |traffic on unidirectional links. | |My proposal would be to allow NHDP and OLSRv2 to send an unique router- |id (ip |address) instead of interface IPs. The only difficulty in this approach |is |that a node receiving a NHDP package would have to discover the |interface IP |of the originator of this package. This could be done either done by |using |information from lower protocol layers (IP source address of the |incoming |broadcast) or the interface IP would have to be included into the NHDP |package. | |Henning Rogge | |************************************************* |Diplom Informatiker Henning Rogge |Forschungsgesellschaft f=FCr |Angewandte Naturwissenschaften e. V. (FGAN) |Neuenahrer Str. 20, 53343 Wachtberg, Germany |Tel.: 0049 (0)228 9435-961 |Fax: 0049 (0)228 9435-685 |E-Mail: rogge@fgan.de |Web: www.fgan.de |************************************************ |Sitz der Gesellschaft: Bonn |Registergericht: Amtsgericht Bonn VR 2530 |Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. = Dr.-Ing. |Joachim Ender (Stellv.) From teco@inf-net.nl Thu Apr 2 06:19: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 0E33A3A6885 for ; Thu, 2 Apr 2009 06:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.504, 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 WdVvDbm-f2Qm for ; Thu, 2 Apr 2009 06:19: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 737A13A6919 for ; Thu, 2 Apr 2009 06:19:05 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Thu, 2 Apr 2009 15:20:06 +0200 From: "Teco Boot" To: "'Stan Ratliff \(sratliff\)'" References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <7FB7EE0A621BA44B8B69E5F0A09DC76407ED9012@xmb-rtp-208.amer.cisco.com> In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76407ED9012@xmb-rtp-208.amer.cisco.com> Date: Thu, 2 Apr 2009 15:20:09 +0200 Message-ID: <00d701c9b395$bf56b700$3e042500$@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: Acmzjhiu+S5GKrDTRq+BhF9qRRbt7QAA6VhgAAC1nSA= Content-Language: nl X-OriginalArrivalTime: 02 Apr 2009 13:20:06.0561 (UTC) FILETIME=[BD626110:01C9B395] Cc: 'manet' Subject: Re: [manet] OLSRv2 - RouterID 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, 02 Apr 2009 13:19:08 -0000 Inline. |-----Oorspronkelijk bericht----- |Van: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] |Verzonden: donderdag 2 april 2009 14:54 |Aan: Teco Boot; manet |Onderwerp: RE: [manet] OLSRv2 - RouterID | |Teco, | |One question inline. | |> -----Original Message----- |> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] |> On Behalf Of Teco Boot |> Sent: Thursday, April 02, 2009 8:25 AM |> To: 'manet' |> Subject: [manet] OLSRv2 - RouterID |> |> Dear OLSRv2 design team, |> |> I have a question on: |> |> > OLSRv2 does not make any assumption about router addresses, |> other than |> > that each router is assumed to have at least one unique and |> routable |> > IP address for each interface that it has which participates in the |> > MANET. |> |> Why is this? It excludes usage of link local addresses. I do |> not see a hard reason not using LLs, as long as they are |> unique in the MANET Routing Domain. And LLs are not routable. |> |> More important: IPv6 LL addresses are mandatory for IPv6 |> router interfaces (RFC4861). |> |> Currently, LLs that are not MANET-wide unique may not be used |> by NHDP / OLSRv2. Why isn't there a router identifier? OLSRv1 |> had this: |> |> > main address |> > The main address of a node, which will be used in OLSR control |> > traffic as the "originator address" of all messages emitted by |> > this node. It is the address of one of the OLSR interfaces of |> > the node. |> |> This is removed in OLSRv2. Now it is harder to recognize |> routers because there is no single router identifier anymore. |> Interfaces may go up and down or temporally addresses may be |> used, and as a result the identity changes over time. |> |> A scenario that introduces problems: |> Assume a router with multiple layer-2 Ethernet to 802.11 |> bridges attached, using VLANs. IPv6 is used, with "default" |> EUI-64 addressing. |> The MAC address of a VLAN logical interfaces is the same for |> all on the same physical interface, and thus the EUI-64 |> interface-IDs are the same. |> Uniqueness on each link is OK, assume the MAC address for the |> physical interface is globally unique. |> |> Currently, NHDP does not send the msg-orig-addr but instead |> sends sets with |> **all** addresses, for itself and for all neighbors. |> Moreover, addresses may be identifiers **or** locators. |> Locators change when an MANET Router moves within the |> topology (result of definition of locator, as used in IRTF RRG). |> |> For SPF calculation, only identifiers for the nodes and their |> links are needed. A straightforward approach would be unique |> router identifiers within the routing domain and unique |> interface identifiers within the scope of each router. For |> the latter, ifIndex could be used and single octet provides |> namespace for 256 interfaces using continuous numbering. One |> may think of extended numbering. A link is identified by a |> 4-tuple of RouterID and a interface identifier, for itself |> and the neighbor. I don't think the interface identifiers are |> needed in the NHDP and OLSRv2 messages. |> | |Forgive me if this is a silly question, but how would you use a 4-tuple |on a multi-access link like an Ethernet? replicate the local information |for each OLSR neighbor? No, what I mean by link is the relation (edge) between 2 nodes (vertices). Maybe only the 2 node IDs would be enough to identify the link. This is what we need for hop count SPF calculations. Maybe we need interface IDs for distinguish parallel links. Or we could advertize just the best link. Info in hello: set of neighbors. Info in information bases, all information that is available and needed for processing. Teco. |Regards, |Stan | | |> I think the problems can be circumvented by using the |> following information bases, for NHDP and OLSRv2: |> (to be verified) |> |> Local Information Base |> Local Interface Set |> ifIndex # added |> I_local_iface_addr # |> I_manet |> Removed Interface Address Set |> ifIndex # added |> IR_local_iface_addr |> IR_time |> Originator Set # not required if orig_addr is stable |> O_orig_addr |> O_time |> Local Attached Network Set |> AL_net_addr |> AL_dist |> |> Interface Information Bases |> Link Set |> ifIndex # added |> L_orig_addr # |> L_ifIndex # needed ?? |> L_HEARD_time |> L_SYM_time |> L_quality |> L_pending |> L_lost |> L_time |> 2-Hop Set |> ifIndex # added |> N2_orig_addr # |> L_ifIndex # needed ?? |> N2_2H_orig_addr |> N2_time |> |> Neighbor Information Base |> Neighbor Set |> N_orig_addr # |> N_symmetric |> N_willingness |> N_mpr |> N_mpr_selector |> Lost Neighbor Set |> NL_orig_addr # |> NL_time |> |> Topology Information Base |> Advertised Neighbor Set |> A_orig_addr # |> Advertising Remote Router Set |> AR_orig_addr # |> AR_seq_number |> AR_time |> Topology Set |> T_dest_orig_addr # |> T_orig_addr |> T_seq_number |> T_time |> Attached Network Set |> AN_net_addr |> AN_orig_addr |> AN_dist |> AN_seq_number |> AN_time |> Routing Set |> R_dest_addr |> R_next_iface_addr |> R_dist |> R_local_ifIndex # |> |> Processing and Forwarding Information Base |> Received Set |> RX_type |> RX_orig_addr |> RX_seq_number |> RX_time |> Processed Set |> P_type |> P_orig_addr |> P_seq_number |> P_time |> Forwarded Set |> F_type |> F_orig_addr |> F_seq_number |> F_time |> Relay Set |> RY_neighbor_orig_addr # |> |> |> As a result, the NHDP hello messages must contain |> msg-orig-addr (may be suppressed if IP header source address |> is msg-orig-addr). This may be a small increase of the size |> of the packets. But other messages would be largely reduced |> in size, as not ALL addresses are advertized anymore. Each |> router identifier (orig-addr) represents all addresses of all |> interfaces of the router. |> |> Also unidirectional links become available for routing, as |> long as there is a pair of unidirectional links (in opposite |> directions). This is desirable qualitative properties #7 of |> MANET routing protocols (RFC2501). |> |> I discussed this with Thomas Clausen in SF last week. His |> first response was that I was somewhat late with this |> enhancement. I have to agree. But I think it is worth to |> consider. Better late than never. |> |> |> Teco. |> |> _______________________________________________ |> manet mailing list |> manet@ietf.org |> https://www.ietf.org/mailman/listinfo/manet |> From jdean@itd.nrl.navy.mil Thu Apr 2 07:03:17 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 3316028C12D for ; Thu, 2 Apr 2009 07:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 4NpsUq8JKvxC for ; Thu, 2 Apr 2009 07:03:16 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 399203A6947 for ; Thu, 2 Apr 2009 07:03:15 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id n32E3ZqF021348; Thu, 2 Apr 2009 10:03:40 -0400 Received: (from bebe [132.250.93.61]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009040210033916216 ; Thu, 02 Apr 2009 10:03:39 -0400 From: "Justin Dean" To: "'Dearlove, Christopher \(UK\)'" , "'Henning Rogge'" , References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> In-Reply-To: Date: Thu, 2 Apr 2009 10:03:32 -0400 Message-ID: <013601c9b39b$ce638060$6b2a8120$@nrl.navy.mil> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmzkNCOzdYrrp+NQ8CFAkxSkzD+JAAAD/+gAAIIT1A= Content-Language: en-us Subject: Re: [manet] OLSRv2 - RouterID 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, 02 Apr 2009 14:03:17 -0000 I would like to jump in here as this is an issue we had lots of debate about quite a while ago and some rational for why the current NHDP specification does not use a routerID type of framework may appropriate at this time before we get to far along in this discussion. OLSRv1 had this idea but NHDP/OLSRv2 does not and this choice was not arbitrary but stems from two main issues. Multiple interfaces and multiple mode operation. The current specification does not generate MID messages from all nodes which have multiple interfaces. This is not insignificant in terms of overhead because ALL nodes which have more than one interface had to generate and flood these message throughout the network. NHDP HELLO messages do contain more address information than previous OLSR HELLO messages but again this is mitigated in terms of overhead by getting rid of MID messages. Furthermore there were and still are issues when using an router ID based approach specifically when the ID address is no longer in use and when differing interfaces are operating in differing modes (ie not all are participating in OLSRv2). Having NHDP HELLOs and OLSRv2 TCs advertize all one hop addresses removes both of these problematic issues. Any address can be removed without issue or countermeasures. Furthermore interface addresses can be tagged with TLVs to show specific MANET operation behaviors and capabilities of those specific interfaces, which may be disjoint sets of behaviors across all interfaces. This is important if NHDP is to support differing protocols at the same time without breaking. I am against changing the functioning of NHDP in such a fundamental way given the above arguments. I am however for some rational in the document explaining this design choice, which I agree is not the intuitive choice (see OLSRv1) and the benefits may not be readily apparent. Justin -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Dearlove, Christopher (UK) Sent: Thursday, April 02, 2009 8:59 AM To: Henning Rogge; manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID > It's not necessary for OLSR to use interface IPs in TCs and Hellos, a single > "Originator IP" for the router instance would be enough to calculate the > route. I'm afraid that is not true. In HELLOs at least you need interface addresses in order for per interface MPR selection to work correctly. And the current design of TC messages is part of how we abolished MID messages from OLSR - and that's a major win in efficiency because MID message forced all multiple addressed nodes to transmit them, while TC messages are only required by MPRs. In addition coordintion between differently timed MID and TC messages is not at all nice, while the current processing is simpler in this regard. I believe these suggestions are failing to appreciate these details. And the serious revision that would be required is exactly what is not what we need at this time. Looking back over drafts, this has been stable in this form since 2006. ******************************************************************** 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 Roshan.Thomas@cobham.com Thu Apr 2 05:49: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 188833A6885 for ; Thu, 2 Apr 2009 05:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 xWB-LUmdaZlx for ; Thu, 2 Apr 2009 05:49:34 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 141E53A684B for ; Thu, 2 Apr 2009 05:49:33 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n32CoYhI022873 for ; Thu, 2 Apr 2009 07:50:34 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n32CoYuH029752 for ; Thu, 2 Apr 2009 07:50:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B391.9CAE87E0" Date: Thu, 2 Apr 2009 08:50:33 -0400 Message-ID: <5ABE30CE099A524CBF95C715D37BCACC025F8E15@nemo.columbia.ads.sparta.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OLSR Specs and Hysteresis Thread-Index: AcmzkXfVzJwCgRtRRV6Iuf6q9Bd1MgAAAW+w From: "Thomas, Roshan" To: X-Mailman-Approved-At: Thu, 02 Apr 2009 08:55:05 -0700 Subject: [manet] OLSR Specs and Hysteresis 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, 02 Apr 2009 12:53:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B391.9CAE87E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I am a DARPA researcher currently studying wormhole attacks on the OLSR protocol.=20 =20 Couple of questions: =20 1. Is there any document that describes in a more intuitive way the hysteresis logic in OLSR, in particular the relationship of the various flags and parameters to VTIME, HTIME and emission intervals? Any document/presentation that expands on the OLSR specification will be helpful. Also any papers that describe experimental work in trying to tune these parameters and measure impact on performance and packet loss will be helpful. =20 2. Also, is the 2003 draft the latest specification for OLSR? =20 Sincerely, =20 Dr. Roshan Thomas =20 =20 Roshan Thomas, Ph.D Senior Principal Scientist SPARTA, Inc. 5875 Trinity Parkway, Suite 300 Centreville, VA 20120 =20 email: roshan.thomas@sparta.com =20 Voice:703-988-8654 Fax :703-988-8599 =20 ------_=_NextPart_001_01C9B391.9CAE87E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I am a DARPA researcher currently studying wormhole = attacks on the OLSR protocol.

 

Couple of questions:

 

1. Is there any document that describes in a more = intuitive way the hysteresis logic in OLSR, in particular the relationship of the = various flags and parameters to VTIME, HTIME and emission intervals? Any document/presentation that expands on the OLSR specification will be = helpful. Also any papers that describe experimental work in trying to tune these parameters and measure impact on performance and packet loss will be = helpful.

 

2. Also, is the 2003 draft the latest specification = for OLSR?

 

Sincerely,

 

Dr. Roshan Thomas

 

 

Roshan Thomas, Ph.D

Senior Principal = Scientist

SPARTA, Inc.

5875 = Trinity Parkway, Suite = 300

Centreville, VA 20120

 

email: roshan.thomas@sparta.com

Voice:703-988-8654

Fax   = :703-988-8599

 

------_=_NextPart_001_01C9B391.9CAE87E0-- From hrogge@googlemail.com Thu Apr 2 09:09:13 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 398903A6895 for ; Thu, 2 Apr 2009 09:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8wXMLNOAhTj for ; Thu, 2 Apr 2009 09:09:12 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id B9C633A681D for ; Thu, 2 Apr 2009 09:09:11 -0700 (PDT) Received: by ewy9 with SMTP id 9so615879ewy.37 for ; Thu, 02 Apr 2009 09:10:12 -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=QYPb4f9aW1qEtbU3d9VIPSSB7bgC/kDIykePLVHrPJ0=; b=fxdJtET0NNO8D8cGXdXvTYg/S3rgO6WNqYs7LFAtSX5c9ZAjgQ8GY5IU1pV2HvU2f/ wzD7xgEBOd80ixplv36IruzcUYwvQkIc2rL/H7CbgBHrI+2B66mihOVHNCueQkgMEsG1 R4nsYg2OqUIrTRC3sg8AKOQdIyVjjy/9QMcFs= 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=HMHg1fzpKQcSMLfcRgBCNv/1LdhJPbrcdDbxkeKEHZJoxLPvktmjG+hc/ny5sQ6rJ/ KGDsKBRThwbUIA94xHKxwEk+N04H/tizjk7vRqyRkvK5gQK8z0SRJaabBpdb/ZB8/vh5 CMk58HcG4EaYubVnkWwh1M1dcdrLvcLIFfNYE= Received: by 10.216.7.209 with SMTP id 59mr79765wep.213.1238688612379; Thu, 02 Apr 2009 09:10:12 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 23sm1634477eya.16.2009.04.02.09.10.11 (version=SSLv3 cipher=RC4-MD5); Thu, 02 Apr 2009 09:10:11 -0700 (PDT) From: Henning Rogge To: manet@ietf.org Date: Thu, 2 Apr 2009 18:10:04 +0200 User-Agent: KMail/1.11.1 (Linux/2.6.29-gentoo; KDE/4.2.1; x86_64; ; ) References: <5ABE30CE099A524CBF95C715D37BCACC025F8E15@nemo.columbia.ads.sparta.com> In-Reply-To: <5ABE30CE099A524CBF95C715D37BCACC025F8E15@nemo.columbia.ads.sparta.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1691515.hFbsklj07P"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904021810.10688.hrogge@googlemail.com> Cc: "Thomas, Roshan" Subject: Re: [manet] OLSR Specs and Hysteresis 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, 02 Apr 2009 16:10:51 -0000 --nextPart1691515.hFbsklj07P Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Donnerstag 02 April 2009 14:50:33 Thomas, Roshan wrote: > I am a DARPA researcher currently studying wormhole attacks on the OLSR > protocol. Internal wormholes (wormholes done by two stations of the network) ? > Couple of questions: > > 1. Is there any document that describes in a more intuitive way the > hysteresis logic in OLSR, Hysteresis in OLSR is an exponential aging of the binary loss/receivement o= f=20 hello messages plus a two-step treshold to convert it back into a binary va= lue=20 (value goes higher than HYST_TRESHOLD_HIGH and output goes to "false", valu= e=20 goes below HYST_TRESHOLD_LOG and output goes to "true"). This way the "active/lost" switching of OLSR links become a little bit more= =20 smooth. > in particular the relationship of the various > flags and parameters to VTIME, HTIME and emission intervals? Any > document/presentation that expands on the OLSR specification will be > helpful. Also any papers that describe experimental work in trying to > tune these parameters and measure impact on performance and packet loss > will be helpful. I think the HYST_SCALING factor must be in a good relation to=20 HELLO_VALIDITY_TIME/HELLO_INTERVAL. Within the interval the link can timeou= t,=20 so you want allow the output of the exponential aging to "move" by a high=20 enough value. With the suggested HYST_SCALING value of 0.5 the result of the exp. aging=20 moves very quickly and does not have a long "memory", but I think this is a= =20 good suggestion for the combination 2sec./6sec. for Hello timing. > 2. Also, is the 2003 draft the latest specification for OLSR? You mean the RFC from 2003 ? http://tools.ietf.org/html/rfc3626 Henning Rogge --nextPart1691515.hFbsklj07P Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAknU42IACgkQcenvcwAcHWfAOQCgih2MmcCNHd1xVO9mSJin6EGl KHAAnj+BxtxTdWJ8iK6Y6L0M5VYMkSHq =Y+5L -----END PGP SIGNATURE----- --nextPart1691515.hFbsklj07P-- From teco@inf-net.nl Thu Apr 2 10:22:32 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 936383A67D2 for ; Thu, 2 Apr 2009 10:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=0.493, 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 AgpuqaihR0m0 for ; Thu, 2 Apr 2009 10:22:31 -0700 (PDT) Received: from CPSMTPM-EML108.kpnxchange.com (Cpsmtpm-eml108.kpnxchange.com [195.121.3.12]) by core3.amsl.com (Postfix) with ESMTP id 05F883A6B28 for ; Thu, 2 Apr 2009 10:22:30 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML108.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Thu, 2 Apr 2009 19:23:28 +0200 From: "Teco Boot" To: "'Justin Dean'" , "'Dearlove, Christopher \(UK\)'" , "'Henning Rogge'" References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> <013601c9b39b$ce638060$6b2a8120$@nrl.navy.mil> In-Reply-To: <013601c9b39b$ce638060$6b2a8120$@nrl.navy.mil> Date: Thu, 2 Apr 2009 19:23:31 +0200 Message-ID: <00fc01c9b3b7$bea548e0$3befdaa0$@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: AcmzkNCOzdYrrp+NQ8CFAkxSkzD+JAAAD/+gAAIIT1AAAmNpsA== Content-Language: nl X-OriginalArrivalTime: 02 Apr 2009 17:23:28.0320 (UTC) FILETIME=[BCB5FC00:01C9B3B7] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 02 Apr 2009 17:22:32 -0000 All, thanks for the quick responses. It seems I missed the historical debate on this. I was not involved in MANET until ~ 3.5 years ago, and up to recently I was not that interested in OLSR, mainly because lack of link metrics. Sorry for this. Objection #1: MID ================= Getting rid of OLSRv1 MID makes sense. No need for justify that. But I am with Henning that introducing a RouterID does not re-introduce the MID. There is a need for a flag that defines RouterID is routable or not. A requirement is that RouterID is stable. Simple to implement, config option or highest configured unicast IP address. Other variants exists, all are fine as long as the ID is unique in the MANET routing domain. Objection #2: NHDP used by OLSRv2 and other protocols ===================================================== I agree that flooding more identifiers (could be "changing" locators!!) provides more functionality. But here we could use the more general multiple topology approach (DYMO has already this capability with DID). I guess we need hello capability TLV anyway. This would be stored in the Interface Information Base Link Set. Guest protocols using NHDP shall only use the link to a neighbor if the required capability for that protocol is found. Flooding bulk of addresses doesn't help here. What am I missing? Further enhancements as result of RouterID ========================================== I think we need the RouterID for anycast support. If addresses are used as RouterIDs, anycast addresses generate shortcuts in the graph, with black holes as result (to be verified). This is unacceptable for me. I have some thought on further reduction of TC overhead. 1) A msg-orig-addr prefix length may be included (own TLV or piggy back somewhere ?). If included, the prefix msg-orig-addr/prefix-length is handled as Attached Network Set. 2) All interface addresses within an advertized Attached Network Set (as summary) should be suppressed in TC messages. 3) When TC msg-orig-addr is missing, the IP header source address is used as msg-orig-addr (a MAY) used in first hop msg flooding. Message forwarding routine shall include the msg-orig-addr. On 1: I highly prefer a single "TC header TLV" with mandatory TLVs. Using one octet Type for each one octet Value looks not very efficient to me. May apply to other message types also. Side remark on TC messages ========================== I think it is hard to find out what addresses are actually sent by TC. I **think** the Advertised Neighbor Set is sent, but I cannot find this in Section 8.2. Maybe the name is altered from Advertised Address Set some day and the text is not updated consistently (I hope so:-). Teco. |-----Oorspronkelijk bericht----- |Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens |Justin Dean |Verzonden: donderdag 2 april 2009 16:04 |Aan: 'Dearlove, Christopher (UK)'; 'Henning Rogge'; manet@ietf.org |Onderwerp: Re: [manet] OLSRv2 - RouterID | |I would like to jump in here as this is an issue we had lots of debate |about |quite a while ago and some rational for why the current NHDP |specification |does not use a routerID type of framework may appropriate at this time |before we get to far along in this discussion. OLSRv1 had this idea but |NHDP/OLSRv2 does not and this choice was not arbitrary but stems from |two |main issues. Multiple interfaces and multiple mode operation. The |current |specification does not generate MID messages from all nodes which have |multiple interfaces. This is not insignificant in terms of overhead |because |ALL nodes which have more than one interface had to generate and flood |these |message throughout the network. NHDP HELLO messages do contain more |address |information than previous OLSR HELLO messages but again this is |mitigated in |terms of overhead by getting rid of MID messages. Furthermore there |were |and still are issues when using an router ID based approach specifically |when the ID address is no longer in use and when differing interfaces |are |operating in differing modes (ie not all are participating in OLSRv2). |Having NHDP HELLOs and OLSRv2 TCs advertize all one hop addresses |removes |both of these problematic issues. Any address can be removed without |issue |or countermeasures. Furthermore interface addresses can be tagged with |TLVs |to show specific MANET operation behaviors and capabilities of those |specific interfaces, which may be disjoint sets of behaviors across all |interfaces. This is important if NHDP is to support differing protocols |at |the same time without breaking. | |I am against changing the functioning of NHDP in such a fundamental way |given the above arguments. I am however for some rational in the |document |explaining this design choice, which I agree is not the intuitive choice |(see OLSRv1) and the benefits may not be readily apparent. | |Justin | |-----Original Message----- |From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf |Of |Dearlove, Christopher (UK) |Sent: Thursday, April 02, 2009 8:59 AM |To: Henning Rogge; manet@ietf.org |Subject: Re: [manet] OLSRv2 - RouterID | | |> It's not necessary for OLSR to use interface IPs in TCs and Hellos, a |single |> "Originator IP" for the router instance would be enough to calculate |the |> route. | |I'm afraid that is not true. In HELLOs at least you need interface |addresses |in order for per interface MPR selection to work correctly. And the |current |design of TC messages is part of how we abolished MID messages from OLSR |- and that's a major win in efficiency because MID message forced all |multiple |addressed nodes to transmit them, while TC messages are only required by |MPRs. |In addition coordintion between differently timed MID and TC messages is |not |at all nice, while the current processing is simpler in this regard. | |I believe these suggestions are failing to appreciate these details. And |the |serious revision that would be required is exactly what is not what we |need |at this time. Looking back over drafts, this has been stable in this |form since |2006. | | |******************************************************************** |This email and any attachments are confidential to the intended |recipient and may also be privileged. If you are not the intended |recipient please delete it from your system and notify the sender. |You should not copy it or use it for any purpose nor disclose or |distribute its contents to any other person. |******************************************************************** | |_______________________________________________ |manet mailing list |manet@ietf.org |https://www.ietf.org/mailman/listinfo/manet | | |_______________________________________________ |manet mailing list |manet@ietf.org |https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Thu Apr 2 23:16:13 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 AA36528C12E for ; Thu, 2 Apr 2009 23:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.482, 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 u4NhAWVKMPP4 for ; Thu, 2 Apr 2009 23:16:12 -0700 (PDT) Received: from CPSMTPM-EML106.kpnxchange.com (Cpsmtpm-eml106.kpnxchange.com [195.121.3.10]) by core3.amsl.com (Postfix) with ESMTP id B4C423A6845 for ; Thu, 2 Apr 2009 23:16:10 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML106.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 3 Apr 2009 08:17:11 +0200 From: "Teco Boot" To: "'manet'" References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> In-Reply-To: <00c701c9b38e$18e7eb70$4ab7c250$@nl> Date: Fri, 3 Apr 2009 08:17:11 +0200 Message-ID: <00fe01c9b423$d30f9a80$792ecf80$@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: Acmzjhiu+S5GKrDTRq+BhF9qRRbt7QAlHvtQ Content-Language: nl X-OriginalArrivalTime: 03 Apr 2009 06:17:11.0182 (UTC) FILETIME=[D2E492E0:01C9B423] Subject: Re: [manet] OLSRv2 - RouterID 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, 03 Apr 2009 06:16:13 -0000 Hi, Comment on my own mail, after more thinking. |As a result, the NHDP hello messages must contain msg-orig-addr (may be |suppressed if IP header source address is msg-orig-addr). This may be a |small increase of the size of the packets. But other messages would be |largely reduced in size, as not ALL addresses are advertized anymore. |Each |router identifier (orig-addr) represents all addresses of all interfaces |of |the router. | |Also unidirectional links become available for routing, as long as there |is |a pair of unidirectional links (in opposite directions). This is |desirable |qualitative properties #7 of MANET routing protocols (RFC2501). This #7 property requires interface identifiers. Could be non-routable "RouterID_local" identifiers like ifIndex. If this is the only (or most important) benefit, I think it doesn't outweigh the complexity / overhead. Not at all. Teco. From chris.dearlove@baesystems.com Fri Apr 3 01:31: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 F11313A6C20 for ; Fri, 3 Apr 2009 01:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.632 X-Spam-Level: X-Spam-Status: No, score=-6.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, 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 lsRZLwcwYeqN for ; Fri, 3 Apr 2009 01:31:35 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id CF5813A698B for ; Fri, 3 Apr 2009 01:31:34 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n338WYda004836 for ; Fri, 3 Apr 2009 09:32:34 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n338WYlh003112 for ; Fri, 3 Apr 2009 09:32:34 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 03 Apr 2009 09:32:34 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Apr 2009 09:32:34 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 3 Apr 2009 09:32:33 +0100 Message-ID: In-Reply-To: <200904021510.58935.rogge@fgan.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: AcmzlIC+onk0R3AEQEKpDJFihjxXAgABeYlA References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> <200904021510.58935.rogge@fgan.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" X-OriginalArrivalTime: 03 Apr 2009 08:32:34.0357 (UTC) FILETIME=[BCAEB650:01C9B436] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 03 Apr 2009 08:31:36 -0000 > If each OLSR node does only have one routable IP for "long range" (more than=20 > 2-hop) traffic, MIDs are not necessary. If an OLSRv2 node only has one address, it's already permitted to include it just as an originator address in a TC message. And in a HELLO message if it only has one address you can omit it and use the sending address from IP. These optimisations are already in the draft (and have been for several versions). ******************************************************************** 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 Rogge@fgan.de Fri Apr 3 01:38:34 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 D0B333A6C2B for ; Fri, 3 Apr 2009 01:38:34 -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_DE=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 15CHp38rEPyY for ; Fri, 3 Apr 2009 01:38:33 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 69DE23A68E0 for ; Fri, 3 Apr 2009 01:38:33 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Lpew2-0005Mp-NW; Fri, 03 Apr 2009 10:39:34 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1Lpew2-0007Nb-Ck; Fri, 03 Apr 2009 10:39:34 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 10:39:34 +0200 From: Henning Rogge To: "Dearlove, Christopher (UK)" Date: Fri, 3 Apr 2009 10:39:25 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.26-1-openvz-686; KDE/4.1.4; i686; ; ) References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021510.58935.rogge@fgan.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2945398.C6nSYtzLvp"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904031039.33788.rogge@fgan.de> X-OriginalArrivalTime: 03 Apr 2009 08:39:34.0418 (UTC) FILETIME=[B70EEF20:01C9B437] X-Virus-Scanned: yes (ClamAV 0.94.2/9201/Fri Apr 3 05:37:50 2009) by mailguard.fgan.de X-Scan-Signature: 294a3b624c54297b50152b57e2ef3e7f Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 03 Apr 2009 08:38:34 -0000 --nextPart2945398.C6nSYtzLvp Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Friday 03 April 2009 10:32:33 schrieb Dearlove, Christopher (UK): > > If each OLSR node does only have one routable IP for "long range" > > (more than > > > 2-hop) traffic, MIDs are not necessary. > > If an OLSRv2 node only has one address, it's already permitted > to include it just as an originator address in a TC message. > And in a HELLO message if it only has one address you can omit > it and use the sending address from IP. These optimisations > are already in the draft (and have been for several versions). The trick is to be able to do this even with multiple interfaces. Each node will have one "public" IP and a number of linklocal interface IPs. I will look through the NHDP/OLSRv2 draft in the weekend again, maybe there= is=20 a way to support this without any need of changing the packet format and wi= th=20 only very small changes in the NHDP handling (and of course without MIDs). Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart2945398.C6nSYtzLvp Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEUEABECAAYFAknVyz0ACgkQRIfGfFXsz+CowgCXTl7LcEuyOUZPf8jK+ie6IxI/ vwCeI0GT0Cbh0lddFbModKnZP6YLMWg= =Feh+ -----END PGP SIGNATURE----- --nextPart2945398.C6nSYtzLvp-- From chris.dearlove@baesystems.com Fri Apr 3 01:42:02 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 DE3783A6C2B for ; Fri, 3 Apr 2009 01:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.631 X-Spam-Level: X-Spam-Status: No, score=-6.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, 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 sfpJsWkoJeU1 for ; Fri, 3 Apr 2009 01:42:02 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id C9C103A68A6 for ; Fri, 3 Apr 2009 01:42:01 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n338h28E008603 for ; Fri, 3 Apr 2009 09:43:02 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n338h1mo000502 for ; Fri, 3 Apr 2009 09:43:01 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 03 Apr 2009 09:43:01 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Apr 2009 09:43:00 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 3 Apr 2009 09:42:56 +0100 Message-ID: In-Reply-To: <00c701c9b38e$18e7eb70$4ab7c250$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acmzjhiu+S5GKrDTRq+BhF9qRRbt7QAqS0eQ References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "manet" X-OriginalArrivalTime: 03 Apr 2009 08:43:00.0969 (UTC) FILETIME=[322C1D90:01C9B438] Subject: Re: [manet] OLSRv2 - RouterID 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, 03 Apr 2009 08:42:03 -0000 I was unable to post this until now. > Relay Set =09 > RY_neighbor_orig_addr # This is an example of why this proposal doesn't work. The Relay Set (or its equivalent post-metrics) needs IP addresses, originator addresses/router IDs don't work, and it needs all the IP addresses that a neighbouring router might use when semding (for example) a TC message. This is because whether to forward a TC message is based on its previous router, and that is available only through the sending IP address of the datagram including the TC message - the TC message's originator address is just that, originator address, not updated on each hop. (And before anyone suggests changing that, very bad idea, for a number of reasons, not the least of which is the security model outlined in RFC 5444.) Consequently neighbour information in HELLO messages needs to include interface IP addresses, and you end up with the design we have. Also note that if a node just has the one address, you already have the option to omit it in a HELLO message (use the sending IP address) and include it only as the originator address in a TC message. So that efficiency saving is already there. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From chris.dearlove@baesystems.com Fri Apr 3 02:07: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 A2F1C3A6968 for ; Fri, 3 Apr 2009 02:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.63 X-Spam-Level: X-Spam-Status: No, score=-6.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, 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 mpZjUu3Ls83Z for ; Fri, 3 Apr 2009 02:07:08 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 8FE5F3A6979 for ; Fri, 3 Apr 2009 02:07:08 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n33989Nj018395 for ; Fri, 3 Apr 2009 10:08:09 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n33989Vu024870 for ; Fri, 3 Apr 2009 10:08:09 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 03 Apr 2009 10:08:08 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Apr 2009 10:08:08 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 3 Apr 2009 10:08:08 +0100 Message-ID: In-Reply-To: <200904031039.33788.rogge@fgan.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm0N723UQGWT281TCyBj9MiXytYlQAAjUqA References: <00c701c9b38e$18e7eb70$4ab7c250$@nl><200904021510.58935.rogge@fgan.de> <200904031039.33788.rogge@fgan.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" X-OriginalArrivalTime: 03 Apr 2009 09:08:08.0581 (UTC) FILETIME=[B4C77350:01C9B43B] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 03 Apr 2009 09:07:09 -0000 >> If an OLSRv2 node only has one address, it's already permitted >> to include it just as an originator address in a TC message. >> And in a HELLO message if it only has one address you can omit >> it and use the sending address from IP. These optimisations >> are already in the draft (and have been for several versions). > The trick is to be able to do this even with multiple interfaces. I don't believe that the multiple interface case is the one that needs maximal efficiency, because this is not going to be the simplest, lowest power, devices. Of course I think it still needs efficiency - especially at the number of messages sent level. One saved message saves a lot more than its number of octets - it saves many more octets due to 5444, UDP, IP, MAC, PHY - and not just headers, also multiple access costs. But an odd octet is less critical. That said, as I pointed out in an email I just sent, we need IP addresses so that (for example) TC message forwarding can work, within the "intended usage" framework of RFC 5444 (which although non-normative in 5444, is normative for OLSRv2). And note that the address compression that's in RFC 5444 makes the multiple address overhead lower. For example if you are already using various other addresses in 10.0.0.0/24, the overhead of adding 10.0.0.51/32 (for example) is one octet (not four). ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From chris.dearlove@baesystems.com Fri Apr 3 02:21: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 550513A6CD5 for ; Fri, 3 Apr 2009 02:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.629 X-Spam-Level: X-Spam-Status: No, score=-6.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, 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 F1gTpXeVyzDD for ; Fri, 3 Apr 2009 02:21:35 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id D6FA43A690C for ; Fri, 3 Apr 2009 02:21:34 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n339MYS6023102 for ; Fri, 3 Apr 2009 10:22:34 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n339MYhQ000870 for ; Fri, 3 Apr 2009 10:22:34 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 03 Apr 2009 10:22:34 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Apr 2009 10:22:34 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 3 Apr 2009 10:22:34 +0100 Message-ID: In-Reply-To: <200904021810.10688.hrogge@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSR Specs and Hysteresis Thread-Index: AcmzrcOsNlGehSBgSDOywxVb9dOTjAAipYMg References: <5ABE30CE099A524CBF95C715D37BCACC025F8E15@nemo.columbia.ads.sparta.com> <200904021810.10688.hrogge@googlemail.com> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 03 Apr 2009 09:22:34.0188 (UTC) FILETIME=[B8B898C0:01C9B43D] Cc: "Thomas, Roshan" Subject: Re: [manet] OLSR Specs and Hysteresis 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, 03 Apr 2009 09:21:36 -0000 >> Couple of questions: >> >> 1. Is there any document that describes in a more intuitive way the >> hysteresis logic in OLSR, > Hysteresis in OLSR is an exponential aging of the binary loss/receivement of=20 > hello messages plus a two-step treshold to convert it back into a binary value=20 > (value goes higher than HYST_TRESHOLD_HIGH and output goes to "false", value=20 > goes below HYST_TRESHOLD_LOG and output goes to "true"). It doesn't haver to be exponential aging - the preferred approach is some information directly from the link layer, exponential aging is a fallback for this. In at least one case where a link quality/hysteresis mechanism is a very good idea (802.11 "grey zone" problems) the HELLO message process is not sufficient. Incidentally in OLSRv2 (see below) we are a little more careful with the terminology - there's link quality (based on link layer information, exponential aging, N out of M process, whatever you like) and hysteresis, which is the use of the two thresholds to map that to link lost/not lost. > This way the "active/lost" switching of OLSR links become a little bit more=20 > smooth. As you say. >> in particular the relationship of the various >> flags and parameters to VTIME, HTIME and emission intervals? Any >> document/presentation that expands on the OLSR specification will be >> helpful. Also any papers that describe experimental work in trying to >> tune these parameters and measure impact on performance and packet loss >> will be helpful. > I think the HYST_SCALING factor must be in a good relation to=20 > HELLO_VALIDITY_TIME/HELLO_INTERVAL. Within the interval the link can timeout,=20 > so you want allow the output of the exponential aging to "move" by a high=20 > enough value. HYST_SCALING actually does two jobs that can be separated - an initial link quality and the exponential factor. In OLSRv2 we keep the former, with a new name (INITIAL_QUALITY from memory) but don't specify the latter, as we don't specify the exponential process, only quote it (as "leaky integrator") as an example. > With the suggested HYST_SCALING value of 0.5 the result of the exp. aging=20 > moves very quickly and does not have a long "memory", but I think this is a=20 > good suggestion for the combination 2sec./6sec. for Hello timing. The point here being that after 6 seconds, there is a loss of link anyway, so any exponential decay that doesn't have some effect withing 3 messages lost is pointless. Note that I haven't done extensive work with those parameters, so I have no specific comment on them. >> 2. Also, is the 2003 draft the latest specification for OLSR? > You mean the RFC from 2003 ? > http://tools.ietf.org/html/rfc3626 That is the latest specification off what was called OLSR, but now may be considered as OLSRv1. However for background I would also recommend looking at the literature published by the authors (of which I am not one). But we are currently working on OLSRv2 in this WG. For latest drafts (what was included in RFC 3626, the equivalent is distributed across five documents, three so far published as RFCs, the two key documents however still being Internet Drafts) look for the latest version of draft-ietf-manet-olsrv2 and the documents it references. These documents include some rationale material. If they included all possible rationale material they'd be many times their length. But there is some discussion of link quality therein. Of course it doesn't all translate exactly to OLSRv1 (OLSRv2's INITIAL_PENDING does not appear in OLSRv1 for example) but it may help. ******************************************************************** 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 Rogge@fgan.de Fri Apr 3 02:23:16 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 6797F28C127 for ; Fri, 3 Apr 2009 02:23:16 -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_DE=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 tXeRu0nVted1 for ; Fri, 3 Apr 2009 02:23:15 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 1467E28C13B for ; Fri, 3 Apr 2009 02:23:07 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1LpfdA-0006cN-Cz; Fri, 03 Apr 2009 11:24:08 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1Lpfd9-0007dr-RH; Fri, 03 Apr 2009 11:24:07 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 11:24:07 +0200 From: Henning Rogge To: "Dearlove, Christopher (UK)" Date: Fri, 3 Apr 2009 11:23:53 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.26-1-openvz-686; KDE/4.1.4; i686; ; ) References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904031039.33788.rogge@fgan.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2267630.1T5LibMH11"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904031124.07286.rogge@fgan.de> X-OriginalArrivalTime: 03 Apr 2009 09:24:07.0892 (UTC) FILETIME=[F092B140:01C9B43D] X-Virus-Scanned: yes (ClamAV 0.94.2/9201/Fri Apr 3 05:37:50 2009) by mailguard.fgan.de X-Scan-Signature: 990dd1dead5e5990fbbbdf25ebfcda39 Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 03 Apr 2009 09:23:16 -0000 --nextPart2267630.1T5LibMH11 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Friday 03 April 2009 11:08:08 schrieb Dearlove, Christopher (UK): > I don't believe that the multiple interface case is the one that > needs maximal efficiency, because this is not going to be the > simplest, lowest power, devices. I think multiple interfaces are very important for efficient networks, and= =20 WLAN cards are not very expensive (in terms of money and power). We have go= od=20 experience with multichannel OLSR networks on small devices (a few hundred = mhz=20 cpu) in Freifunk/Funkfeuer networks. > Of course I think it still needs > efficiency - especially at the number of messages sent level. > One saved message saves a lot more than its number of octets > - it saves many more octets due to 5444, UDP, IP, MAC, PHY > - and not just headers, also multiple access costs. But an odd > octet is less critical. Yes. Even requesting media access can be worse than sending a few bytes mor= e. > That said, as I pointed out in an email I just sent, we need IP > addresses so that (for example) TC message forwarding can work, > within the "intended usage" framework of RFC 5444 (which although > non-normative in 5444, is normative for OLSRv2). Can you please explain this point a little bit more ? It seems I miss some= =20 important details. Do we need the interface IPs of the two-hop neighbors fo= r=20 TC forwarding ? I thought we would need =2D all IPs of the local node (we do have this information of course) =2D all interface IPs of the 1-hop neighbors (and routerid if present ?) =2D an identifier for 2-hop neighbors (don't need to be the interface ip li= st) =2D knowledge about which 2-hop neighbor can be reached through each one-hop interface. > And note that the > address compression that's in RFC 5444 makes the multiple address > overhead lower. For example if you are already using various other > addresses in 10.0.0.0/24, the overhead of adding 10.0.0.51/32 (for > example) is one octet (not four). I know (I'm experimenting with automatic address compression), but this=20 doesn't work well for IPv6 linklocal addresses. Each address will be at lea= st=20 an 8 byte overhead (maybe more). Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart2267630.1T5LibMH11 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAknV1akACgkQRIfGfFXsz+AasQCfdeR57n+lMw+5CqtpuKiPjfYQ lbEAn1vze3bmIAsZ5dg8dfO9W7E3IfRg =pNfG -----END PGP SIGNATURE----- --nextPart2267630.1T5LibMH11-- From chris.dearlove@baesystems.com Fri Apr 3 02:37:29 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 ABD953A6D72 for ; Fri, 3 Apr 2009 02:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.628 X-Spam-Level: X-Spam-Status: No, score=-6.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, 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 0FW-2HQiyvCp for ; Fri, 3 Apr 2009 02:37:28 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 46C783A6D55 for ; Fri, 3 Apr 2009 02:37:28 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n339cSU4029074 for ; Fri, 3 Apr 2009 10:38:28 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n339cSFx009976 for ; Fri, 3 Apr 2009 10:38:28 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 03 Apr 2009 10:38:28 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Apr 2009 10:38:28 +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, 3 Apr 2009 10:38:27 +0100 Message-ID: In-Reply-To: <200904031124.07286.rogge@fgan.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm0PfW2VAeuIKzgRvq8S3XKedM8aQAAKETQ References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904031039.33788.rogge@fgan.de> <200904031124.07286.rogge@fgan.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" X-OriginalArrivalTime: 03 Apr 2009 09:38:28.0097 (UTC) FILETIME=[F14B8F10:01C9B43F] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 03 Apr 2009 09:37:29 -0000 We don't need the IP addresses of the two hop neighbours for TC forwarding. But we get the IP addresses of the two hop neighbours mostly for free as they are the same IP addresses included in HELLO messages as are used for one hop neighbours (in order to etablish symmetry). And those are the same IP addresses as nodes themselves must send in order that TC forwarding can work. The "mostly" above is because there are the IP addresses sent as neighbours on other interfaces. But those need to be comparable with the addresses sent on this interface, to manage the cases where there are more than one link between two nodes (and because without forcing a node to send two sets of identifiers - obviously inefficient - that's all we have). The above is a rapidly composed, incomplete summary (I need to get back to other stuff). But note that things really aren't as simple as "let's just change this". The authors have considered, now some time ago, various simplifications, and many just don't work when all the details are considered. Ideally we'd have published an informational draft, or paper, on this and other issues - but time just hasn't permitted (and certainly won't until NHDP is out and OLSRv2 has metrics). --=20 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: Henning Rogge [mailto:rogge@fgan.de]=20 Sent: 03 April 2009 10:24 To: Dearlove, Christopher (UK) Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID Am Friday 03 April 2009 11:08:08 schrieb Dearlove, Christopher (UK): > I don't believe that the multiple interface case is the one that > needs maximal efficiency, because this is not going to be the > simplest, lowest power, devices. I think multiple interfaces are very important for efficient networks, and= =20 WLAN cards are not very expensive (in terms of money and power). We have= good=20 experience with multichannel OLSR networks on small devices (a few hundred= mhz=20 cpu) in Freifunk/Funkfeuer networks. > Of course I think it still needs > efficiency - especially at the number of messages sent level. > One saved message saves a lot more than its number of octets > - it saves many more octets due to 5444, UDP, IP, MAC, PHY > - and not just headers, also multiple access costs. But an odd > octet is less critical. Yes. Even requesting media access can be worse than sending a few bytes= more. > That said, as I pointed out in an email I just sent, we need IP > addresses so that (for example) TC message forwarding can work, > within the "intended usage" framework of RFC 5444 (which although > non-normative in 5444, is normative for OLSRv2). Can you please explain this point a little bit more ? It seems I miss some= =20 important details. Do we need the interface IPs of the two-hop neighbors= for=20 TC forwarding ? I thought we would need - all IPs of the local node (we do have this information of course) - all interface IPs of the 1-hop neighbors (and routerid if present ?) - an identifier for 2-hop neighbors (don't need to be the interface ip= list) - knowledge about which 2-hop neighbor can be reached through each one-hop interface. > And note that the > address compression that's in RFC 5444 makes the multiple address > overhead lower. For example if you are already using various other > addresses in 10.0.0.0/24, the overhead of adding 10.0.0.51/32 (for > example) is one octet (not four). I know (I'm experimenting with automatic address compression), but this=20 doesn't work well for IPv6 linklocal addresses. Each address will be at= least=20 an 8 byte overhead (maybe more). Henning Rogge ************************************************* Diplom Informatiker Henning Rogge Forschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 Fax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) ******************************************************************** 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 Fri Apr 3 03:18: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 011E53A6816 for ; Fri, 3 Apr 2009 03:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.472, 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 w2Nh1gRzGVfi for ; Fri, 3 Apr 2009 03:18:13 -0700 (PDT) Received: from CPSMTPM-EML101.kpnxchange.com (cpsmtpm-eml101.kpnxchange.com [195.121.3.5]) by core3.amsl.com (Postfix) with ESMTP id EE2FC3A68B9 for ; Fri, 3 Apr 2009 03:17:42 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML101.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 3 Apr 2009 12:18:43 +0200 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Henning Rogge'" References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> <200904021510.58935.rogge@fgan.de> In-Reply-To: Date: Fri, 3 Apr 2009 12:18:44 +0200 Message-ID: <010b01c9b445$91d94c10$b58be430$@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: AcmzlIC+onk0R3AEQEKpDJFihjxXAgABeYlAAClIEUA= Content-Language: nl X-OriginalArrivalTime: 03 Apr 2009 10:18:43.0972 (UTC) FILETIME=[9144D440:01C9B445] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 03 Apr 2009 10:18:14 -0000 |Van: |Dearlove, Christopher (UK) |If an OLSRv2 node only has one address, it's already permitted |to include it just as an originator address in a TC message. |And in a HELLO message if it only has one address you can omit |it and use the sending address from IP. These optimisations |are already in the draft (and have been for several versions). Extending this facility looks interesting. What happens if MANET Routers use the same IP address on all its interfaces for NHDP/OLSRv2? o It advertizes only one interface address, to be used as IP_hdr_srce_addr, local_iface_addr, orig_addr, RouterID, etc. Functionality is equivalent with using a loopback interface address added to the MANET interface(s). o This address is used for L2 address resolving (ARP, ND), on all interfaces. o Symmetric link check is per interface (no change). I think this will work, but could require minor text changes in NHDP / OLSRv2. The address may be link-local or unique. A unique address provides multi-hop reachability, which is "practical" for icmp, management, etc. Teco. From chris.dearlove@baesystems.com Fri Apr 3 03:24:17 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 7AB893A6946 for ; Fri, 3 Apr 2009 03:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.626 X-Spam-Level: X-Spam-Status: No, score=-6.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, 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 vCdgrZ5HCnQ3 for ; Fri, 3 Apr 2009 03:24:16 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 36A893A68AD for ; Fri, 3 Apr 2009 03:24:16 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n33APGdd023405 for ; Fri, 3 Apr 2009 11:25:16 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n33APGY7009386 for ; Fri, 3 Apr 2009 11:25:16 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 03 Apr 2009 11:25:16 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Apr 2009 11:25:15 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 3 Apr 2009 11:25:15 +0100 Message-ID: In-Reply-To: <010b01c9b445$91d94c10$b58be430$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: AcmzlIC+onk0R3AEQEKpDJFihjxXAgABeYlAAClIEUAAAY5goA== References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> <200904021510.58935.rogge@fgan.de> <010b01c9b445$91d94c10$b58be430$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Henning Rogge" X-OriginalArrivalTime: 03 Apr 2009 10:25:15.0994 (UTC) FILETIME=[7AEEA3A0:01C9B446] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 03 Apr 2009 10:24:17 -0000 > What happens if MANET Routers use the same IP address on=20 > all its interfaces for NHDP/OLSRv2? Breaks the protocol. > I think this will work It doesn't. Among other issues it is unable to distinguish a symmetric link between interfaces I and J with two non-symmetric links I1 to J1 and J2 to I2, and it fails to allow interface specific MPR selection, which is necessary to avoid a race condition which can otherwise occur. Furthermore once we add metrics, when there are multiple links between two nodes (easy to occur if, for example we equip some nodes with one 802.11 card on channel 1, some with one 802.11 card on channel 5, and some with two 802.11 cards, on each channel) they will have different metrics and we need to distinguish them. ******************************************************************** 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 mbs.rscoe@gmail.com Fri Apr 3 05:15: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 5146528C297 for ; Fri, 3 Apr 2009 05:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] 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 dHnJDOyozAXE for ; Fri, 3 Apr 2009 05:15:18 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id 24A2A3A6B31 for ; Fri, 3 Apr 2009 05:15:18 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id l35so562962waf.5 for ; Fri, 03 Apr 2009 05:16:20 -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=91BPez9imnieR9hcxYz27Q7X8U2BrFaRBKes3B5rFZU=; b=rwe4CETNy/Bj1QFnQCCpX7dxvGQAipLvZTOF8hd4CLTHjUVKmN5m7x5zm7qm3jebXM i9Sz/jCk3DR/Es7b8IMaa3kGd5ne2WCKqLp3nPZVrL3bcpHiKr1vciYoOXqY6FEPmGzn mHNuzykosypi/zqHEN1ZYarB7VPROZEEYQFV8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=mG7Ugt+5TRYzifkQCuS8dmRwUd3v/r/tOsIIlD7DZf30240Vz0Rgn6veJoi7MkwVRR Jy+z1ZQt7kyUuKkEsIwgS6quPTwuhdYuyhrJ8vk6sQSEhKjHx7qlomgkGxuYOCzjTLGO 0PYtGV1kJCPEqaksAgPXp3QRv3lQgnAnsaTm8= MIME-Version: 1.0 Received: by 10.114.26.11 with SMTP id 11mr589677waz.38.1238760980614; Fri, 03 Apr 2009 05:16:20 -0700 (PDT) Date: Fri, 3 Apr 2009 17:46:20 +0530 Message-ID: <1a6317190904030516h165ffaa3he0f4bfef28d6987c@mail.gmail.com> From: Mahendra Salunke To: manet@ietf.org Content-Type: multipart/alternative; boundary=0016364587b4360ef60466a58478 Subject: [manet] Want to develop testbed for MANET? 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, 03 Apr 2009 12:15:19 -0000 --0016364587b4360ef60466a58478 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello all, I want to develop MANET testbed using LAPTOPs and PDAs to test existing and modified protocols in MANET. Can I get guidelines for developing testbed for MANET? I want the details of hardware and software required for it. Thanks in advance. -- Mahendra B. Salunke --0016364587b4360ef60466a58478 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all,
=A0
I want to develop MANET testbed using LAPTOPs and PDAs=A0to test exist= ing and modified protocols in MANET.
=A0
Can I get guidelines for developing testbed for MANET?
=A0
I want the details of hardware and software required for it.

Thanks in advance.
=A0
--=A0
Mahendra B. Salunke

=A0
--0016364587b4360ef60466a58478-- From teco@inf-net.nl Fri Apr 3 06:04: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 159A93A6D15 for ; Fri, 3 Apr 2009 06:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.462, 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 9A-pVRNjPHKs for ; Fri, 3 Apr 2009 06:04:58 -0700 (PDT) Received: from CPSMTPM-EML108.kpnxchange.com (Cpsmtpm-eml108.kpnxchange.com [195.121.3.12]) by core3.amsl.com (Postfix) with ESMTP id C46073A6CC5 for ; Fri, 3 Apr 2009 06:04:57 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML108.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 3 Apr 2009 15:05:58 +0200 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Henning Rogge'" References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> <200904021510.58935.rogge@fgan.de> <010b01c9b445$91d94c10$b58be430$@nl> In-Reply-To: Date: Fri, 3 Apr 2009 15:05:59 +0200 Message-ID: <011a01c9b45c$eed44750$cc7cd5f0$@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: AcmzlIC+onk0R3AEQEKpDJFihjxXAgABeYlAAClIEUAAAY5goAAEd7jA Content-Language: nl X-OriginalArrivalTime: 03 Apr 2009 13:05:58.0786 (UTC) FILETIME=[EE7BEE20:01C9B45C] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 03 Apr 2009 13:04:59 -0000 |Van: Dearlove, Christopher (UK) [mailto:chris.dearlove@baesystems.com] |Aan: Teco Boot; Henning Rogge | |> What happens if MANET Routers use the same IP address on |> all its interfaces for NHDP/OLSRv2? | |Breaks the protocol. | |> I think this will work | |It doesn't. May be it isn't, maybe it is. I said, a minor change in text (or algorithm) could be needed. |Among other issues it is unable to distinguish a symmetric |link between interfaces I and J with two non-symmetric |links I1 to J1 and J2 to I2, Neighbors can perfectly distinguish the links, and can check symmetry. I receives "J via I1" and "J via I2". J receives "I via J1" and "I via J2". Link tables router I: Interface I1: Neighbor J via J, status [heard | symmetric | lost] Interface I2: Neighbor J via J, status [heard | symmetric | lost] Link tables router J: Interface J1: Neighbor I via I, status [heard | symmetric | lost] Interface J2: Neighbor I via I, status [heard | symmetric | lost] |and it fails to allow interface |specific MPR selection, which is necessary to avoid a race |condition which can otherwise occur. I don't understand this. The requirement is that the set of MPRs must provide connectivity to all 2-hop neighbors (Flooding-MPR "coverage criterion") . Questions: o Why MPR selection per interface? o What is the problem? Because there is enough signaling to send selected MPR info via one of the interfaces, and the relay set is maintained per interface? Example, assuming I and J has 2-hop neighbors K respectively L: 2-Hop Set router I: Router K 2-Hop Set router J: Router L Relay Set router I: Interface I1: Neighbor J via J Interface I2: Relay Set router J: Interface J1: Interface J2: Neighbor I via I |Furthermore once we add metrics, when there are multiple |links between two nodes (easy to occur if, for example we |equip some nodes with one 802.11 card on channel 1, some |with one 802.11 card on channel 5, and some with two 802.11 |cards, on each channel) they will have different metrics |and we need to distinguish them. Definitely agreed. First, the sender knows the Tx data rate selected for each neighbor on a link. When this is higher than the minimum (and there is unicast traffic), this is enough for calculating a metric value. And the Rx RSSI level may be used, but this is not recommended, the Rx RSSI captured by the neighbor is to be used. This "remote Rx RSSI" can be transferred to the neighbor with the NHDP hello messages on that link, the metric is for the link on that interface. What is the problem? So far, none yet. Teco. From chris.dearlove@baesystems.com Fri Apr 3 06:15: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 816533A6DD3 for ; Fri, 3 Apr 2009 06:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.625 X-Spam-Level: X-Spam-Status: No, score=-6.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, 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 O3CQRwL5YWEU for ; Fri, 3 Apr 2009 06:15:35 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 669E43A6D12 for ; Fri, 3 Apr 2009 06:15:35 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n33DGZ5r024144 for ; Fri, 3 Apr 2009 14:16:35 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n33DGXde006765 for ; Fri, 3 Apr 2009 14:16:33 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 03 Apr 2009 14:16:33 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Apr 2009 14:16:33 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 3 Apr 2009 14:16:32 +0100 Message-ID: In-Reply-To: <011a01c9b45c$eed44750$cc7cd5f0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: AcmzlIC+onk0R3AEQEKpDJFihjxXAgABeYlAAClIEUAAAY5goAAEd7jAAAFdGbA= References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> <200904021510.58935.rogge@fgan.de><010b01c9b445$91d94c10$b58be430$@nl> <011a01c9b45c$eed44750$cc7cd5f0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Henning Rogge" X-OriginalArrivalTime: 03 Apr 2009 13:16:33.0269 (UTC) FILETIME=[68AA5A50:01C9B45E] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 03 Apr 2009 13:15:36 -0000 |Van: Dearlove, Christopher (UK) [mailto:chris.dearlove@baesystems.com] |Aan: Teco Boot; Henning Rogge | |> What happens if MANET Routers use the same IP address on |> all its interfaces for NHDP/OLSRv2? | |Breaks the protocol. | |> I think this will work | |It doesn't. > May be it isn't, maybe it is. I said, a minor change in text (or algorithm) > could be needed. No such change is going to be minor, and most such changes just don't work (we've investigated many of them). And it is just not appropriate to go down this route at this time, when we have been stable for three years, with a protocol we understand and have running code for, chasing the chimera of maybe we can simplify something that is non-trivial for good reasons. > I don't understand this. The requirement is that the set > of MPRs must provide connectivity to all 2-hop neighbors That's not sufficient. > o Why MPR selection per interface? Read the literature. And yes, that is me not putting in the effort to point out the race condition case and why per interface avoids it and per router doesn't (a subtlety in the MPR flooding proof). Note that with metrics, flooding MPRs will be per interface, routing MPRs don't have to be. The point is, this is a far too late, ill-thought out, proposal. There are many subtle details that went into what we have. ******************************************************************** 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 ssaulojorge@gmail.com Fri Apr 3 06:25: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 CE4CC3A6A58 for ; Fri, 3 Apr 2009 06:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 U-gSe8FfCLNN for ; Fri, 3 Apr 2009 06:25:42 -0700 (PDT) Received: from mail-gx0-f160.google.com (mail-gx0-f160.google.com [209.85.217.160]) by core3.amsl.com (Postfix) with ESMTP id F3BAC3A681F for ; Fri, 3 Apr 2009 06:25:41 -0700 (PDT) Received: by gxk4 with SMTP id 4so2299949gxk.13 for ; Fri, 03 Apr 2009 06:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:received:message-id:subject :from:to:content-type; bh=xL7tL0PCxOqOJZ3+wIOWIqeTQTKBnfCGDwiuEI4+JTA=; b=UXXWDKolD9wF6uz1jN48RM7U6Eh1BcnWVm8nAjOqloqXBL69YvIw5vsGn/PKOJAaYy V3W9gh7JrgeiO09F3KPMWGcG9XZW6xaOUw43QKmkTlWYDlu/4wVw2mQEkoSEN14ZST9t 9OE9HzITe+BR5sOCIIb6l0JrTKpmNqOZ6XBJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=dbeBWx3ZV8sOSLQ/lz5pzOu2IvMsoHaIJjJALm0Do7+HKTqAdn9GrxOsjFxvQnjMex Tr9HgI1l9O6/5qJhxCeDwNlMzhNYpvK7UlNxyQBFro9uZl2zNTX6BQsKkcL6XKrPy64P LdxQzzFF1lKMVaAgQu5nPqrquc4ZrXSkN+jzI= MIME-Version: 1.0 Date: Fri, 3 Apr 2009 09:26:29 -0400 Received: by 10.150.205.20 with SMTP id c20mr2241113ybg.12.1238765204224; Fri, 03 Apr 2009 06:26:44 -0700 (PDT) Message-ID: <3ad5e1a50904030626ua9826f0o5ed418494d433c48@mail.gmail.com> From: Saulo Jorge Queiroz To: manet@ietf.org Content-Type: multipart/alternative; boundary=000e0cd40330f53bc30466a67f66 Subject: [manet] OLSR2 - Routing Set Updates 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, 03 Apr 2009 13:25:42 -0000 --000e0cd40330f53bc30466a67f66 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, I've worked on algorithms for maintaining Routing Set in OLSR. Could anyon= e clarify if a change of the known symmetric links and/or attached networks necessarily changes the routing set? --=20 Saulo Jorge bq - =93Os maus de cora=E7=E3o n=E3o amam nunca; apenas se alegram entre compars= as" -- Caio F=E1bio --000e0cd40330f53bc30466a67f66 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello,

I've worked on algorithms for maintaining Routing Set in = OLSR.=A0 Could anyone clarify if a change of the known symmetric links and/= or attached networks necessarily changes the routing set?


--
Saulo Jorge bq
-
=93Os maus de cora=E7=E3o n=E3o amam nunc= a; apenas se alegram entre comparsas"
-- Caio F=E1bio
--000e0cd40330f53bc30466a67f66-- From jfdsmit@gmail.com Fri Apr 3 06:34:58 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 ADBFF3A6E0A for ; Fri, 3 Apr 2009 06:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xV2YrKiCIc8c for ; Fri, 3 Apr 2009 06:34:58 -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 C499B3A6E08 for ; Fri, 3 Apr 2009 06:34:57 -0700 (PDT) Received: by fxm2 with SMTP id 2so983944fxm.37 for ; Fri, 03 Apr 2009 06:35:59 -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 :content-transfer-encoding; bh=ns4SKJVEQPmsuEeeN0HxzlMYqlAbo5bjEkBCrCgyRKo=; b=syCUmP0yY4UXBie74FsJf4FFPB+OjoP1XR434PjSEqMXm/jWyXo6CT5YMldV3CJsYj RblMq+kGeVLFyg8kKeHyHrYVVU1kSq8ao79kdoc0cyw11qzbzv6jP7MHroS/eWtjXLdr ie19GWEaipbrQKXLHizMWowK3Pcpktrw1BxaE= 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:content-transfer-encoding; b=ImeDNL5P3VQYyy+CJrjGB+yW5WpTLFQf30Hl0oztLA2D83gE/OiMHX5diHEuhE9cal aUS5X19psMHY9Zjle2sAoBFtRDV4IgYD1RONvZIXqmmwKK8lWHM4iRKjFdw7FQq0L+0l mm80wNls+tp7CmrdBi7nIuNtVzaUdl1dVdnFI= MIME-Version: 1.0 Received: by 10.223.108.196 with SMTP id g4mr1094380fap.36.1238765759718; Fri, 03 Apr 2009 06:35:59 -0700 (PDT) In-Reply-To: <3ad5e1a50904030626ua9826f0o5ed418494d433c48@mail.gmail.com> References: <3ad5e1a50904030626ua9826f0o5ed418494d433c48@mail.gmail.com> Date: Fri, 3 Apr 2009 15:35:59 +0200 Message-ID: From: Jens de Smit To: Saulo Jorge Queiroz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] OLSR2 - Routing Set Updates 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, 03 Apr 2009 13:34:58 -0000 On Fri, Apr 3, 2009 at 3:26 PM, Saulo Jorge Queiroz wrote: > Hello, > > I've worked on algorithms for maintaining Routing Set in OLSR.=A0 Could a= nyone > clarify if a change of the known symmetric links and/or attached networks > necessarily changes the routing set? Well.... That actually depends on your algorithm, doesn't it? But, unless your algorithm selects each and every node as router, there's always a topology where the loss of 1 link does not require the routing set to change to keep the network connected. Regards, Jens From chris.dearlove@baesystems.com Fri Apr 3 06:39:03 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 15CDF3A68FF for ; Fri, 3 Apr 2009 06:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.624 X-Spam-Level: X-Spam-Status: No, score=-6.624 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 o1rYeBfLEIF1 for ; Fri, 3 Apr 2009 06:39:02 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id C8A1E3A68F0 for ; Fri, 3 Apr 2009 06:39:01 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n33De2Fh000624 for ; Fri, 3 Apr 2009 14:40:02 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n33De2M9017372 for ; Fri, 3 Apr 2009 14:40:02 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 03 Apr 2009 14:40:02 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Apr 2009 14:40:02 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B461.B04F16FE" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 3 Apr 2009 14:40:01 +0100 Message-ID: In-Reply-To: <3ad5e1a50904030626ua9826f0o5ed418494d433c48@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSR2 - Routing Set Updates Thread-Index: Acm0X9q+6j7L1NMDR6SfsuWoMkbslAAABKmQ References: <3ad5e1a50904030626ua9826f0o5ed418494d433c48@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Saulo Jorge Queiroz" , X-OriginalArrivalTime: 03 Apr 2009 13:40:02.0190 (UTC) FILETIME=[B072A2E0:01C9B461] Subject: Re: [manet] OLSR2 - Routing Set Updates 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, 03 Apr 2009 13:39:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B461.B04F16FE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think the summary (and we're open to changing the exact wording here if appropriate) of the situation would be =20 - Any change to anything that goes into the Routing Set (including the= cases you note) has the potential to change the Routing Set. =20 - You ought to keep the Routing Set up to date. (Of course there may be quality of implementation issues - do I allow a slightly longer than= necessary delay in which it's out of date, and if so how long?) =20 - If this means you have to recalculate the Routing Set, so be it. But if= (for whatever reason) you can patch the set without recalculating it, so much= the better. If you've got any particularly good ways to do so, please share= them with us. =20 - The specification talks in terms of recalculating the Routing Set any= time something changes, because that's a convenient way to specify the= protocol.. But there's also a blanket "as if" that means you don't have to do it= that way (in fact you don't even have to have a Routing Set in exactly that form). =20 - The Routing Set (and the set of MPRs) also have an additional freedom - while there's a suggested how to do it algorithm, the actual= specification is anything that gives minimum path routes given the specified Topology Graph. So there's another permission to do what works for you. =20 - But don't lose sight of that if you try using outdated routes, for as= long as you do, you will risk looping in the network, and that's not a good= thing. --=20 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= Saulo Jorge Queiroz Sent: 03 April 2009 14:26 To: manet@ietf.org Subject: [manet] OLSR2 - Routing Set Updates *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 =09 Hello, I've worked on algorithms for maintaining Routing Set in OLSR. Could= anyone clarify if a change of the known symmetric links and/or attached= networks necessarily changes the routing set? --=20 Saulo Jorge bq - "Os maus de cora=E7=E3o n=E3o amam nunca; apenas se alegram entre= comparsas" -- Caio F=E1bio ******************************************************************** 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. ******************************************************************** ------_=_NextPart_001_01C9B461.B04F16FE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I think the= summary (and=20 we're open to changing the exact wording here
if= appropriate) of the=20 situation would be
 
- Any change to anything that goes into the= Routing Set=20 (including the cases
  you note) has the potential to change the= Routing=20 Set.
 
- You ought to keep the Routing Set up to date.= (Of course=20 there may be
  quality of implementation issues - do I= allow=20 a slightly longer than necessary
  delay in which it's= out of= date, and if=20 so how long?)
 
- If this means you have to recalculate the= Routing Set, so=20 be it. But if (for
  whatever reason) you can patch the set= without=20 recalculating it, so much the
  better. If you've got any particularly good= ways to=20 do so, please share them
  with us.
 
- The specification talks in terms of= recalculating the=20 Routing Set any time
  something changes, because that's a= convenient way=20 to specify the protocol..
  But there's also a blanket "as if"= that means=20 you don't have to do it that way
  (in fact you don't even have to have a= Routing Set=20 in exactly that form).
 
- The Routing Set (and the set of MPRs) also have= an=20 additional freedom -
  while there's a suggested how to do it= algorithm,=20 the actual specification
  is anything that gives minimum path routes= given the=20 specified Topology
  Graph. So there's another permission to do= what=20 works for you.
 
- But don't lose sight of that if you try using= outdated=20 routes, for as long as
  you do, you will risk looping in the= network, and=20 that's not a good thing.

--=
Christopher=20 Dearlove
Technology Leader, Communications Group
Networks, Security= and=20 Information Systems Department
BAE Systems Advanced Technology= Centre
West=20 Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245=20 242194  Fax: +44 1245 242124

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

 

From: manet-bounces@ietf.org=20 [mailto:manet-bounces@ietf.org] On Behalf Of Saulo Jorge=20 Queiroz
Sent: 03 April 2009 14:26
To:=20 manet@ietf.org
Subject: [manet] OLSR2 - Routing Set=20 Updates

*** WARNING ***

This mail has originated=20 outside your organization,
either from an external partner or the= =20 Global Internet.
Keep this in mind if you answer this message.=20
Hello,

I've worked on algorithms for= =20 maintaining Routing Set in OLSR.  Could anyone clarify if a change of= the=20 known symmetric links and/or attached networks necessarily changes the= routing=20 set?


--
Saulo Jorge bq
-
=93Os maus de= cora=E7=E3o n=E3o=20 amam nunca; apenas se alegram entre comparsas"
-- Caio=20 F=E1bio
****************************************************************= ****
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.
********************************************************************

------_=_NextPart_001_01C9B461.B04F16FE-- From chris.dearlove@baesystems.com Fri Apr 3 06:43:30 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 BDF573A6A04 for ; Fri, 3 Apr 2009 06:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.624 X-Spam-Level: X-Spam-Status: No, score=-6.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, 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 AeID+nraahdX for ; Fri, 3 Apr 2009 06:43:30 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id B2EE23A6452 for ; Fri, 3 Apr 2009 06:43:29 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n33DiU9c001903 for ; Fri, 3 Apr 2009 14:44:31 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n33DiUkP002354 for ; Fri, 3 Apr 2009 14:44:30 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 03 Apr 2009 14:44:30 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Apr 2009 14:44:30 +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, 3 Apr 2009 14:44:29 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSR2 - Routing Set Updates Thread-Index: Acm0YSyXBzybJDQ7QSqNl6lF9psZiQAAJIZg References: <3ad5e1a50904030626ua9826f0o5ed418494d433c48@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Jens de Smit" , "Saulo Jorge Queiroz" X-OriginalArrivalTime: 03 Apr 2009 13:44:30.0336 (UTC) FILETIME=[50467800:01C9B462] Cc: manet@ietf.org Subject: Re: [manet] OLSR2 - Routing Set Updates 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, 03 Apr 2009 13:43:30 -0000 >> I've worked on algorithms for maintaining Routing Set in OLSR.=A0 Could= anyone >> clarify if a change of the known symmetric links and/or attached= networks >> necessarily changes the routing set? > Well.... That actually depends on your algorithm, doesn't it? But, > unless your algorithm selects each and every node as router, there's > always a topology where the loss of 1 link does not require the > routing set to change to keep the network connected. That would be a special case (and quite likely a good one) of the case of only needing to patch the Routing Set when necessary. Link not used, patch is trivial. I can see at least two ways to do that - neither of which I'm claiming is particularly good. One would be to augment to Routing Tuples to retain the whole path used in each case. Amother would be to put a flag next to all links which are used when calculating the Routing Set (and no others). If a flagless link breaks, no need to recalculate the Routing Set. ******************************************************************** 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 Fri Apr 3 07:42: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 AB3623A6E6E for ; Fri, 3 Apr 2009 07:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.453, 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 7I6LGuNXYSNG for ; Fri, 3 Apr 2009 07:42:21 -0700 (PDT) Received: from CPSMTPM-EML103.kpnxchange.com (cpsmtpm-eml103.kpnxchange.com [195.121.3.7]) by core3.amsl.com (Postfix) with ESMTP id E72143A6E67 for ; Fri, 3 Apr 2009 07:42:15 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML103.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 3 Apr 2009 16:43:17 +0200 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Henning Rogge'" References: <00c701c9b38e$18e7eb70$4ab7c250$@nl><200904021510.58935.rogge@fgan.de> <200904031039.33788.rogge@fgan.de> In-Reply-To: Date: Fri, 3 Apr 2009 16:43:18 +0200 Message-ID: <012e01c9b46a$87394420$95abcc60$@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: Acm0N723UQGWT281TCyBj9MiXytYlQAAjUqAAAv6rmA= Content-Language: nl X-OriginalArrivalTime: 03 Apr 2009 14:43:17.0520 (UTC) FILETIME=[86A40900:01C9B46A] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 03 Apr 2009 14:42:21 -0000 |Van: Dearlove, Christopher (UK) |I don't believe that the multiple interface case is the one that |needs maximal efficiency, because this is not going to be the |simplest, lowest power, devices. Of course I think it still needs |efficiency - especially at the number of messages sent level. |One saved message saves a lot more than its number of octets |- it saves many more octets due to 5444, UDP, IP, MAC, PHY |- and not just headers, also multiple access costs. But an odd |octet is less critical. Maybe, maybe not. Some radio technologies do not have high UDP, IP, MAC & PHY overhead and each odd octet could be critical. This type of radios do occur where multiple interfaces are used. At least in my environment. Teco. From ssaulojorge@gmail.com Fri Apr 3 07:49:49 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 54C2A3A6A58 for ; Fri, 3 Apr 2009 07:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 seEPWtd48I9W for ; Fri, 3 Apr 2009 07:49:48 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id CE86C28C136 for ; Fri, 3 Apr 2009 07:49:47 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so1369476yxm.49 for ; Fri, 03 Apr 2009 07:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :received:message-id:subject:from:to:cc:content-type; bh=CfGjAQMYEiu6ww4/LyS0YEG6ZHQQbGA5Dexk3pi4VsE=; b=UPSlLSJumhjgNFj3BhgOn/Bo7oKlTeltWiShx/rUqUYOeM43WtQfu994HB05PS9cOz oAFyz5gNxjDNQy2v82OBQ8CBDU30pzlSGvT53Vwq/kEGG0cQHja65LGIB7+ITt72tuo7 Kcww6Bjx4vrQ7yeFZanmTRXsGaTKyxbMaz8Bc= 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=LVNh2DJ60apJQJaazuC7HG0gzUfoVwIZV4wuMexBhGvl/xccYU+pne/BFZKgBWD5Cm mTT52xRbocyWIMCTqPIxjt5Rxl8EPZ5SfmTJKbzJjoXMOwafmbT54X8rosDXRReBmHU0 mA2E56EP+mVyqlyRHUqzwxvZ9LxDnXPgdnS04= MIME-Version: 1.0 In-Reply-To: References: <3ad5e1a50904030626ua9826f0o5ed418494d433c48@mail.gmail.com> Date: Fri, 3 Apr 2009 10:50:34 -0400 Received: by 10.151.100.17 with SMTP id c17mr2318581ybm.216.1238770250311; Fri, 03 Apr 2009 07:50:50 -0700 (PDT) Message-ID: <3ad5e1a50904030750k27bd8928jb5380d4b66613478@mail.gmail.com> From: Saulo Jorge Queiroz To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=00151751146cba6b1a0466a7ac79 Cc: manet@ietf.org Subject: Re: [manet] OLSR2 - Routing Set Updates 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, 03 Apr 2009 14:49:49 -0000 --00151751146cba6b1a0466a7ac79 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The Ramalingan and Reps algorithm (and any one based on Bounded Incremental Computation Model) defines a dag Gd=3D(V,A') from the graph G=3D(V,A) in su= ch a way that A' has all edges which belongs to current known shortest paths. For every new edge information the Topology of graph G is necessarily updated but info about SPTree (pi[v] and d[v] for all v in G) and so, Gd, are updated only if edge inserted / deleted / updated (weight) belongs (belonged) to Gd. Once Gd is affected, the algorithm identify the set of routers for which shortest paths must be recomputed and do it. The running time is given in terms of delta (instead all |V|). I think that routing set could be seen as Gd (i.e. the space complexity is the same as in Dijkstra) 2009/4/3 Dearlove, Christopher (UK) > I think the summary (and we're open to changing the exact wording here > if appropriate) of the situation would be > > - Any change to anything that goes into the Routing Set (including the > cases > you note) has the potential to change the Routing Set. > > - You ought to keep the Routing Set up to date. (Of course there may be > quality of implementation issues - do I allow a slightly longer > than necessary > delay in which it's out of date, and if so how long?) > > - If this means you have to recalculate the Routing Set, so be it. But if > (for > whatever reason) you can patch the set without recalculating it, so muc= h > the > better. If you've got any particularly good ways to do so, please share > them > with us. > > - The specification talks in terms of recalculating the Routing Set any > time > something changes, because that's a convenient way to specify the > protocol.. > But there's also a blanket "as if" that means you don't have to do it > that way > (in fact you don't even have to have a Routing Set in exactly that form= ). > > - The Routing Set (and the set of MPRs) also have an additional freedom - > while there's a suggested how to do it algorithm, the actual > specification > is anything that gives minimum path routes given the specified Topology > Graph. So there's another permission to do what works for you. > > - But don't lose sight of that if you try using outdated routes, for as > long as > you do, you will risk looping in the network, and that's not a good > thing. > > -- > 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 > > > ------------------------------ > *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On Behalf > Of *Saulo Jorge Queiroz > *Sent:* 03 April 2009 14:26 > *To:* manet@ietf.org > *Subject:* [manet] OLSR2 - Routing Set Updates > > *** WARNING *** > > This mail has originated outside your organization, > either from an external partner or the Global Internet. > Keep this in mind if you answer this message. > Hello, > > I've worked on algorithms for maintaining Routing Set in OLSR. Could > anyone clarify if a change of the known symmetric links and/or attached > networks necessarily changes the routing set? > > > -- > Saulo Jorge bq > - > =93Os maus de cora=E7=E3o n=E3o amam nunca; apenas se alegram entre compa= rsas" > -- Caio F=E1bio > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > --=20 Saulo Jorge bq - =93Os maus de cora=E7=E3o n=E3o amam nunca; apenas se alegram entre compars= as" -- Caio F=E1bio --00151751146cba6b1a0466a7ac79 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The Ramalingan and Reps algorithm (and any one based on Bounded Incremental= Computation Model) defines a dag Gd=3D(V,A') from the graph G=3D(V,A) = in such a way that A' has all edges which belongs to current known shor= test paths.

For every new edge information=A0 the Topology of graph G is necessaril= y updated but info about SPTree (pi[v] and d[v] for all v in G) and so, Gd,= are updated only if edge inserted / deleted / updated (weight) belongs (be= longed) to Gd.=A0 Once Gd is affected, the algorithm identify the set of ro= uters for which shortest paths must be recomputed and do it. The running ti= me is given in terms of delta (instead all |V|).

I think that routing set could be seen as Gd (i.e. the space complexity= is the same as in Dijkstra)


2009/4/3= Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>
I think the summary (and=20 we're open to changing the exact wording here
if appropriate) of the=20 situation would be
=A0
- Any change to anything that goes into the Routing Set=20 (including the cases
=A0 you note) has the potential to change the Routing=20 Set.
=A0
- You ought to keep the Routing Set up to date. (Of course=20 there may be
=A0 quality of implementation issues - do I allow=20 a=A0slightly longer than=A0necessary
=A0=A0delay in which it's out of date, and if=20 so how long?)
=A0
- If this means you have to recalculate the Routing Set, so=20 be it. But if (for
=A0 whatever reason) you can patch the set without=20 recalculating it, so much the
=A0 better. If you've got any particularly good ways to=20 do so, please share them
=A0 with us.
=A0
- The specification talks in terms of recalculating the=20 Routing Set any time
=A0 something changes, because that's a convenient way=20 to specify the protocol..
=A0=A0But there's also a blanket "as if" that me= ans=20 you don't have to do it that way
=A0 (in fact you don't even have to have a Routing Set=20 in exactly that form).
=A0
- The Routing Set (and the set of MPRs) also have an=20 additional freedom -
=A0 while there's a suggested how to do it algorithm,=20 the actual specification
=A0 is anything that gives minimum path routes given the=20 specified Topology
=A0 Graph. So there's another permission to do what=20 works for you.
=A0
- But don't lose sight of that if you try using outdated= =20 routes, for as long as
=A0 you do, you will risk looping in the network, and=20 that's not a good thing.

--
Christopher=20 Dearlove
Technology Leader, Communications Group
Networks, Security a= nd=20 Information Systems Department
BAE Systems Advanced Technology CentreWest=20 Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245= =20 242194=A0 Fax: +44 1245 242124

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

=A0

From: manet-bounces@ietf.org=20 [mailto:manet-b= ounces@ietf.org] On Behalf Of Saulo Jorge=20 Queiroz
Sent: 03 April 2009 14:26
To:=20 manet@ietf.org
<= b>Subject: [manet] OLSR2 - Routing Set=20 Updates

*** WARNING ***

This mail has originated= =20 outside your organization,
either from an external partner or the= =20 Global Internet.
Keep this in mind if you answer this message.=20
Hello,
I've worked on algorithms for=20 maintaining Routing Set in OLSR.=A0 Could anyone clarify if a change of the= =20 known symmetric links and/or attached networks necessarily changes the rout= ing=20 set?


--
Saulo Jorge bq
-
=93Os maus de c= ora=E7=E3o n=E3o=20 amam nunca; apenas se alegram entre comparsas"
-- Caio=20 F=E1bio
*********= ***********************************************************
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.
********************************************************************



<= br>--
Saulo Jorge bq
-
=93Os maus de cora=E7=E3o n=E3o amam nunca= ; apenas se alegram entre comparsas"
-- Caio F=E1bio
--00151751146cba6b1a0466a7ac79-- From dastudente@gmail.com Fri Apr 3 08:23:16 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 DFBEB28C284 for ; Fri, 3 Apr 2009 08:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 yunsaVI7hbv4 for ; Fri, 3 Apr 2009 08:23:16 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 51E2028C29D for ; Fri, 3 Apr 2009 08:23:07 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so221232eyf.31 for ; Fri, 03 Apr 2009 08:24:09 -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=9Z/ZSX158fd4Jtg47jTDFYpyVzd+ojTkcA5tiO8lGLM=; b=OZ4stBhEZKk57CdKumPPZ4yfkT1yDxE+TB1sh0zIQVC4T+3MmIFF/TwwrzLFcoEn37 i301gnSuMQaNqNznUESoYOM3kEOeEoRdIx28boIKlGowIfjeAQ2Mr+P36yA7UZx6j71E 5JzSJe+I7+xrC1KEguR2x5Ct1kEv45gmDjuL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=jjSFLpQ0ATpDbp8r3IDysHV2Tx8HLmbMgjwTJVkhG+wnbR+1dqGVpwM3LCXZZg5XJK t+OIWS1qqgG+KyBkVpvrPRCcsegtfL2KKaMZ/J2jPV0gZ5kLacJh5SGL9aGCBQAJ1u5g PnHMDsjuyHloGzQviblE4A+hvsrilde8mPv1E= MIME-Version: 1.0 Received: by 10.216.45.78 with SMTP id o56mr456636web.152.1238772249123; Fri, 03 Apr 2009 08:24:09 -0700 (PDT) Date: Fri, 3 Apr 2009 18:24:09 +0300 Message-ID: <16556380904030824q3f2aad1as22697931fd726e9e@mail.gmail.com> From: Dawit Gebremichael To: manet@ietf.org Content-Type: multipart/alternative; boundary=0016367b6de6dddb920466a82368 Subject: [manet] How to identfy IP address first time 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, 03 Apr 2009 15:23:17 -0000 --0016367b6de6dddb920466a82368 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear, A MANET node (using AODV) sends a RREQ message of a node whose address it knows if the path to that node does not exist in its route cache. But, how can a node comes to know the address of a node it has not communicated with before? Is there any mechanism by which a MANET node knows the IP addresses of all the nodes in the network? Regards, Da --0016367b6de6dddb920466a82368 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
Dear,
=A0
A=A0MANET node (using AODV)=A0sends a RREQ=A0 message=A0of a node whos= e address it knows if the=A0 path to that node does not exist in its route = cache. But, how can a node comes to know the address of a node it has not c= ommunicated with before? Is there any mechanism by which a MANET node knows= the IP addresses of all the nodes in the network?
=A0
Regards,
Da
--0016367b6de6dddb920466a82368-- From charles.perkins@earthlink.net Fri Apr 3 09:40: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 5AE9228C14D for ; Fri, 3 Apr 2009 09:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=-0.926, BAYES_00=-2.599, 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 jpuZSaRRNXUc for ; Fri, 3 Apr 2009 09:40:58 -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 794B83A6ACE for ; Fri, 3 Apr 2009 09:40:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=bLBuhiBC0Qzdjr7BZsTjHxDBSHH/ZYHBeuEDsB/CvxJcVBShx1Mtktk/N8OXFWFd; 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 [99.51.129.145] (helo=[10.166.254.139]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LpmSu-0004yE-1q; Fri, 03 Apr 2009 12:42:00 -0400 Message-ID: <49D63C55.4070105@earthlink.net> Date: Fri, 03 Apr 2009 09:41:57 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> <200904021510.58935.rogge@fgan.de><010b01c9b445$91d94c10$b58be430$@nl> <011a01c9b45c$eed44750$cc7cd5f0$@nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f526fcfc65966c1bf5961b11cf11f61a10d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 03 Apr 2009 16:40:59 -0000 Hello Chris, Comments below... Dearlove, Christopher (UK) wrote: > >> I don't understand this. The requirement is that the set >> of MPRs must provide connectivity to all 2-hop neighbors >> > > That's not sufficient. > I believe this is highly debatable. > >> o Why MPR selection per interface? >> > > Read the literature. And yes, that is me not putting in the effort > to point out the race condition case and why per interface avoids > it and per router doesn't (a subtlety in the MPR flooding proof). > I read the proofs, albeit a couple of years ago, and I don't remember anything particular about this point. Too bad I can't go back and review this material today. > The point is, this is a far too late, ill-thought out, proposal. > This is what goaded me into making a response. First of all, I saw a suggestion, not a proposal. Of course it wasn't fully thought out. Second, it's never too late to simplify and improve a protocol. Sometimes it is too late for a particular publication. Sometimes code has to get frozen in order to test and ship it. It's never too late to suggest improvements. And if the engineering management decides to ship a product because the improvements cannot be incorporated, then the improvements may well be considered for future product upgrades. Perhaps you will claim that no future upgrades are envisioned for OLSR. Regards, Charlie P. From teco@inf-net.nl Fri Apr 3 11:18: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 7B8513A6C87 for ; Fri, 3 Apr 2009 11:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, 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 yPGQPcXUUfWj for ; Fri, 3 Apr 2009 11:18:20 -0700 (PDT) Received: from CPSMTPM-EML101.kpnxchange.com (cpsmtpm-eml101.kpnxchange.com [195.121.3.5]) by core3.amsl.com (Postfix) with ESMTP id F18003A6CCA for ; Fri, 3 Apr 2009 11:18:19 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML101.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 3 Apr 2009 20:19:21 +0200 From: "Teco Boot" To: References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> <200904021510.58935.rogge@fgan.de><010b01c9b445$91d94c10$b58be430$@nl> <011a01c9b45c$eed44750$cc7cd5f0$@nl> In-Reply-To: Date: Fri, 3 Apr 2009 20:19:23 +0200 Message-ID: <016a01c9b488$b6de3e60$249abb20$@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: AcmzlIC+onk0R3AEQEKpDJFihjxXAgABeYlAAClIEUAAAY5goAAEd7jAAAFdGbAACikbQA== Content-Language: nl X-OriginalArrivalTime: 03 Apr 2009 18:19:21.0814 (UTC) FILETIME=[B5F64F60:01C9B488] Subject: Re: [manet] OLSRv2 - RouterID 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, 03 Apr 2009 18:18:21 -0000 I'll prefer the technical discussion. But some words on: >> this is a far too late, ill-thought out, proposal Far too late: ============= I raised this issues a couple of times before. See below minutes of IETF-71 and two ML postings. During meetings between, the response was "get out packetBB and others first, thereafter we can take a look at it". Now the time has come. Ill-thought out: ================ Great scientists in history had ill-thought ideas. Nowadays, we think different. I'm not saying my proposal is brilliant or even it is mine. Back to the technical discussion: ================================= >>>> o Why MPR selection per interface? > Read the literature. I read again the documents on MPR. I did not find problems with MPR selection based on nodes. Can someone come up with some material? Otherwise my conclusion is that my proposal is an important enhancement. Teco. === Meeting : IETF 71 Monday March 10th 2008 Teco Boot: The number of addresses exchanged with the interface IDs is problematic. It is inefficient. Is possible to simply use a single router ID to improve it ? Thomas Clausen: If you have only one interface with one address, then things might be simplify-able. However with multiple interfaces and multiple addresses, then the bi-directionality check of a link over a pair of interfaces requires information describing all addresses. Ian Chakeres: Let's put this on the "to do" list. === http://www.ietf.org/mail-archive/web/manet/current/msg10433.html Date: Mon, 28 Jul 2008 19:15:17 +0200 All, Let me repeat an older comment on NHDP (and OLSRv2). The current document mandates exchange of ALL addresses on ALL interfaces of the MANET Router. E.g. page 11: o A 2-Hop Set, which records the existence of bidirectional links between symmetric 1-hop neighbors of this MANET interface and other nodes (symmetric 2-hop neighbors). The 2-Hop Set consists of 2-Hop Tuples, each of which records an interface address of a symmetric 2-hop neighbor, and all interface addresses of the ======================= corresponding symmetric 1-hop neighbor. The 2-Hop Set is updated by the signaling of this protocol, but is not itself reported in that signaling. I prefer reducing overhead where we can, as bandwidth in the MANET can be scarce and improvements on efficiency helps scalability. IMHO a MANET router could advertize a single summary prefix into the MANET protocol. For NHDP, a RouterID or alternative approach could be used for identifying a MANET Router. Therefore I want to have removed specifications that **all interface addresses** are exchanged. Please respond on this opinion. Regards, Teco === http://www.ietf.org/mail-archive/web/manet/current/msg10478.html From: "Dearlove, Christopher (UK)" Date: Wed, 27 Aug 2008 12:28:49 +0100 I agree with you in that this should be qualified as limited to addresses which the node wishes to make available for non-local routing. If a node has an address that it doesn't want to be used for routing to it from other nodes, there is of course no reason to advertise that. We should qualify the wording to indicate that. Whether a node then wants to advertise a single address, a single prefix, or multiple addresses/prefixes is then up to it, but it needs to then be consistent (it can change its advertisement, but this over-rides any previous advertisement and should be done infrequently). === From ssaulojorge@gmail.com Sat Apr 4 05:26:46 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 B04E13A68DB for ; Sat, 4 Apr 2009 05:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 mTOtjQYKM3UG for ; Sat, 4 Apr 2009 05:26:45 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id AEFE13A67D2 for ; Sat, 4 Apr 2009 05:26:45 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so1901114yxm.49 for ; Sat, 04 Apr 2009 05:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :received:message-id:subject:from:to:cc:content-type; bh=qWF8HiVVR/brrjaVar5PK7nj1Keg7mBeVW8ZwtySSMM=; b=eJxiXHvJebjStf1uMDWKxqY1h8Lt9wn3osHx1SOyblf7ga4FLapTZ2hrEqh1qf4GZU 5dIQ1Va2N62bpMVOAKGW09nRcVI1f4aD35UzStIY9rxR1ASgZGi00hvAYz4qiU/i3aB0 b8abCMtLS8BK57dDyZfr+V6dyYCcZLVw5iDCk= 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=Ssd/dZuQiMgZjn8X7kppWuyo8obBmuhA0QXT3d4ZVWUD9cr4PSLYxRh8+OOC9orxXa feznSW3BG/vKBUX4/tFbB2uznKtwlFTR5l3GDvFtVRQbU3EG6pECghsu+ucJUijFN5oP vHMxx6BrbYMUAopHex6wDw6dWg/d6xc9cpE7w= MIME-Version: 1.0 In-Reply-To: References: <3ad5e1a50904030626ua9826f0o5ed418494d433c48@mail.gmail.com> Date: Sat, 4 Apr 2009 08:27:34 -0400 Received: by 10.150.225.17 with SMTP id x17mr4284675ybg.76.1238848069235; Sat, 04 Apr 2009 05:27:49 -0700 (PDT) Message-ID: <3ad5e1a50904040527t799f0784ydcb376774dc05f7a@mail.gmail.com> From: Saulo Jorge Queiroz To: jfdsmit@gmail.com Content-Type: multipart/alternative; boundary=000e0cd4033218f4d20466b9cbc5 Cc: manet@ietf.org Subject: Re: [manet] OLSR2 - Routing Set Updates 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, 04 Apr 2009 12:26:46 -0000 --000e0cd4033218f4d20466b9cbc5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2009/4/3 Jens de Smit > On Fri, Apr 3, 2009 at 3:26 PM, Saulo Jorge Queiroz > wrote: > > Hello, > > > > I've worked on algorithms for maintaining Routing Set in OLSR. Could > anyone > > clarify if a change of the known symmetric links and/or attached networ= ks > > necessarily changes the routing set? > > Well.... That actually depends on your algorithm, doesn't it? Up to now, I think it depends on more of topology discovery configuration o= f OLSR than SSP algorithm. I performed several (time infinite-horizon) simulations and noticed that proportion of times routing table changed could be drammatically reduced by turnning MPR (RFC3626) off and by using fish-eye algorithm (in comparison with RFC3626). > But, > unless your algorithm selects each and every node as router, there's > always a topology where the loss of 1 link does not require the > routing set to change to keep the network connected. > > Regards, > > Jens > --=20 Saulo Jorge bq - =93Os maus de cora=E7=E3o n=E3o amam nunca; apenas se alegram entre compars= as" -- Caio F=E1bio --000e0cd4033218f4d20466b9cbc5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

2009/4/3 Jens de Smit = <jfdsmit@gmail.com>
On Fri, Apr 3, 2009 at 3:26 PM, Saulo Jorge Queiroz
<ssaulojorge@gmail.com> = wrote:
> Hello,
>
> I've worked on algorithms for maintaining Routing Set in OLSR.=A0 = Could anyone
> clarify if a change of the known symmetric links and/or attached netwo= rks
> necessarily changes the routing set?

Well.... That actually depends on your algorithm, doesn't it?
=A0
Up to now, I think it depends on more of topolo= gy discovery configuration of OLSR than SSP algorithm.=A0 I performed sever= al (time infinite-horizon) simulations and noticed that=A0 proportion of ti= mes routing table changed could be=A0 drammatically reduced by turnning MPR= (RFC3626) off and by using fish-eye algorithm (in comparison with RFC3626)= .
But,
unless your algorithm selects each and every node as router, there's always a topology where the loss of 1 link does not require the
routing set to change to keep the network connected.

Regards,

Jens



--
Saulo Jorge bq-
=93Os maus de cora=E7=E3o n=E3o amam nunca; apenas se alegram entre = comparsas"
-- Caio F=E1bio
--000e0cd4033218f4d20466b9cbc5-- From sana_cis@yahoo.com Fri Apr 3 09:14: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 735B93A6A42 for ; Fri, 3 Apr 2009 09:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.161 X-Spam-Level: X-Spam-Status: No, score=-1.161 tagged_above=-999 required=5 tests=[AWL=-0.977, BAYES_40=-0.185, HTML_MESSAGE=0.001] 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 2MUpRE1lynsq for ; Fri, 3 Apr 2009 09:14:14 -0700 (PDT) Received: from n54.bullet.mail.sp1.yahoo.com (n54.bullet.mail.sp1.yahoo.com [98.136.44.32]) by core3.amsl.com (Postfix) with SMTP id CE4883A6A07 for ; Fri, 3 Apr 2009 09:14:14 -0700 (PDT) Received: from [216.252.122.218] by n54.bullet.mail.sp1.yahoo.com with NNFMP; 03 Apr 2009 16:15:17 -0000 Received: from [67.195.9.82] by t3.bullet.sp1.yahoo.com with NNFMP; 03 Apr 2009 16:15:17 -0000 Received: from [67.195.9.106] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 03 Apr 2009 16:15:17 -0000 Received: from [127.0.0.1] by omp110.mail.gq1.yahoo.com with NNFMP; 03 Apr 2009 16:13:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 556189.74589.bm@omp110.mail.gq1.yahoo.com Received: (qmail 21690 invoked by uid 60001); 3 Apr 2009 16:15:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238775317; bh=JR34ivwm3DaU+bMI8yn6sPsS4Hy11q/s0tqII29VIS8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=ZGqI4su/atrujseQ8tCSLpFVEsBhjzH3/hF6FDu7VGWPhIm+/8lu5+2EMjDYlytlUTiQ+HOPgkGCh82LGUtIL22O916oEM+f58bYbqkjJdHnlRFPoO3ohRDbTSfvf/mw1qWOGdQVqJ48vUmFCc2JKUoFISNxRfDlkFuewtvpUSg= 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=lX2Bdhv8z0AMRZrCecH4lIltWbTgHGT15kt61H0gKoo7CfMqnsIeAfG8B3Pel5p3EXLcX2IkBXQ740doTMtCZy6vWFUTnMtlreYNGx/Au6jXa2VCFV+7rCrpAj/ldGtKRL0F46Zswm1U07Vn0yiNygHuZruN+o7hh/8Xhj0W2J0=; Message-ID: <159422.18647.qm@web111116.mail.gq1.yahoo.com> X-YMail-OSG: olJvo5QVM1mlzmKroMJikuFEufkUz2Y9NGQB9IDi4xmzs_AkmsD9ARJODMpkGX3Vlhe8RR_AnBAvILjUPsmBim3efeVl8UWVAj_Ke7r.y5BBPwRE.oQ3vTksh4.X00JZ2xKgNYFicycPeampxwszdeLq19DdR3eeuejSec18.RL31cf0aYwJEaDwpspFUL6O2wRi4mxK2Ydun_ItUjFvhXMxHu8a Received: from [94.249.7.157] by web111116.mail.gq1.yahoo.com via HTTP; Fri, 03 Apr 2009 09:15:15 PDT X-Mailer: YahooMailClassic/5.2.15 YahooMailWebService/0.7.289.1 Date: Fri, 3 Apr 2009 09:15:15 -0700 (PDT) From: sana wedian To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-795460731-1238775315=:18647" X-Mailman-Approved-At: Sat, 04 Apr 2009 08:12:45 -0700 Subject: [manet] exchanging topology info. ? 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, 03 Apr 2009 16:14:15 -0000 --0-795460731-1238775315=:18647 Content-Type: text/plain; charset=us-ascii Dear all, I need to know if there is a way for the nodes in MANET to exchange their topological information periodically without using hello messages?? if there is, i'll be so thankful to provide me by some hints. Best regards, Sana --0-795460731-1238775315=:18647 Content-Type: text/html; charset=us-ascii
Dear all,

I need to know if there is a way for the nodes in MANET to exchange their topological information periodically without using hello messages??

if there is, i'll be so thankful to provide me by some hints.

Best regards,
Sana

--0-795460731-1238775315=:18647-- From ssaulojorge@gmail.com Sun Apr 5 09:22:11 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 0BD9C3A689E for ; Sun, 5 Apr 2009 09:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 kmhA6ipv5-0Y for ; Sun, 5 Apr 2009 09:22:09 -0700 (PDT) Received: from mail-gx0-f160.google.com (mail-gx0-f160.google.com [209.85.217.160]) by core3.amsl.com (Postfix) with ESMTP id 2751C3A6A2B for ; Sun, 5 Apr 2009 09:22:06 -0700 (PDT) Received: by gxk4 with SMTP id 4so3942009gxk.13 for ; Sun, 05 Apr 2009 09:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :received:message-id:subject:from:to:cc:content-type; bh=4VSmsSbQvO2WREfOpGFDX7L6DAxCjYtmMEfz7efJ0Es=; b=vVm4e6LH8Ytn5jq2HDlzNcJ73CffeLMgZzgtInWktZVevs3wI3gAJOiQD1/l/u6UPq EL4r3DL+H0Uc6K4adhS4TO1vC5GLxttd0mVX5aST9jMCURoSY892ASt+r+oubdi2l+Bd j2rr5U5GKoo807JkZecQuhR/6SSSfyBg3lELM= 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=UMEmHt9jSnBBhTMMuocjmH8VHX09BnAL64hK/TetwIO6Mu0n2HW6kGWuNbd95yG7mM OBS7EBh4aMkMGl14oaznVbYyz/1rrkbnsFrg9KiVvSg7hVyASYLIdhKJWmX/eORUKZPW 556zCNBXz05yGYiylN+U9P2mr/S5NYctjxcT8= MIME-Version: 1.0 In-Reply-To: <3ad5e1a50904030750k27bd8928jb5380d4b66613478@mail.gmail.com> References: <3ad5e1a50904030626ua9826f0o5ed418494d433c48@mail.gmail.com> <3ad5e1a50904030750k27bd8928jb5380d4b66613478@mail.gmail.com> Date: Sun, 5 Apr 2009 12:22:55 -0400 Received: by 10.151.41.14 with SMTP id t14mr6597121ybj.144.1238948590427; Sun, 05 Apr 2009 09:23:10 -0700 (PDT) Message-ID: <3ad5e1a50904050922j4fab3802ub20f372d291a85cf@mail.gmail.com> From: Saulo Jorge Queiroz To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=0015174ff61ea09e6b0466d132b4 Cc: manet@ietf.org Subject: Re: [manet] OLSR2 - Routing Set Updates 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: Sun, 05 Apr 2009 16:22:11 -0000 --0015174ff61ea09e6b0466d132b4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable An additional note: 'delta' is the set of routers whose shortest paths changed after one update on the graph (i.e. delta is in V-{source}, and 0<=3D|delta|<=3D |V|-1). 2009/4/3 Saulo Jorge Queiroz > The Ramalingan and Reps algorithm (and any one based on Bounded Increment= al > Computation Model) defines a dag Gd=3D(V,A') from the graph G=3D(V,A) in = such a > way that A' has all edges which belongs to current known shortest paths. > > For every new edge information the Topology of graph G is necessarily > updated but info about SPTree (pi[v] and d[v] for all v in G) and so, Gd, > are updated only if edge inserted / deleted / updated (weight) belongs > (belonged) to Gd. Once Gd is affected, the algorithm identify the set of > routers for which shortest paths must be recomputed and do it. The runnin= g > time is given in terms of delta (instead all |V|). > > I think that routing set could be seen as Gd (i.e. the space complexity i= s > the same as in Dijkstra) > > > 2009/4/3 Dearlove, Christopher (UK) > > I think the summary (and we're open to changing the exact wording here >> if appropriate) of the situation would be >> >> - Any change to anything that goes into the Routing Set (including the >> cases >> you note) has the potential to change the Routing Set. >> >> - You ought to keep the Routing Set up to date. (Of course there may be >> quality of implementation issues - do I allow a slightly longer >> than necessary >> delay in which it's out of date, and if so how long?) >> >> - If this means you have to recalculate the Routing Set, so be it. But i= f >> (for >> whatever reason) you can patch the set without recalculating it, so mu= ch >> the >> better. If you've got any particularly good ways to do so, please shar= e >> them >> with us. >> >> - The specification talks in terms of recalculating the Routing Set any >> time >> something changes, because that's a convenient way to specify the >> protocol.. >> But there's also a blanket "as if" that means you don't have to do it >> that way >> (in fact you don't even have to have a Routing Set in exactly that >> form). >> >> - The Routing Set (and the set of MPRs) also have an additional freedom = - >> while there's a suggested how to do it algorithm, the actual >> specification >> is anything that gives minimum path routes given the specified Topolog= y >> Graph. So there's another permission to do what works for you. >> >> - But don't lose sight of that if you try using outdated routes, for as >> long as >> you do, you will risk looping in the network, and that's not a good >> thing. >> >> -- >> 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 >> >> >> ------------------------------ >> *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On Behal= f >> Of *Saulo Jorge Queiroz >> *Sent:* 03 April 2009 14:26 >> *To:* manet@ietf.org >> *Subject:* [manet] OLSR2 - Routing Set Updates >> >> *** WARNING *** >> >> This mail has originated outside your organization, >> either from an external partner or the Global Internet. >> Keep this in mind if you answer this message. >> Hello, >> >> I've worked on algorithms for maintaining Routing Set in OLSR. Could >> anyone clarify if a change of the known symmetric links and/or attached >> networks necessarily changes the routing set? >> >> >> -- >> Saulo Jorge bq >> - >> =93Os maus de cora=E7=E3o n=E3o amam nunca; apenas se alegram entre comp= arsas" >> -- Caio F=E1bio >> ******************************************************************** >> 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. >> ******************************************************************** >> >> > > > -- > Saulo Jorge bq > - > =93Os maus de cora=E7=E3o n=E3o amam nunca; apenas se alegram entre compa= rsas" > -- Caio F=E1bio > --=20 Saulo Jorge bq - =93Os maus de cora=E7=E3o n=E3o amam nunca; apenas se alegram entre compars= as" -- Caio F=E1bio --0015174ff61ea09e6b0466d132b4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable An additional note:

'delta' is the set of routers whose shor= test paths changed after one update on the graph (i.e. delta is in V-{sourc= e}, and 0<=3D|delta|<=3D |V|-1).

20= 09/4/3 Saulo Jorge Queiroz <ssaulojorge@gmail.com>
The Ramalingan an= d Reps algorithm (and any one based on Bounded Incremental Computation Mode= l) defines a dag Gd=3D(V,A') from the graph G=3D(V,A) in such a way tha= t A' has all edges which belongs to current known shortest paths.

For every new edge information=A0 the Topology of graph G is necessaril= y updated but info about SPTree (pi[v] and d[v] for all v in G) and so, Gd,= are updated only if edge inserted / deleted / updated (weight) belongs (be= longed) to Gd.=A0 Once Gd is affected, the algorithm identify the set of ro= uters for which shortest paths must be recomputed and do it. The running ti= me is given in terms of delta (instead all |V|).

I think that routing set could be seen as Gd (i.e. the space complexity= is the same as in Dijkstra)


2009/4/3= Dearlove, Christopher (UK) <chris.dearlove@baesystems.com= >

I think the summary (and=20 we're open to changing the exact wording here
if appropriate) of the=20 situation would be
=A0
- Any change to anything that goes into the Routing Set=20 (including the cases
=A0 you note) has the potential to change the Routing=20 Set.
=A0
- You ought to keep the Routing Set up to date. (Of course=20 there may be
=A0 quality of implementation issues - do I allow=20 a=A0slightly longer than=A0necessary
=A0=A0delay in which it's out of date, and if=20 so how long?)
=A0
- If this means you have to recalculate the Routing Set, so=20 be it. But if (for
=A0 whatever reason) you can patch the set without=20 recalculating it, so much the
=A0 better. If you've got any particularly good ways to=20 do so, please share them
=A0 with us.
=A0
- The specification talks in terms of recalculating the=20 Routing Set any time
=A0 something changes, because that's a convenient way=20 to specify the protocol..
=A0=A0But there's also a blanket "as if" that me= ans=20 you don't have to do it that way
=A0 (in fact you don't even have to have a Routing Set=20 in exactly that form).
=A0
- The Routing Set (and the set of MPRs) also have an=20 additional freedom -
=A0 while there's a suggested how to do it algorithm,=20 the actual specification
=A0 is anything that gives minimum path routes given the=20 specified Topology
=A0 Graph. So there's another permission to do what=20 works for you.
=A0
- But don't lose sight of that if you try using outdated= =20 routes, for as long as
=A0 you do, you will risk looping in the network, and=20 that's not a good thing.

--
Christopher=20 Dearlove
Technology Leader, Communications Group
Networks, Security a= nd=20 Information Systems Department
BAE Systems Advanced Technology CentreWest=20 Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245= =20 242194=A0 Fax: +44 1245 242124

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

=A0

From: manet-bounces@ietf.org=20 [mailto:manet-b= ounces@ietf.org] On Behalf Of Saulo Jorge=20 Queiroz
Sent: 03 April 2009 14:26
To:=20 manet@ietf.org
<= b>Subject: [manet] OLSR2 - Routing Set=20 Updates

*** WARNING ***

This mail has originated= =20 outside your organization,
either from an external partner or the= =20 Global Internet.
Keep this in mind if you answer this message.=20
Hello,

I've= worked on algorithms for=20 maintaining Routing Set in OLSR.=A0 Could anyone clarify if a change of the= =20 known symmetric links and/or attached networks necessarily changes the rout= ing=20 set?


--
Saulo Jorge bq
-
=93Os maus de c= ora=E7=E3o n=E3o=20 amam nunca; apenas se alegram entre comparsas"
-- Caio=20 F=E1bio
*********= ***********************************************************
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.
********************************************************************

<= /div>



--
Saulo Jorge bq
-=
=93Os maus de cora=E7=E3o n=E3o amam nunca; apenas se alegram entre com= parsas"
-- Caio F=E1bio



--
Saulo Jorge= bq
-
=93Os maus de cora=E7=E3o n=E3o amam nunca; apenas se alegram e= ntre comparsas"
-- Caio F=E1bio
--0015174ff61ea09e6b0466d132b4-- From Rogge@fgan.de Mon Apr 6 02:18:07 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 25F423A6B79 for ; Mon, 6 Apr 2009 02:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.042 X-Spam-Level: X-Spam-Status: No, score=-5.042 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_EQ_DE=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 xhjJ-4-3QlmM for ; Mon, 6 Apr 2009 02:18:06 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id E74B63A69CF for ; Mon, 6 Apr 2009 02:18:05 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Lqkyy-00012u-M0; Mon, 06 Apr 2009 11:19:08 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1Lqkyy-0000rR-1v; Mon, 06 Apr 2009 11:19:08 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 11:19:07 +0200 From: Henning Rogge To: "Dearlove, Christopher (UK)" Date: Mon, 6 Apr 2009 11:19:01 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.26-1-openvz-686; KDE/4.1.4; i686; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart65214028.B8M21cGDSr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904061119.07374.rogge@fgan.de> X-OriginalArrivalTime: 06 Apr 2009 09:19:08.0035 (UTC) FILETIME=[BD156530:01C9B698] X-Virus-Scanned: yes (ClamAV 0.94.2/9206/Sun Apr 5 20:23:11 2009) by mailguard.fgan.de X-Scan-Signature: c772b2ea0022692dee5192ab69800584 Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 09:18:07 -0000 --nextPart65214028.B8M21cGDSr Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I had some time to look at the MPR calculation in OLSRv2 and I'm still not convinced that the interface IPs are necessary to calculate routing and forwarding set. So I try to explain our (Markus Kittenberg from Vienna and me) concept a little bit more. Even if it's too late to include this into the main OLSRv2 RFCs I will=20 continue to work on the concept to see if it can be done correctly because I think it's a good idea to allow an easier use of linklocal addresses and handling of dynamic interfaces. The router-id of a node should be a FIXED IP address which does not change. The base of the concept is that there should be no change in packet format, just a change what kind of IP will be written into Hello/TC messages. OLSRv2/NHDP messages changes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Hellomessages: =2D a Hello message MUST contain the router-ID of it's OLSR node as the originator-IP of the message =2D a Hello message CAN include the interface IP of it's OLSR node as an address tagged with LOCAL_IF(THIS_IF). The address can be omitted if the source IP of the package contains the interface IP =2D a Hello message don't need to include other interface IP's of it's OLSR node. If these IP's are included in the message they must be tagged with LOCAL_IF(OTHER_IF) as described in the current draft. =2D all address IPs of 1-hop neighbors in the Hello message will be originator-IPs, tagges as described in OLSRv2 10.1.1 (Page 30). Especially the LINK_STATUS/OTHER_NEIGHB tlv allows to distinguish between 2-hop neighbors on the same interface as the received Hello message and 2-hop neighbors on other interfaces, even if the interface IP's of this nodes are invisible. TC message: =2D a TC message MUST contain the router-ID of it's OLSR node as the originator-IP of the message =2D a TC message MUST contain the originator-IPs of it's advertised neighbor set. Information Bases: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Some of the OLSR information bases that they store the originator-IP instead of the interface IP. The only exception are data for 1-Hop neighbors which will be stored including both IPs. MPR selection =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (I'm referring to appendix B.1. in OLSRv2 page 56) N(I): It's easy to see that N(I) can be calculated from the received Hellos of 1-Hop neighbors. Each OLSR node knowns the originator-IP and the interface IP of it's neighbors. N2(I): The union of all originator-IPs received by Hello messages of members of N(I) Connected to I via Y: same as in OLSRv2 draft 08 D(Y,I): same as in OLSRv2 draft 08 R(Y,I): same as in OLSRv2 draft 08 Routing Metrics with link quality =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D (this applies to OLSR networks sending routing metric data as ETX through the whole topology of the OLSR network) If two OLSR nodes have multiple links between each other just the highest link quality will be included into the TC message. Special routing metrics like MIC might need additional data in the TC entries. Henning Rogge ************************************************* Diplom-Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart65214028.B8M21cGDSr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAknZyQUACgkQRIfGfFXsz+CreACfaO1kU9BITwIEagLYkUSVBtmF gY4AnjPWCi94Qxs/UABfWZA78inC/Ui3 =DDYD -----END PGP SIGNATURE----- --nextPart65214028.B8M21cGDSr-- From chris.dearlove@baesystems.com Mon Apr 6 02:30: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 0C9C528C129 for ; Mon, 6 Apr 2009 02:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.623 X-Spam-Level: X-Spam-Status: No, score=-6.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, 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 NTMVK8O67zZ2 for ; Mon, 6 Apr 2009 02:30:20 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id E9C5E28C126 for ; Mon, 6 Apr 2009 02:30:19 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n369VNMe002294 for ; Mon, 6 Apr 2009 10:31:23 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n369VNZa025775 for ; Mon, 6 Apr 2009 10:31:23 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 10:31:22 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 10:31:22 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Apr 2009 10:31:21 +0100 Message-ID: In-Reply-To: <200904061119.07374.rogge@fgan.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2mMIUYwydlKLuQlqKf2EXIICmbAAAB57w References: <200904061119.07374.rogge@fgan.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" X-OriginalArrivalTime: 06 Apr 2009 09:31:22.0509 (UTC) FILETIME=[72DD3BD0:01C9B69A] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 09:30:21 -0000 > I had some time to look at the MPR calculation in OLSRv2 and I'm still not > convinced that the interface IPs are necessary to calculate routing and > forwarding set. You need (a) All possible IP addresses that may be used as sending addresses of IP datagrams that include e.g. TC messages. (b) Per interface knowledge of which neighbours are reachable, in order that you can determine MPRs (for flooding) per interface (and then form a union of those sets). (c) Routable addresses of neighbours in order to advertise them in TC messages in order that nodes which are not selected as MPRs don't send messages (such as OLSR MID messages) unnecessarily. (d) To handle cases where there may be multiple links, with different characteristics, between the same two nodes. I do not believe any of these alternative proposals handles all of these issues (and others I haven't listed). ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From chris.dearlove@baesystems.com Mon Apr 6 02:54:43 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 8D8F228C119 for ; Mon, 6 Apr 2009 02:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.622 X-Spam-Level: X-Spam-Status: No, score=-6.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, 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 Zq3Vr1PLIfhK for ; Mon, 6 Apr 2009 02:54:34 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id F345128C131 for ; Mon, 6 Apr 2009 02:54:33 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n369tad1013147 for ; Mon, 6 Apr 2009 10:55:36 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n369taek006900 for ; Mon, 6 Apr 2009 10:55:36 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 10:55:36 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 10:55:35 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Apr 2009 10:55:33 +0100 Message-ID: In-Reply-To: <012e01c9b46a$87394420$95abcc60$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm0N723UQGWT281TCyBj9MiXytYlQAAjUqAAAv6rmAAjIGY8A== References: <00c701c9b38e$18e7eb70$4ab7c250$@nl><200904021510.58935.rogge@fgan.de> <200904031039.33788.rogge@fgan.de> <012e01c9b46a$87394420$95abcc60$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Henning Rogge" X-OriginalArrivalTime: 06 Apr 2009 09:55:35.0651 (UTC) FILETIME=[D5011B30:01C9B69D] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 09:54:43 -0000 > Some radio technologies do not have high UDP, IP, MAC & PHY overhead and > each odd octet could be critical. I don't know any system in which all of those overheads aren't such that one's first priority isn't to save messages, the secondly to save message size. Obviously one message ten times the size of two isn't (usually) a win, but one message is significantly cheaper than two that apparently have the same total size (as long as within MTU limits). As for individual octets, well, we fought the fight when creating RFC 5444 between the competing interests of flexibility, efficiency and simplicity. One all three axes we had people wanting to move us from where we ended up in both directions. (Of course no one wanted to move to, for example, less efficient because it was less efficient, but because they wanted it, say, simpler.) The same logic applies to NHDP and OLSRv2. For ultimate every octet is critical design, I think you'll need the ROLL group. Our target has to be reasonable efficiency, while retaining the other characteristics (and some others as well. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Mon Apr 6 03:17:49 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 029493A6C0A for ; Mon, 6 Apr 2009 03:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_05=-1.11, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 Hkac4I3VZ+XO for ; Mon, 6 Apr 2009 03:17:42 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id D8C2B3A697E for ; Mon, 6 Apr 2009 03:17:41 -0700 (PDT) Received: (qmail 8320 invoked from network); 6 Apr 2009 12:18:44 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 6 Apr 2009 12:18:44 +0200 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" References: <00c701c9b38e$18e7eb70$4ab7c250$@nl><200904021510.58935.rogge@fgan.de> <200904031039.33788.rogge@fgan.de> <012e01c9b46a$87394420$95abcc60$@nl> In-Reply-To: Date: Mon, 6 Apr 2009 12:18:14 +0200 Message-ID: <001e01c9b6a1$115569d0$34003d70$@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: Acm0N723UQGWT281TCyBj9MiXytYlQAAjUqAAAv6rmAAjIGY8AAA6YuQ Content-Language: nl Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 10:17:49 -0000 |> Some radio technologies do not have high UDP, IP, MAC & PHY overhead |and |> each odd octet could be critical. | |I don't know any system in which all of those overheads aren't such |that one's first priority isn't to save messages, the secondly to |save message size. Obviously one message ten times the size of two |isn't (usually) a win, but one message is significantly cheaper than |two that apparently have the same total size (as long as within MTU |limits). Not (always) true for TDMA type of radios. For CSMA/CA (with RTS/CTS) without header compression, I agree saving each octet is not the primary goal. The more advanced type of radios do have other media access and support header compression. A single octet could cause usage of another timeslot, causing a lot of overhead (worst case: doubling used bandwidth). |As for individual octets, well, we fought the fight when creating |RFC 5444 between the competing interests of flexibility, efficiency |and simplicity. One all three axes we had people wanting to move us |from where we ended up in both directions. (Of course no one wanted |to move to, for example, less efficient because it was less efficient, |but because they wanted it, say, simpler.) The same logic applies to |NHDP and OLSRv2. For ultimate every octet is critical design, I think |you'll need the ROLL group. Our target has to be reasonable efficiency, |while retaining the other characteristics (and some others as well. In general I agree. Still, I think it is more practical to use a single TLV for a set of fields that are always there, e.g. a hello or tc header. Teco. From Rogge@fgan.de Mon Apr 6 03:37: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 6F61C3A6C2C for ; Mon, 6 Apr 2009 03:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.008 X-Spam-Level: X-Spam-Status: No, score=-6.008 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_EQ_DE=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 jgS8k3hGpZHt for ; Mon, 6 Apr 2009 03:37:08 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 4777C3A6902 for ; Mon, 6 Apr 2009 03:37:08 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1LqmDU-0003Qp-1W; Mon, 06 Apr 2009 12:38:12 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1LqmDT-0001LI-Li; Mon, 06 Apr 2009 12:38:11 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 12:38:11 +0200 From: Henning Rogge To: "Dearlove, Christopher (UK)" Date: Mon, 6 Apr 2009 12:38:06 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.26-1-openvz-686; KDE/4.1.4; i686; ; ) References: <200904061119.07374.rogge@fgan.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart34420063.2k3lZHLhX4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904061238.11268.rogge@fgan.de> X-OriginalArrivalTime: 06 Apr 2009 10:38:11.0687 (UTC) FILETIME=[C8853F70:01C9B6A3] X-Virus-Scanned: yes (ClamAV 0.94.2/9206/Sun Apr 5 20:23:11 2009) by mailguard.fgan.de X-Scan-Signature: 0a4bd1cc3f83d53cde7bef5b38d78774 Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 10:37:09 -0000 --nextPart34420063.2k3lZHLhX4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Monday 06 April 2009 11:31:21 schrieb Dearlove, Christopher (UK): > You need I will compare this list to my recent proposal... > (a) All possible IP addresses that may be used as sending addresses > of IP datagrams that include e.g. TC messages. We are using only the originator IPs for src/dst of unicast messages/routes. Only OLSR broadcast have the interface IP as it's source. So nodes 2 hop away don't need to know about the interface IPs. > (b) Per interface knowledge of which neighbours are reachable, in > order that you can determine MPRs (for flooding) per interface > (and then form a union of those sets). You can read this from the hello packages, all neigbours with LINK_STATUS a= re=20 reachable through "this" interface. No need to send the interface IP of eac= h=20 neighbour. > (c) Routable addresses of neighbours in order to advertise them in > TC messages in order that nodes which are not selected as MPRs > don't send messages (such as OLSR MID messages) unnecessarily. That will be the originator-IPs in my suggestion. Interface IPs will only b= e=20 reachable from one hop distance. > (d) To handle cases where there may be multiple links, with different > characteristics, between the same two nodes. This one is more interesting. In my oppinion there can be only one link between two OLSR nodes for each=20 interface of a receiving node. If this is true the LINK_STATUS/OTHER_NEIGHB= =20 tlvs will help to set the status of multiple links. The LINK_STATUS will te= ll=20 you if the link through THIS interface is symmetric/heared/lost, the=20 OTHER_NEIGHB will tell you if there is a symmetric link through another=20 interface. > I do not believe any of these alternative proposals handles all of > these issues (and others I haven't listed). I think my proposal match all four points you raised. Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart34420063.2k3lZHLhX4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAknZ244ACgkQRIfGfFXsz+AHpACgrp2TyYvXkxlg38lVhBZaKsnT 7osAn0FHUMzplXupJ5HJqM/GodqJHpX0 =FCgu -----END PGP SIGNATURE----- --nextPart34420063.2k3lZHLhX4-- From chris.dearlove@baesystems.com Mon Apr 6 03:46: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 84F3D3A6C2E for ; Mon, 6 Apr 2009 03:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.622 X-Spam-Level: X-Spam-Status: No, score=-6.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, 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 hZKw47gUO5Cj for ; Mon, 6 Apr 2009 03:46:46 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 771E63A6935 for ; Mon, 6 Apr 2009 03:46:46 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36AlnUL025841 for ; Mon, 6 Apr 2009 11:47:50 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36AlnPE008207 for ; Mon, 6 Apr 2009 11:47:49 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 11:47:49 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 11:47:49 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Apr 2009 11:47:48 +0100 Message-ID: In-Reply-To: <200904061238.11268.rogge@fgan.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2o88jOFgU3l/bQGSJuuCy057WNwAAFNmA References: <200904061119.07374.rogge@fgan.de> <200904061238.11268.rogge@fgan.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" X-OriginalArrivalTime: 06 Apr 2009 10:47:49.0351 (UTC) FILETIME=[20D5C770:01C9B6A5] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 10:46:47 -0000 > We are using only the originator IPs for src/dst of unicast messages/routes. > Only OLSR broadcast have the interface IP as it's source. And those are exactly how TC messages are sent, and one reason we need to know all interface addresses. >> I do not believe any of these alternative proposals handles all of >> these issues (and others I haven't listed). > I think my proposal match all four points you raised. I think at the least it misses the point I note above. And that list of four is not exhaustive, it's just the points that I pulled together out of where I've immediately seen proposals fail. ******************************************************************** 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 Rogge@fgan.de Mon Apr 6 03:58:13 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 00DF13A6AD9 for ; Mon, 6 Apr 2009 03:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.048 X-Spam-Level: X-Spam-Status: No, score=-6.048 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HELO_EQ_DE=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 UlOOHKVEA63t for ; Mon, 6 Apr 2009 03:58:05 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 95DA13A6C55 for ; Mon, 6 Apr 2009 03:57:39 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1LqmXL-00041T-Vv; Mon, 06 Apr 2009 12:58:44 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1LqmXL-0001RF-L8; Mon, 06 Apr 2009 12:58:43 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 12:58:43 +0200 From: Henning Rogge To: "Dearlove, Christopher (UK)" Date: Mon, 6 Apr 2009 12:58:37 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.26-1-openvz-686; KDE/4.1.4; i686; ; ) References: <200904061119.07374.rogge@fgan.de> <200904061238.11268.rogge@fgan.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart13045268.J8BKk24DlW"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904061258.43279.rogge@fgan.de> X-OriginalArrivalTime: 06 Apr 2009 10:58:43.0688 (UTC) FILETIME=[A6D9AE80:01C9B6A6] X-Virus-Scanned: yes (ClamAV 0.94.2/9206/Sun Apr 5 20:23:11 2009) by mailguard.fgan.de X-Scan-Signature: 711cfe84e8f62d248cc13f80a51c6aa9 Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 10:58:13 -0000 --nextPart13045268.J8BKk24DlW Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Monday 06 April 2009 12:47:48 schrieb Dearlove, Christopher (UK): > > We are using only the originator IPs for src/dst of unicast > > messages/routes. > > Only OLSR broadcast have the interface IP as it's source. > > And those are exactly how TC messages are sent, and one reason we need > to know all interface addresses. Yes, and each OLSR nodes know this interface IPs from the Hellos of the=20 sending node (TCs from non-symmetric neighbours are dropped). > >> I do not believe any of these alternative proposals handles all of > >> these issues (and others I haven't listed). > > > > I think my proposal match all four points you raised. > > I think at the least it misses the point I note above. I think you forgot about the interface-ip/originator-ip pair each nodes get= =20 through the Hello messages of it's neighbours. Henning ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart13045268.J8BKk24DlW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAknZ4F0ACgkQRIfGfFXsz+DOiACeN08AHtL5zHECJyZXsFUmgFc2 e7UAoIeOBZ/kTSOs2UsaGP0rDf/vKS0U =bDbs -----END PGP SIGNATURE----- --nextPart13045268.J8BKk24DlW-- From chris.dearlove@baesystems.com Mon Apr 6 04:02:29 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 22B7C28C12A for ; Mon, 6 Apr 2009 04:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.621 X-Spam-Level: X-Spam-Status: No, score=-6.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, 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 cTD8-zuusb9M for ; Mon, 6 Apr 2009 04:02:22 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 1D9793A6C42 for ; Mon, 6 Apr 2009 04:02:21 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36B3Qdo011450 for ; Mon, 6 Apr 2009 12:03:26 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36B3QRq017902 for ; Mon, 6 Apr 2009 12:03:26 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 12:03:25 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 12:03:25 +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: Mon, 6 Apr 2009 12:03:24 +0100 Message-ID: In-Reply-To: <200904061258.43279.rogge@fgan.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2prCzgSr+BHV2QauEDJb02sa6uwAADZ9w References: <200904061119.07374.rogge@fgan.de> <200904061238.11268.rogge@fgan.de> <200904061258.43279.rogge@fgan.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" X-OriginalArrivalTime: 06 Apr 2009 11:03:25.0542 (UTC) FILETIME=[4ED93060:01C9B6A7] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 11:02:29 -0000 Only if (but I'm not saying this is a sufficient condition, only that it's a necessary one) we can guarantee that there's only one such address that is always used for all IP datagrams sent on an interface. --=20 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: Henning Rogge [mailto:rogge@fgan.de]=20 Sent: 06 April 2009 11:59 To: Dearlove, Christopher (UK) Cc: Thomas Heide Clausen; manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID Am Monday 06 April 2009 12:47:48 schrieb Dearlove, Christopher (UK): > > We are using only the originator IPs for src/dst of unicast > > messages/routes. > > Only OLSR broadcast have the interface IP as it's source. > > And those are exactly how TC messages are sent, and one reason we need > to know all interface addresses. Yes, and each OLSR nodes know this interface IPs from the Hellos of the=20 sending node (TCs from non-symmetric neighbours are dropped). > >> I do not believe any of these alternative proposals handles all of > >> these issues (and others I haven't listed). > > > > I think my proposal match all four points you raised. > > I think at the least it misses the point I note above. I think you forgot about the interface-ip/originator-ip pair each nodes get= =20 through the Hello messages of it's neighbours. Henning ************************************************* Diplom Informatiker Henning Rogge Forschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 Fax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) ******************************************************************** 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 Rogge@fgan.de Mon Apr 6 04:06:25 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 C273B28C14A for ; Mon, 6 Apr 2009 04:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.077 X-Spam-Level: X-Spam-Status: No, score=-6.077 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HELO_EQ_DE=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 GJLwWY8JZpPD for ; Mon, 6 Apr 2009 04:06:25 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id DE29728C0F5 for ; Mon, 6 Apr 2009 04:06:24 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Lqmfp-0004Ie-72; Mon, 06 Apr 2009 13:07:29 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1Lqmfo-0001Ug-MJ; Mon, 06 Apr 2009 13:07:28 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 13:07:28 +0200 From: Henning Rogge To: "Dearlove, Christopher (UK)" Date: Mon, 6 Apr 2009 13:07:28 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.26-1-openvz-686; KDE/4.1.4; i686; ; ) References: <200904061119.07374.rogge@fgan.de> <200904061258.43279.rogge@fgan.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3077481.TbWizrx0rC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904061307.28277.rogge@fgan.de> X-OriginalArrivalTime: 06 Apr 2009 11:07:28.0779 (UTC) FILETIME=[DFD435B0:01C9B6A7] X-Virus-Scanned: yes (ClamAV 0.94.2/9206/Sun Apr 5 20:23:11 2009) by mailguard.fgan.de X-Scan-Signature: 093a4d18fb20d26714c728ddf8a13ad0 Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 11:06:25 -0000 --nextPart3077481.TbWizrx0rC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Monday 06 April 2009 13:03:24 schrieb Dearlove, Christopher (UK): > Only if (but I'm not saying this is a sufficient condition, > only that it's a necessary one) we can guarantee that there's > only one such address that is always used for all IP datagrams > sent on an interface. If there are multiple interface IPs they can be all included in the Hello=20 message marked with LOCAL_IF(THIS_IF). Of course you can only skip it if th= ere=20 is only one interface IP and it's used in all broadcast datagrams sent from= =20 this interface. But they still don't need to be known more than one hop away. Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart3077481.TbWizrx0rC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAknZ4nAACgkQRIfGfFXsz+DN5wCfVC2JyOkYJLqRa7LDVH1tLf8j UYUAn2ueEO+xNgRK0K4nsmshKQ1CNpaG =IuvK -----END PGP SIGNATURE----- --nextPart3077481.TbWizrx0rC-- From chris.dearlove@baesystems.com Mon Apr 6 04:35: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 E90963A6902 for ; Mon, 6 Apr 2009 04:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.621 X-Spam-Level: X-Spam-Status: No, score=-6.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, 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 Ja5FhL51Yzmy for ; Mon, 6 Apr 2009 04:35:22 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id B0C1E3A6782 for ; Mon, 6 Apr 2009 04:35:21 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36BaOja015874 for ; Mon, 6 Apr 2009 12:36:25 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36BaO9E004435 for ; Mon, 6 Apr 2009 12:36:24 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 12:36:24 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 12:36:23 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Apr 2009 12:36:23 +0100 Message-ID: In-Reply-To: <200904061307.28277.rogge@fgan.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2p+bNhLg/G7r2RRiqpeNQRu+viwAAtuVg References: <200904061119.07374.rogge@fgan.de> <200904061258.43279.rogge@fgan.de> <200904061307.28277.rogge@fgan.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" X-OriginalArrivalTime: 06 Apr 2009 11:36:24.0120 (UTC) FILETIME=[EA2C3B80:01C9B6AB] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 11:35:23 -0000 > If there are multiple interface IPs they can be all included in the Hello=20 > message marked with LOCAL_IF(THIS_IF). Now you're including IP addresses and interface IDs in HELLO messages, Not good. ******************************************************************** 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 Rogge@fgan.de Mon Apr 6 04:43:25 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 84DA33A6782 for ; Mon, 6 Apr 2009 04:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_DE=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 GntCzZZZwSki for ; Mon, 6 Apr 2009 04:43:18 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id E654F3A6B65 for ; Mon, 6 Apr 2009 04:43:17 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1LqnFW-0005Na-Am; Mon, 06 Apr 2009 13:44:22 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1LqnFV-0001iQ-W9; Mon, 06 Apr 2009 13:44:22 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 13:44:22 +0200 From: Henning Rogge To: "Dearlove, Christopher (UK)" Date: Mon, 6 Apr 2009 13:44:16 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.26-1-openvz-686; KDE/4.1.4; i686; ; ) References: <200904061119.07374.rogge@fgan.de> <200904061307.28277.rogge@fgan.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1622631.SE0CHn9gl4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904061344.21632.rogge@fgan.de> X-OriginalArrivalTime: 06 Apr 2009 11:44:22.0101 (UTC) FILETIME=[07125850:01C9B6AD] X-Virus-Scanned: yes (ClamAV 0.94.2/9206/Sun Apr 5 20:23:11 2009) by mailguard.fgan.de X-Scan-Signature: c5b001ed8a32557dab9f13d2bf4e6284 Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 11:43:25 -0000 --nextPart1622631.SE0CHn9gl4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Monday 06 April 2009 13:36:23 schrieb Dearlove, Christopher (UK): > > If there are multiple interface IPs they can be all included in the > > message marked with LOCAL_IF(THIS_IF). > > Now you're including IP addresses and interface IDs > in HELLO messages interface IDs =3D router-id =3D originator-IP ? =46rom my first email today: =2D a Hello message MUST contain the router-ID of it's OLSR node as the =A0 originator-IP of the message =2D a Hello message CAN include the interface IP of it's OLSR node as an =A0 address tagged with LOCAL_IF(THIS_IF). The address can be omitted if =A0 the source IP of the package contains the interface IP So yes, the Hello messages contain both the public/netwide IP of the router= =20 (the originator-ip), the (optional) the linklocal/interface IPs of the rout= er=20 and the public IPs of it's neighbors. Should be pretty straight forward because Hellos are TTL 1 messages, so=20 linklocal IPs ARE routable IPs in this scope. > , Not good. Thats similar how it's done in NHDP now. But you can skip the interface IP = if=20 this interface has only one and it is contained in the source of the ip- datagram. Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart1622631.SE0CHn9gl4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAknZ6xAACgkQRIfGfFXsz+BN2gCeMkqn/mXmq5yPpE1bseT+dv0q xmgAoIDRXSAE5l91BoykwYPSScj6Gpmm =tlvK -----END PGP SIGNATURE----- --nextPart1622631.SE0CHn9gl4-- From chris.dearlove@baesystems.com Mon Apr 6 04:50:51 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 71AD23A69E8 for ; Mon, 6 Apr 2009 04:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.62 X-Spam-Level: X-Spam-Status: No, score=-6.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, 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 OC4thJkQ7LvA for ; Mon, 6 Apr 2009 04:50:50 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 7556E3A69CC for ; Mon, 6 Apr 2009 04:50:50 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36BpsGN028493 for ; Mon, 6 Apr 2009 12:51:54 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36BpseX012037 for ; Mon, 6 Apr 2009 12:51:54 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 12:51:53 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 12:51:53 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Apr 2009 12:51:52 +0100 Message-ID: In-Reply-To: <200904061344.21632.rogge@fgan.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2rRROtRVFdgOJRXm3SX81uu23EgAADeBA References: <200904061119.07374.rogge@fgan.de> <200904061307.28277.rogge@fgan.de> <200904061344.21632.rogge@fgan.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" X-OriginalArrivalTime: 06 Apr 2009 11:51:53.0636 (UTC) FILETIME=[14351E40:01C9B6AE] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 11:50:51 -0000 > Thats similar how it's done in NHDP now. No. Right now the addresses in NHDP within OLSRv2 do three jobs - interface identification for two hop set formation, knowledge of possible TC sending address and addresses to route to. In the simplest cases that gets efficiency because even if interface IDs could be smaller than addresses, you need the addresses anyway (and they may be compressed). The place you may lose efficiency is in some unnecessary inclusion in TC messages, but that can be addressed with permission to exclude/aggregate. (And we have to revise OLSRv2 anyway, for metrics, so that's not a significant deal.) ******************************************************************** 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 Rogge@fgan.de Mon Apr 6 05:10:29 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 3573C3A6AC8 for ; Mon, 6 Apr 2009 05:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.115 X-Spam-Level: X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_DE=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 5K37jgCtTQMB for ; Mon, 6 Apr 2009 05:10:21 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 544803A698F for ; Mon, 6 Apr 2009 05:10:18 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Lqnfe-0006Bp-P4; Mon, 06 Apr 2009 14:11:22 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1Lqnfe-0001s2-BY; Mon, 06 Apr 2009 14:11:22 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 14:11:22 +0200 From: Henning Rogge To: "Dearlove, Christopher (UK)" Date: Mon, 6 Apr 2009 14:11:11 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.26-1-openvz-686; KDE/4.1.4; i686; ; ) References: <200904061119.07374.rogge@fgan.de> <200904061344.21632.rogge@fgan.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2081892.7TEzPi5nGm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904061411.16983.rogge@fgan.de> X-OriginalArrivalTime: 06 Apr 2009 12:11:22.0487 (UTC) FILETIME=[CCE5A070:01C9B6B0] X-Virus-Scanned: yes (ClamAV 0.94.2/9206/Sun Apr 5 20:23:11 2009) by mailguard.fgan.de X-Scan-Signature: 1e9a6bb74562192ca4a04316780810e4 Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 12:10:29 -0000 --nextPart2081892.7TEzPi5nGm Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Monday 06 April 2009 13:51:52 schrieb Dearlove, Christopher (UK): > > Thats similar how it's done in NHDP now. > > No. Right now the addresses in NHDP within OLSRv2 do three jobs > - interface identification for two hop set formation, knowledge > of possible TC sending address and addresses to route to. In the > simplest cases that gets efficiency because even if interface IDs > could be smaller than addresses, you need the addresses anyway > (and they may be compressed). Yes, in the trivial case my suggestion would always include the originator-= IP=20 into the message while NHDP could skip it. > The place you may lose efficiency > is in some unnecessary inclusion in TC messages, but that can be > addressed with permission to exclude/aggregate. (And we have to > revise OLSRv2 anyway, for metrics, so that's not a significant > deal.) In my experience there are a LOT more TCs in most OLSR networks than Hellos= ,=20 especially in large networks. So the current draft will be a little bit more efficient in Hellos because = my=20 suggestion have to include the originator-IP into it, but it will be as=20 efficient as the current draft for "single interface" TCs and more efficien= t=20 for "multi-interface" TCs. So (if we ignore the whole efficiency stuff) I managed to convinced you tha= t=20 my proposal does work and sattisfy the requirements for correct MPR selecti= on? Henning ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart2081892.7TEzPi5nGm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAknZ8V8ACgkQRIfGfFXsz+CdqACffBcUlOPO9Vhlhh64EvxKUSR4 5dIAnijVc8qN0xVjBJuhhQds5m7+7wEG =GXoC -----END PGP SIGNATURE----- --nextPart2081892.7TEzPi5nGm-- From chris.dearlove@baesystems.com Mon Apr 6 05:30:27 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 49F543A6C4D for ; Mon, 6 Apr 2009 05:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.62 X-Spam-Level: X-Spam-Status: No, score=-6.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, 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 yCWxvQ+88Wfw for ; Mon, 6 Apr 2009 05:30:21 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id CC75B3A6C0A for ; Mon, 6 Apr 2009 05:30:20 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36CVOuB005819 for ; Mon, 6 Apr 2009 13:31:24 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36CVOrr011020 for ; Mon, 6 Apr 2009 13:31:24 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 13:31:24 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 13:31:24 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Apr 2009 13:31:23 +0100 Message-ID: In-Reply-To: <200904061411.16983.rogge@fgan.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2sNLozuueL3KOSgGSL7A30apWUgAAMn6g References: <200904061119.07374.rogge@fgan.de> <200904061344.21632.rogge@fgan.de> <200904061411.16983.rogge@fgan.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" X-OriginalArrivalTime: 06 Apr 2009 12:31:24.0167 (UTC) FILETIME=[99277170:01C9B6B3] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 12:30:27 -0000 > So the current draft will be a little bit more efficient in Hellos because my=20 > suggestion have to include the originator-IP into it, but it will be as=20 > efficient as the current draft for "single interface" TCs and more efficient=20 > for "multi-interface" TCs. No, I don't believe that is the case either. TCs need to include all routable IP addresses, however you do it. We can give permission to drop the unneeded ones without introducing router IDs etc. You can't just include router IDs in TC messages without reintroducing something like a MID message. And in OLSRv1, if all nodes have multiple addresses you send more MID messages than TC messages. > So (if we ignore the whole efficiency stuff) I managed to convinced you that=20 > my proposal does work and sattisfy the requirements for correct MPR selection? No. I haven't said that anywhere, in fact I've carefully pointed out to the contrary in just about every posting (that although the four points I made are important, they aren't all). And there are several of other points (such as multiple link relationships) that I haven't followed up on disagreement. But, I will note that even today's proposal you've had to modify. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Mon Apr 6 05:35:30 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 7A9653A6C53 for ; Mon, 6 Apr 2009 05:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.655 X-Spam-Level: X-Spam-Status: No, score=-0.655 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 m96KY3YCWrsx for ; Mon, 6 Apr 2009 05:35:29 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id DA1123A6BFA for ; Mon, 6 Apr 2009 05:35:28 -0700 (PDT) Received: (qmail 21070 invoked from network); 6 Apr 2009 14:36:32 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 6 Apr 2009 14:36:32 +0200 From: "Teco Boot" To: "'Henning Rogge'" , "'Dearlove, Christopher \(UK\)'" References: <200904061119.07374.rogge@fgan.de> In-Reply-To: <200904061119.07374.rogge@fgan.de> Date: Mon, 6 Apr 2009 14:36:02 +0200 Message-ID: <004501c9b6b4$515986c0$f40c9440$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm2mPd5GflogV5vRCux1vbGasUsfwAGS/DA Content-Language: nl Cc: manet@ietf.org, 'Thomas Heide Clausen' Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 12:35:30 -0000 Agreed with approach, it is in line with mine. Inline some additional comments. Teco. |Van: |Henning Rogge | |I had some time to look at the MPR calculation in OLSRv2 and I'm still |not |convinced that the interface IPs are necessary to calculate routing and |forwarding set. So I try to explain our (Markus Kittenberg from Vienna |and |me) concept a little bit more. | |Even if it's too late to include this into the main OLSRv2 RFCs=20 Maybe it is late, but not too late. There is no OLSRv2 RFC yet. | I will |continue to work on the concept to see if it can be done correctly |because |I think it's a good idea to allow an easier use of linklocal addresses |and |handling of dynamic interfaces. | |The router-id of a node should be a FIXED IP address which does not |change. | |The base of the concept is that there should be no change in packet |format, |just a change what kind of IP will be written into Hello/TC messages. Yes, but we could decide to reduce complexity of the messages, if we = want to. |OLSRv2/NHDP messages changes |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D | |Hellomessages: | |- a Hello message MUST contain the router-ID of it's OLSR node as the | originator-IP of the message |- a Hello message CAN include the interface IP of it's OLSR node as an | address tagged with LOCAL_IF(THIS_IF). The address can be omitted if | the source IP of the package contains the interface IP |- a Hello message don't need to include other interface IP's of it's | OLSR node. If these IP's are included in the message they must be | tagged with LOCAL_IF(OTHER_IF) as described in the current draft. |- all address IPs of 1-hop neighbors in the Hello message will be | originator-IPs, tagges as described in OLSRv2 10.1.1 (Page 30). | Especially the LINK_STATUS/OTHER_NEIGHB tlv allows to distinguish | between 2-hop neighbors on the same interface as the received | Hello message and 2-hop neighbors on other interfaces, even if | the interface IP's of this nodes are invisible. | |TC message: | |- a TC message MUST contain the router-ID of it's OLSR node as the | originator-IP of the message |- a TC message MUST contain the originator-IPs of it's advertised | neighbor set. | | |Information Bases: |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | |Some of the OLSR information bases that they store the originator-IP |instead of the interface IP. The only exception are data for 1-Hop |neighbors which will be stored including both IPs. Or another identifier for the interface, e.g. ifIndex. Note that LLs for VLANs typically have the same IPv6 LL address, because they share the same MAC address. The interface ID is local only, it is not sent to other nodes. |MPR selection |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |(I'm referring to appendix B.1. in OLSRv2 page 56) | |N(I): | It's easy to see that N(I) can be calculated from the received Hellos |of | 1-Hop neighbors. Each OLSR node knowns the originator-IP and the |interface | IP of it's neighbors. | |N2(I): | The union of all originator-IPs received by Hello messages of members | of N(I) | |Connected to I via Y: | same as in OLSRv2 draft 08 | |D(Y,I): | same as in OLSRv2 draft 08 | |R(Y,I): | same as in OLSRv2 draft 08 | | |Routing Metrics with link quality |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D |(this applies to OLSR networks sending routing metric data as ETX |through |the whole topology of the OLSR network) | |If two OLSR nodes have multiple links between each other just the |highest |link quality will be included into the TC message. Special routing |metrics |like MIC might need additional data in the TC entries. | |Henning Rogge | | |************************************************* |Diplom-Informatiker Henning Rogge |Forschungsgesellschaft f=FCr |Angewandte Naturwissenschaften e. V. (FGAN) |Neuenahrer Str. 20, 53343 Wachtberg, Germany |Tel.: 0049 (0)228 9435-961 |Fax: 0049 (0)228 9435-685 |E-Mail: rogge@fgan.de |Web: www.fgan.de |************************************************ |Sitz der Gesellschaft: Bonn |Registergericht: Amtsgericht Bonn VR 2530 |Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. = Dr.-Ing. |Joachim Ender (Stellv.) From Rogge@fgan.de Mon Apr 6 05:46: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 6EEBE3A6979 for ; Mon, 6 Apr 2009 05:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_DE=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 ucVDHu1TbHPF for ; Mon, 6 Apr 2009 05:46:11 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id C14C028C14A for ; Mon, 6 Apr 2009 05:46:11 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1LqoEO-0007D8-39; Mon, 06 Apr 2009 14:47:16 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1LqoEN-00024B-OP; Mon, 06 Apr 2009 14:47:15 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 14:47:15 +0200 From: Henning Rogge To: "Teco Boot" Date: Mon, 6 Apr 2009 14:47:15 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.26-1-openvz-686; KDE/4.1.4; i686; ; ) References: <200904061119.07374.rogge@fgan.de> <004501c9b6b4$515986c0$f40c9440$@nl> In-Reply-To: <004501c9b6b4$515986c0$f40c9440$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2088895.FaoRh5FtBy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904061447.15372.rogge@fgan.de> X-OriginalArrivalTime: 06 Apr 2009 12:47:15.0655 (UTC) FILETIME=[D048FD70:01C9B6B5] X-Virus-Scanned: yes (ClamAV 0.94.2/9207/Mon Apr 6 13:58:21 2009) by mailguard.fgan.de X-Scan-Signature: 0f287e88b12fb29766ba98e7b870a51f Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org, 'Thomas Heide Clausen' Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 12:46:19 -0000 --nextPart2088895.FaoRh5FtBy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Monday 06 April 2009 14:36:02 schrieb Teco Boot: > |Information Bases: > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | > |Some of the OLSR information bases that they store the originator-IP > |instead of the interface IP. The only exception are data for 1-Hop > |neighbors which will be stored including both IPs. > > Or another identifier for the interface, e.g. ifIndex. > Note that LLs for VLANs typically have the same IPv6 LL address, because > they share the same MAC address. > The interface ID is local only, it is not sent to other nodes. I remember that LLs contain a 16 Bit random number, that should give the tw= o=20 VLANs the same LL ? Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart2088895.FaoRh5FtBy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAknZ+dMACgkQRIfGfFXsz+AkeQCfS1dWmMZZo2MBAgXYZ7u7ztKo UmQAn2oPxxilr9+bs7QltlFkvbFoFo3q =Bmgj -----END PGP SIGNATURE----- --nextPart2088895.FaoRh5FtBy-- From teco@inf-net.nl Mon Apr 6 05:59:27 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 EC0513A6C61 for ; Mon, 6 Apr 2009 05:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 167hajPVmd4y for ; Mon, 6 Apr 2009 05:59:22 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 981B83A6C2E for ; Mon, 6 Apr 2009 05:59:21 -0700 (PDT) Received: (qmail 11891 invoked from network); 6 Apr 2009 15:00:24 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 6 Apr 2009 15:00:24 +0200 From: "Teco Boot" To: "'Henning Rogge'" , "'Dearlove, Christopher \(UK\)'" References: <200904061119.07374.rogge@fgan.de> <200904061238.11268.rogge@fgan.de> In-Reply-To: <200904061238.11268.rogge@fgan.de> Date: Mon, 6 Apr 2009 14:59:51 +0200 Message-ID: <004a01c9b6b7$a6d30f10$f4792d30$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm2o/v3Ek2J9ICURrCImmUk5Fx3hQAETmNw Content-Language: nl Cc: manet@ietf.org, 'Thomas Heide Clausen' Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 12:59:28 -0000 |> You need |I will compare this list to my recent proposal... | |> (a) All possible IP addresses that may be used as sending addresses |> of IP datagrams that include e.g. TC messages. |We are using only the originator IPs for src/dst of unicast |messages/routes. |Only OLSR broadcast have the interface IP as it's source. | |So nodes 2 hop away don't need to know about the interface IPs. There is no reason not using the RouterID for other purposes. Agreed on that all NHDP/OLSRv2 messages use RouterID as source address. |> (b) Per interface knowledge of which neighbours are reachable, in |> order that you can determine MPRs (for flooding) per interface |> (and then form a union of those sets). |You can read this from the hello packages, all neigbours with |LINK_STATUS are |reachable through "this" interface. No need to send the interface IP of |each neighbour. Agreed. |> (c) Routable addresses of neighbours in order to advertise them in |> TC messages in order that nodes which are not selected as MPRs |> don't send messages (such as OLSR MID messages) unnecessarily. |That will be the originator-IPs in my suggestion. Interface IPs will |only be reachable from one hop distance. Agreed. |> (d) To handle cases where there may be multiple links, with different |> characteristics, between the same two nodes. |This one is more interesting. | |In my opinion there can be only one link between two OLSR nodes for |each interface of a receiving node. If this is true the |LINK_STATUS/OTHER_NEIGHB |tlvs will help to set the status of multiple links. The LINK_STATUS = will |tell |you if the link through THIS interface is symmetric/heared/lost, the |OTHER_NEIGHB will tell you if there is a symmetric link through another |interface. We come from min_hop Dijkstra. Multiple topology routing is the other = end of the spectrum. For what we need right now, only the link with the lowest = cost is of interest. It will do advertizing only that one. |> I do not believe any of these alternative proposals handles all of |> these issues (and others I haven't listed). |I think my proposal match all four points you raised. Agreed. Teco. |Henning Rogge | |************************************************* |Diplom Informatiker Henning Rogge |Forschungsgesellschaft f=FCr |Angewandte Naturwissenschaften e. V. (FGAN) |Neuenahrer Str. 20, 53343 Wachtberg, Germany |Tel.: 0049 (0)228 9435-961 |Fax: 0049 (0)228 9435-685 |E-Mail: rogge@fgan.de |Web: www.fgan.de |************************************************ |Sitz der Gesellschaft: Bonn |Registergericht: Amtsgericht Bonn VR 2530 |Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. = Dr.-Ing. |Joachim Ender (Stellv.) From chris.dearlove@baesystems.com Mon Apr 6 06:05: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 38D4C3A6C2C for ; Mon, 6 Apr 2009 06:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.619 X-Spam-Level: X-Spam-Status: No, score=-6.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, 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 UtjYDFnDf2zF for ; Mon, 6 Apr 2009 06:05:55 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 3DEB13A6C0A for ; Mon, 6 Apr 2009 06:05:55 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36D6xXX026697 for ; Mon, 6 Apr 2009 14:06:59 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36D6xMm022368 for ; Mon, 6 Apr 2009 14:06:59 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 14:06:58 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 14:06:58 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Apr 2009 14:06:58 +0100 Message-ID: In-Reply-To: <004a01c9b6b7$a6d30f10$f4792d30$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2o/v3Ek2J9ICURrCImmUk5Fx3hQAETmNwAACmy3A= References: <200904061119.07374.rogge@fgan.de> <200904061238.11268.rogge@fgan.de> <004a01c9b6b7$a6d30f10$f4792d30$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Henning Rogge" X-OriginalArrivalTime: 06 Apr 2009 13:06:58.0655 (UTC) FILETIME=[916876F0:01C9B6B8] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 13:05:56 -0000 >|Only OLSR broadcast have the interface IP as it's source. > Agreed on that all NHDP/OLSRv2 messages use RouterID as source address. That isn't agreement. Henning pointed out that OLSR broadcasts will use interface IP as source address, which is correct. Using Router ID is different, and not what will happen. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Mon Apr 6 06:06:18 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 99DB628C184 for ; Mon, 6 Apr 2009 06:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 pUaulvBt47w7 for ; Mon, 6 Apr 2009 06:06:12 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 4FB5928C178 for ; Mon, 6 Apr 2009 06:06:12 -0700 (PDT) Received: (qmail 17684 invoked from network); 6 Apr 2009 15:07:16 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 6 Apr 2009 15:07:16 +0200 From: "Teco Boot" To: "'Henning Rogge'" , "'Dearlove, Christopher \(UK\)'" References: <200904061119.07374.rogge@fgan.de> <200904061307.28277.rogge@fgan.de> <200904061344.21632.rogge@fgan.de> In-Reply-To: <200904061344.21632.rogge@fgan.de> Date: Mon, 6 Apr 2009 15:06:46 +0200 Message-ID: <004b01c9b6b8$9c7c7690$d57563b0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm2rRoVOg5N1PVST6qKw52Dgt3a1AACyP6w Content-Language: nl Cc: manet@ietf.org, 'Thomas Heide Clausen' Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 13:06:18 -0000 Not sure what this discussion is about. Is it L2 to L2 address mapping? This needs some words, e.g. using ip unnumbered or proxy-arp. If not, what is the problem? Teco. |-----Oorspronkelijk bericht----- |Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens |Henning Rogge |Verzonden: maandag 6 april 2009 13:44 |Aan: Dearlove, Christopher (UK) |CC: manet@ietf.org; Thomas Heide Clausen |Onderwerp: Re: [manet] OLSRv2 - RouterID | |Am Monday 06 April 2009 13:36:23 schrieb Dearlove, Christopher (UK): |> > If there are multiple interface IPs they can be all included in the |> > message marked with LOCAL_IF(THIS_IF). |> |> Now you're including IP addresses and interface IDs |> in HELLO messages | |interface IDs =3D router-id =3D originator-IP ? | |From my first email today: |- a Hello message MUST contain the router-ID of it's OLSR node as the |=A0 originator-IP of the message |- a Hello message CAN include the interface IP of it's OLSR node as an |=A0 address tagged with LOCAL_IF(THIS_IF). The address can be omitted = if |=A0 the source IP of the package contains the interface IP | |So yes, the Hello messages contain both the public/netwide IP of the |router |(the originator-ip), the (optional) the linklocal/interface IPs of the |router |and the public IPs of it's neighbors. | |Should be pretty straight forward because Hellos are TTL 1 messages, so |linklocal IPs ARE routable IPs in this scope. | |> , Not good. | |Thats similar how it's done in NHDP now. But you can skip the interface |IP if |this interface has only one and it is contained in the source of the = ip- |datagram. | |Henning Rogge | |************************************************* |Diplom Informatiker Henning Rogge |Forschungsgesellschaft f=FCr |Angewandte Naturwissenschaften e. V. (FGAN) |Neuenahrer Str. 20, 53343 Wachtberg, Germany |Tel.: 0049 (0)228 9435-961 |Fax: 0049 (0)228 9435-685 |E-Mail: rogge@fgan.de |Web: www.fgan.de |************************************************ |Sitz der Gesellschaft: Bonn |Registergericht: Amtsgericht Bonn VR 2530 |Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. = Dr.-Ing. |Joachim Ender (Stellv.) From Rogge@fgan.de Mon Apr 6 06:11:33 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 5D5363A68DE for ; Mon, 6 Apr 2009 06:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.139 X-Spam-Level: X-Spam-Status: No, score=-6.139 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HELO_EQ_DE=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 y01K12GGDOzD for ; Mon, 6 Apr 2009 06:11:32 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 451E53A6930 for ; Mon, 6 Apr 2009 06:11:32 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Lqocu-0007wh-OG; Mon, 06 Apr 2009 15:12:36 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1Lqocu-0002DP-DL; Mon, 06 Apr 2009 15:12:36 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 15:12:36 +0200 From: Henning Rogge To: "Dearlove, Christopher (UK)" Date: Mon, 6 Apr 2009 15:12:30 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.28.1; KDE/4.1.4; i686; ; ) References: <200904061119.07374.rogge@fgan.de> <004a01c9b6b7$a6d30f10$f4792d30$@nl> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5231119.Q4oKkfAYVr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904061512.35997.rogge@fgan.de> X-OriginalArrivalTime: 06 Apr 2009 13:12:36.0318 (UTC) FILETIME=[5AABBFE0:01C9B6B9] X-Virus-Scanned: yes (ClamAV 0.94.2/9207/Mon Apr 6 13:58:21 2009) by mailguard.fgan.de X-Scan-Signature: 1898d222f6d189e5ce4a9c9e6636a2d2 Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 13:11:33 -0000 --nextPart5231119.Q4oKkfAYVr Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Monday 06 April 2009 15:06:58 schrieb Dearlove, Christopher (UK): > >|Only OLSR broadcast have the interface IP as it's source. > > > > Agreed on that all NHDP/OLSRv2 messages use RouterID as source > > address. > > That isn't agreement. Henning pointed out that OLSR > broadcasts will use interface IP as source address, > which is correct. Using Router ID is different, and > not what will happen. Yes, I'm thinking of OLSR packets as "linklocal" packages (they only travel= on=20 hop away to the next OLSR instance), so they should always have the linkloc= al=20 source IP. Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart5231119.Q4oKkfAYVr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAknZ/74ACgkQRIfGfFXsz+DoTwCfe1lvTwXdBUDhdnp5a+dt6acG DoYAniEq7ELorzvEpFQ5IaYybGscgdVj =52H/ -----END PGP SIGNATURE----- --nextPart5231119.Q4oKkfAYVr-- From teco@inf-net.nl Mon Apr 6 06:24: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 C2D5F3A6C74 for ; Mon, 6 Apr 2009 06:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.973 X-Spam-Level: X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 8iIovi1lZ7Ge for ; Mon, 6 Apr 2009 06:24:30 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 7517D3A6C73 for ; Mon, 6 Apr 2009 06:24:29 -0700 (PDT) Received: (qmail 1056 invoked from network); 6 Apr 2009 15:25:32 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 6 Apr 2009 15:25:32 +0200 From: "Teco Boot" To: "'Henning Rogge'" References: <200904061119.07374.rogge@fgan.de> <004501c9b6b4$515986c0$f40c9440$@nl> <200904061447.15372.rogge@fgan.de> In-Reply-To: <200904061447.15372.rogge@fgan.de> Date: Mon, 6 Apr 2009 15:25:03 +0200 Message-ID: <005301c9b6bb$2a23ab10$7e6b0130$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm2tfVyoTaRtb02QEivO8fFr6Nq/AABF8rg Content-Language: nl Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org, 'Thomas Heide Clausen' Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 13:24:31 -0000 |> |Information Bases: |> |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |> | |> |Some of the OLSR information bases that they store the originator-IP |> |instead of the interface IP. The only exception are data for 1-Hop |> |neighbors which will be stored including both IPs. |> |> Or another identifier for the interface, e.g. ifIndex. |> Note that LLs for VLANs typically have the same IPv6 LL address, |because |> they share the same MAC address. |> The interface ID is local only, it is not sent to other nodes. |I remember that LLs contain a 16 Bit random number, that should give = the |two VLANs the same LL ? The 16-bit is for IPv4. IPv4 LLs on routers is not used today. However, = we can think about it. IPv6 LLs on routers are mandatory (ND, RFC4861 page 9). Often, EUI-64 interface IDs are used. Those are composed from the L2 address, and on = each VLAN on a single physical port, the L2 MAC address is re-used and thus = the IPv6 LLs are the same for each VLAN. This is no problem, as VLAN equals link, and MAC addresses are globally unique (if you buy stuff from a respected vendor..). Teco. |Henning Rogge | |************************************************* |Diplom Informatiker Henning Rogge |Forschungsgesellschaft f=FCr |Angewandte Naturwissenschaften e. V. (FGAN) |Neuenahrer Str. 20, 53343 Wachtberg, Germany |Tel.: 0049 (0)228 9435-961 |Fax: 0049 (0)228 9435-685 |E-Mail: rogge@fgan.de |Web: www.fgan.de |************************************************ |Sitz der Gesellschaft: Bonn |Registergericht: Amtsgericht Bonn VR 2530 |Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. = Dr.-Ing. |Joachim Ender (Stellv.) From chris.dearlove@baesystems.com Mon Apr 6 06:26:07 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 049BE3A6B04 for ; Mon, 6 Apr 2009 06:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.619 X-Spam-Level: X-Spam-Status: No, score=-6.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, 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 Jccc-QYieHiH for ; Mon, 6 Apr 2009 06:26:06 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 04AFA28C186 for ; Mon, 6 Apr 2009 06:25:56 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36DR1ts004790 for ; Mon, 6 Apr 2009 14:27:01 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36DR0NX013904 for ; Mon, 6 Apr 2009 14:27:00 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 14:26:52 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 14:26:21 +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: Mon, 6 Apr 2009 14:26:21 +0100 Message-ID: In-Reply-To: <200904061512.35997.rogge@fgan.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2uV/52Vwoae2SQF6X9E7hrt5aOwAABbNw References: <200904061119.07374.rogge@fgan.de> <004a01c9b6b7$a6d30f10$f4792d30$@nl> <200904061512.35997.rogge@fgan.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" X-OriginalArrivalTime: 06 Apr 2009 13:26:21.0912 (UTC) FILETIME=[46C36580:01C9B6BB] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 13:26:07 -0000 There's nothing in NHDP that makes you use linklocal addresses. But there's nothing that stops you. Yes, you use those link local addresses further away (in NHDP two hops away). I will note that as far as I could tell most of the members of the autoconf Design Team seemed happy to use a MANET interface address with a MANET-wide scope. (The MANET WG has ducked every time it's been suggested to ask IANA for a specific MANET-scoped address however.) But, if using link local addresses, you can't stop those link local addresses being seen two hops away. And it is essential (in NHDP) that they are unique up to two hops (not just one) away, as that's how symmetry advertisement in HELLO messages works. And once they are visible, have to be inspected, and have to be unique two hops away, putting them in Information Bases is not adding any new problems. --=20 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: Henning Rogge [mailto:rogge@fgan.de]=20 Sent: 06 April 2009 14:13 To: Dearlove, Christopher (UK) Cc: Teco Boot; manet@ietf.org; Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID Am Monday 06 April 2009 15:06:58 schrieb Dearlove, Christopher (UK): > >|Only OLSR broadcast have the interface IP as it's source. > > > > Agreed on that all NHDP/OLSRv2 messages use RouterID as source > > address. > > That isn't agreement. Henning pointed out that OLSR > broadcasts will use interface IP as source address, > which is correct. Using Router ID is different, and > not what will happen. Yes, I'm thinking of OLSR packets as "linklocal" packages (they only travel= on=20 hop away to the next OLSR instance), so they should always have the= linklocal=20 source IP. Henning Rogge ************************************************* Diplom Informatiker Henning Rogge Forschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 Fax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Mon Apr 6 06:37:27 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 6F05628C164 for ; Mon, 6 Apr 2009 06:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.032 X-Spam-Level: X-Spam-Status: No, score=-1.032 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 tWIJ+WR1q73R for ; Mon, 6 Apr 2009 06:37:26 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 4808628C14F for ; Mon, 6 Apr 2009 06:37:26 -0700 (PDT) Received: (qmail 14144 invoked from network); 6 Apr 2009 15:38:30 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 6 Apr 2009 15:38:30 +0200 From: "Teco Boot" To: "'Henning Rogge'" , "'Dearlove, Christopher \(UK\)'" References: <200904061119.07374.rogge@fgan.de> <004a01c9b6b7$a6d30f10$f4792d30$@nl> <200904061512.35997.rogge@fgan.de> In-Reply-To: <200904061512.35997.rogge@fgan.de> Date: Mon, 6 Apr 2009 15:38:00 +0200 Message-ID: <005701c9b6bc$f96dcf80$ec496e80$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm2uYAIyhyUDdueSaqH6hgAWmwUsAAAceAA Content-Language: nl Cc: manet@ietf.org, 'Thomas Heide Clausen' Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 13:37:27 -0000 |> >|Only OLSR broadcast have the interface IP as it's source. |> > |> > Agreed on that all NHDP/OLSRv2 messages use RouterID as source |> |> address. |> |> That isn't agreement. Henning pointed out that OLSR |> broadcasts will use interface IP as source address, |> which is correct. Using Router ID is different, and |> not what will happen. | |Yes, I'm thinking of OLSR packets as "linklocal" packages (they only |travel on |hop away to the next OLSR instance), so they should always have the |linklocal |source IP. OK, we can discuss this "minor detail" later. I originally suggested usage of LLs (see Autoconf PPT last IETF). Using the RouterID as source address eliminates sending the = msg-orig-addr in hellos. It is more in line with Thomas his "practical addressing = proposal" using unique host prefixes on MANET interfaces. It introduces the requirement for L3 to L2 mapping (solvable). Teco. | |Henning Rogge | |************************************************* |Diplom Informatiker Henning Rogge |Forschungsgesellschaft f=FCr |Angewandte Naturwissenschaften e. V. (FGAN) |Neuenahrer Str. 20, 53343 Wachtberg, Germany |Tel.: 0049 (0)228 9435-961 |Fax: 0049 (0)228 9435-685 |E-Mail: rogge@fgan.de |Web: www.fgan.de |************************************************ |Sitz der Gesellschaft: Bonn |Registergericht: Amtsgericht Bonn VR 2530 |Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. = Dr.-Ing. |Joachim Ender (Stellv.) From chris.dearlove@baesystems.com Mon Apr 6 06:43:53 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 DF2363A6C67 for ; Mon, 6 Apr 2009 06:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.618 X-Spam-Level: X-Spam-Status: No, score=-6.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, 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 CwNnDSPD562c for ; Mon, 6 Apr 2009 06:43:53 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id DE5A23A698F for ; Mon, 6 Apr 2009 06:43:52 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36DiugJ012156 for ; Mon, 6 Apr 2009 14:44:56 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36Diu5B026290 for ; Mon, 6 Apr 2009 14:44:56 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 14:44:56 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 14:44:56 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Apr 2009 14:44:54 +0100 Message-ID: In-Reply-To: <005701c9b6bc$f96dcf80$ec496e80$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2uYAIyhyUDdueSaqH6hgAWmwUsAAAceAAAAB1UUA= References: <200904061119.07374.rogge@fgan.de> <004a01c9b6b7$a6d30f10$f4792d30$@nl> <200904061512.35997.rogge@fgan.de> <005701c9b6bc$f96dcf80$ec496e80$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Henning Rogge" X-OriginalArrivalTime: 06 Apr 2009 13:44:56.0122 (UTC) FILETIME=[DEE259A0:01C9B6BD] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 13:43:54 -0000 > OK, we can discuss this "minor detail" later. This is not a minor detail. These details are critical to why NHDP is as it is, and interface IP addresses are needed. > Using the RouterID as source address eliminates sending the msg-orig-addr in > hellos. msg-orig-addr is already essentially eliminated, as it is optional in RFC 5444 and isn't used in NHDP. (It is used in OLSRv2 TC messages.) But trying to use a router ID as a source address does not work in general. Note that what has a source address is an IP datagram, containing an RFC 5444 packet which is multiplexed from multiple protocols, of which NHDP and OLSRv2 are only examples. This is essentially a layer violation. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From chris.dearlove@baesystems.com Mon Apr 6 06:44:13 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 B58D728C18D for ; Mon, 6 Apr 2009 06:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.618 X-Spam-Level: X-Spam-Status: No, score=-6.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, 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 9I5B0YJT6G-e for ; Mon, 6 Apr 2009 06:44:07 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id AB5C63A6C89 for ; Mon, 6 Apr 2009 06:44:06 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36Dj6kP006486 for ; Mon, 6 Apr 2009 14:45:06 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36Dj6fC026468 for ; Mon, 6 Apr 2009 14:45:06 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 14:45:06 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 14:45:05 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Apr 2009 14:45:04 +0100 Message-ID: In-Reply-To: <51108.68.222.95.76.1239024505.squirrel@webmail.jsums.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2u5XRwhim5XmCR8afj6MAam+jCAAABJzw References: <200904061119.07374.rogge@fgan.de> <200904061238.11268.rogge@fgan.de> <200904061258.43279.rogge@fgan.de> <51108.68.222.95.76.1239024505.squirrel@webmail.jsums.edu> From: "Dearlove, Christopher (UK)" To: , "Henning Rogge" X-OriginalArrivalTime: 06 Apr 2009 13:45:05.0698 (UTC) FILETIME=[E4978820:01C9B6BD] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 13:44:13 -0000 > Can these emails be please exchanged only among the concerned persons > rather than the whole MANET group? Actually, no. The main purpose of this IETF MANET WG mailing list is to hold discussions relating to the progression of the WG's documents towards RFC status. This is an open process, and this discussion is being held in the open to achieve this. The MANET mailing list was, until recently a mess where these things it is meant for didn't happen here, and what was here was a whole lot of off-topic discussion. (General discussion of MANETs is not the purpose of this group, except in that it progresses the WG documents and related matters, and WG administration and so on.) Fortunately, or rather due to an initiative by Ian [and my apologies to the person who did (does?) a lot of the discouraging of off-topic posting, that I can't recall your name to say thank you] this list now does cover on topic things, and this discussion is exactly that. Actually at least one side-thread has gone private, where it has gone onto another topic. But the main subject is what this list is for. ******************************************************************** 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 Rogge@fgan.de Mon Apr 6 06:44: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 7AA963A6C88 for ; Mon, 6 Apr 2009 06:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_DE=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 i1-KnjC+FL00 for ; Mon, 6 Apr 2009 06:44:41 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 4B76128C130 for ; Mon, 6 Apr 2009 06:44:39 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Lqp8x-0000Wj-S1; Mon, 06 Apr 2009 15:45:43 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1Lqp8x-0002Ou-H3; Mon, 06 Apr 2009 15:45:43 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 15:45:43 +0200 From: Henning Rogge To: "Dearlove, Christopher (UK)" Date: Mon, 6 Apr 2009 15:45:36 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.28.1; KDE/4.1.4; i686; ; ) References: <200904061119.07374.rogge@fgan.de> <200904061512.35997.rogge@fgan.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3416465.2ocHCVhkym"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904061545.43281.rogge@fgan.de> X-OriginalArrivalTime: 06 Apr 2009 13:45:43.0478 (UTC) FILETIME=[FB1C4D60:01C9B6BD] X-Virus-Scanned: yes (ClamAV 0.94.2/9207/Mon Apr 6 13:58:21 2009) by mailguard.fgan.de X-Scan-Signature: d163b979b1239c4a1e19ba7cda5fb2a3 Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 13:44:42 -0000 --nextPart3416465.2ocHCVhkym Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Monday 06 April 2009 15:26:21 schrieb Dearlove, Christopher (UK): > There's nothing in NHDP that makes you use linklocal > addresses. But there's nothing that stops you. Yes, > you use those link local addresses further away (in > NHDP two hops away). I will note that as far as I > could tell most of the members of the autoconf > Design Team seemed happy to use a MANET interface > address with a MANET-wide scope. (The MANET WG has > ducked every time it's been suggested to ask IANA > for a specific MANET-scoped address however.) I can imagine that would be difficult... ;) > But, if using link local addresses, you can't stop those > link local addresses being seen two hops away. And it is > essential (in NHDP) that they are unique up to two hops > (not just one) away, as that's how symmetry advertisement > in HELLO messages works. And once they are visible, have > to be inspected, and have to be unique two hops away, > putting them in Information Bases is not adding any new > problems. The problem with OLSR (or wireless links) are the overlapping and non-disjo= int=20 broadcast domains, so yes the term link-local might be a little bit dangero= us=20 there. > |Yes, I'm thinking of OLSR packets as "linklocal" packages (they only > |travel on > |hop away to the next OLSR instance), so they should always have the > |linklocal > |source IP. > > OK, we can discuss this "minor detail" later. > I originally suggested usage of LLs (see Autoconf PPT last IETF). > > Using the RouterID as source address eliminates sending the msg-orig-addr > in hellos. It is more in line with Thomas his "practical addressing > proposal" using unique host prefixes on MANET interfaces. It introduces t= he > requirement for L3 to L2 mapping (solvable). If you use the src-ip to transmit the router ID then you must include the=20 interface IP in the message to define the "next hop" for your routing entri= es=20 (which are done with linklocal IPs in most IPv6 routers). So I'm not sure t= his=20 would safe much. =2D------------- Okay, let's see if we can get back to something more "productive". I will=20 continue to work (mostly coding it for OLSRv1 at the moment) on the=20 "originator-IP" idea, but maybe we can all agree to relax some sentences in= =20 the OLSRv2 draft so the TC part of my concept will fit into the draft witho= ut=20 changing existing implementations. The Hello part of the new concept still= =20 needs some work. Part 8.2., page 32 of the OLSRv2 draft (TC messages) says A TC message MUST contain: =2E.... "All of the router's interface addresses. These MUST be included in the=20 message's Address Blocks, unless..." I think this paragraph could be relaxed to "All of the router's globaly=20 routable IPs" or something like this. If I don't plan any routes to an=20 interface IP, there is no reason to put it into the header of the TC. A few lines later it says: "If the TC message is complete, all addresses in the Advertised Address Set= =20 and..." This section points to section 6.3.1., page 19 (Advertised Neighbor Set): "A router's Advertised Neighbor Set contains interface addresses of symmetr= ic=20 1-hop neighbors which are to be advertised through TC messages. ..." Maybe this one could be relaxed a little bit too so it's not necessary to p= ut=20 interface IPs in there but a globally routable IP of the neighbor node. This way an OLSR agent can decide to use originator-IPs or just drop double= =20 link information from the AN set. What do you think ? Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart3416465.2ocHCVhkym Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAknaB4AACgkQRIfGfFXsz+BGkACfain3cYQFRifaSSv9b4oxG113 j8sAoIXHd26dtvjBT+fdTDPb8uoMzxoU =6cD9 -----END PGP SIGNATURE----- --nextPart3416465.2ocHCVhkym-- From teco@inf-net.nl Mon Apr 6 06:52:46 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 6B7CD3A68A6 for ; Mon, 6 Apr 2009 06:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.08 X-Spam-Level: X-Spam-Status: No, score=-1.08 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 2S5OpO9hIag6 for ; Mon, 6 Apr 2009 06:52:45 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id ED2333A6C6C for ; Mon, 6 Apr 2009 06:51:08 -0700 (PDT) Received: (qmail 27920 invoked from network); 6 Apr 2009 15:52:12 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 6 Apr 2009 15:52:12 +0200 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Henning Rogge'" References: <200904061119.07374.rogge@fgan.de> <004a01c9b6b7$a6d30f10$f4792d30$@nl> <200904061512.35997.rogge@fgan.de> In-Reply-To: Date: Mon, 6 Apr 2009 15:51:43 +0200 Message-ID: <005c01c9b6be$e3a0af90$aae20eb0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm2uV/52Vwoae2SQF6X9E7hrt5aOwAABbNwAADn3ZA= Content-Language: nl Cc: manet@ietf.org, 'Thomas Heide Clausen' Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 13:52:46 -0000 |There's nothing in NHDP that makes you use linklocal |addresses. But there's nothing that stops you. Yes, |you use those link local addresses further away (in |NHDP two hops away). LLs could be used as identifier, as an extension to link local address = for "next hop routing". But only if this is applicable. We better use a well defined identifier for it, such as RouterID. | I will note that as far as I |could tell most of the members of the autoconf |Design Team seemed happy to use a MANET interface |address with a MANET-wide scope. No answers yet on my question what to do with IPv6 LLs. They are = mandatory. The current NHDP / OLSRv2 text locks out usage of IPv6. For sure, this = point will be raised in a NHDP / OLSRv2 WGLC and follow-up. Small text changes fix this problem (ALL interface addresses, but NOT = the LLs..... or another concept using RouterID). | (The MANET WG has |ducked every time it's been suggested to ask IANA |for a specific MANET-scoped address however.) | |But, if using link local addresses, you can't stop those |link local addresses being seen two hops away. And it is |essential (in NHDP) that they are unique up to two hops |(not just one) away,=20 Depending on movement, they MUST be unique in a MANET segment, that = could be 10 hops away, or even 255... If LLs are used as source address, and NOT as RouterID / InterfaceID or whatever they are NOT seen further than 1 hop away. |as that's how symmetry advertisement |in HELLO messages works. And once they are visible, have |to be inspected, and have to be unique two hops away, |putting them in Information Bases is not adding any new |problems. The "problem" is that LLs are unique within a "segment". A router may = use the same LL address on multiple interfaces. Teco. |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: Henning Rogge [mailto:rogge@fgan.de] |Sent: 06 April 2009 14:13 |To: Dearlove, Christopher (UK) |Cc: Teco Boot; manet@ietf.org; Thomas Heide Clausen |Subject: Re: [manet] OLSRv2 - RouterID | |Am Monday 06 April 2009 15:06:58 schrieb Dearlove, Christopher (UK): |> >|Only OLSR broadcast have the interface IP as it's source. |> > |> > Agreed on that all NHDP/OLSRv2 messages use RouterID as source |> |> address. |> |> That isn't agreement. Henning pointed out that OLSR |> broadcasts will use interface IP as source address, |> which is correct. Using Router ID is different, and |> not what will happen. | |Yes, I'm thinking of OLSR packets as "linklocal" packages (they only |travel on |hop away to the next OLSR instance), so they should always have the |linklocal |source IP. | |Henning Rogge | |************************************************* |Diplom Informatiker Henning Rogge |Forschungsgesellschaft f=FCr |Angewandte Naturwissenschaften e. V. (FGAN) |Neuenahrer Str. 20, 53343 Wachtberg, Germany |Tel.: 0049 (0)228 9435-961 |Fax: 0049 (0)228 9435-685 |E-Mail: rogge@fgan.de |Web: www.fgan.de |************************************************ |Sitz der Gesellschaft: Bonn |Registergericht: Amtsgericht Bonn VR 2530 |Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. = Dr.-Ing. |Joachim Ender (Stellv.) | | |******************************************************************** |This email and any attachments are confidential to the intended |recipient and may also be privileged. If you are not the intended |recipient please delete it from your system and notify the sender. |You should not copy it or use it for any purpose nor disclose or |distribute its contents to any other person. |******************************************************************** From chris.dearlove@baesystems.com Mon Apr 6 06:57:58 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 641343A68AD for ; Mon, 6 Apr 2009 06:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.618 X-Spam-Level: X-Spam-Status: No, score=-6.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, 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 lRN4Y54JRK7y for ; Mon, 6 Apr 2009 06:57:57 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id B40853A68E0 for ; Mon, 6 Apr 2009 06:57:53 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36Dwv48018189 for ; Mon, 6 Apr 2009 14:58:57 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36DwvJm002646 for ; Mon, 6 Apr 2009 14:58:57 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 14:58:56 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 14:58:56 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Apr 2009 14:58:54 +0100 Message-ID: In-Reply-To: <200904061545.43281.rogge@fgan.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2vgaO2YC0oer8QPyQ8mvx54RKuwAACDdQ References: <200904061119.07374.rogge@fgan.de> <200904061512.35997.rogge@fgan.de> <200904061545.43281.rogge@fgan.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" X-OriginalArrivalTime: 06 Apr 2009 13:58:56.0557 (UTC) FILETIME=[D3D28DD0:01C9B6BF] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 13:57:58 -0000 > maybe we can all agree to relax some sentences in=20 > the OLSRv2 draft so the TC part of my concept will fit into the draft without=20 > changing existing implementations. I think we are on the same page here. > Part 8.2., page 32 of the OLSRv2 draft (TC messages) says > A TC message MUST contain: > ..... > > "All of the router's interface addresses. These MUST be included in the=20 > message's Address Blocks, unless..." > > I think this paragraph could be relaxed to "All of the router's globaly=20 > routable IPs" or something like this. If I don't plan any routes to an > interface IP, there is no reason to put it into the header of the TC. This isn't quite the solution, as it fails to handle the case of a node that is routing only, i.e. only acts as a relay, has no routable addresses, but still needs to appear in the Topology Graph. But that can be squared, it's just a question of details. Incidentally in this case (or any other) it's no harm if the address ends up in the Routing Set, it just shouldn't be copied to the IP routing table. That indicates another piece of text revision that would be part of this. And there is a second possible saving, relating to aggregation (possibly more relevant to the non-LL address approach) that the authors have bounced off each other but are still thinking about. > A few lines later it says: > > "If the TC message is complete, all addresses in the Advertised Address Set=20 > and..." > > This section points to section 6.3.1., page 19 (Advertised Neighbor Set): > > "A router's Advertised Neighbor Set contains interface addresses of symmetric=20 > 1-hop neighbors which are to be advertised through TC messages. ..." > > Maybe this one could be relaxed a little bit too so it's not necessary to put=20 > interface IPs in there but a globally routable IP of the neighbor node. These two paragraphs should essentially be saying the same thing from different perspectives. So if one changes, so does the other. (And I don't rule out there being any others as well.) I would be happy to proceed with NHDP as-is and undertake to make a revision along these lines in OLSRv2. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From chris.dearlove@baesystems.com Mon Apr 6 07:02:13 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 D3A2C3A6C73 for ; Mon, 6 Apr 2009 07:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.617 X-Spam-Level: X-Spam-Status: No, score=-6.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, 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 NQ8AxALNc68S for ; Mon, 6 Apr 2009 07:02:13 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id DE0F03A698B for ; Mon, 6 Apr 2009 07:02:12 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36E3H27020209 for ; Mon, 6 Apr 2009 15:03:17 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36E3GBK006566 for ; Mon, 6 Apr 2009 15:03:16 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 15:03:16 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 15:03:16 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Apr 2009 15:03:14 +0100 Message-ID: In-Reply-To: <005c01c9b6be$e3a0af90$aae20eb0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2uV/52Vwoae2SQF6X9E7hrt5aOwAABbNwAADn3ZAAALp90A== References: <200904061119.07374.rogge@fgan.de><004a01c9b6b7$a6d30f10$f4792d30$@nl><200904061512.35997.rogge@fgan.de> <005c01c9b6be$e3a0af90$aae20eb0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Henning Rogge" X-OriginalArrivalTime: 06 Apr 2009 14:03:16.0323 (UTC) FILETIME=[6EA7B330:01C9B6C0] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 14:02:13 -0000 > A router may use > the same LL address on multiple interfaces. This I think is the one sticking point, it's not going to work, as differentiating MANET interfaces is essential. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Mon Apr 6 07:06:11 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 86EAB28C10C for ; Mon, 6 Apr 2009 07:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 tMIx0jNWK2Oj for ; Mon, 6 Apr 2009 07:06:10 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 8AEBC3A6850 for ; Mon, 6 Apr 2009 07:06:09 -0700 (PDT) Received: (qmail 10404 invoked from network); 6 Apr 2009 16:07:12 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 6 Apr 2009 16:07:12 +0200 From: "Teco Boot" To: "'Henning Rogge'" , "'Dearlove, Christopher \(UK\)'" References: <200904061119.07374.rogge@fgan.de> <200904061512.35997.rogge@fgan.de> <200904061545.43281.rogge@fgan.de> In-Reply-To: <200904061545.43281.rogge@fgan.de> Date: Mon, 6 Apr 2009 16:06:42 +0200 Message-ID: <006001c9b6c0$fbf20c90$f3d625b0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm2vh/HPo4GJ2wBRVeG6dvJFKDNowAAQ3aw Content-Language: nl Cc: manet@ietf.org, 'Thomas Heide Clausen' Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 14:06:11 -0000 |-----Oorspronkelijk bericht----- |Van: Henning Rogge [mailto:rogge@fgan.de] |Verzonden: maandag 6 april 2009 15:46 |Aan: Dearlove, Christopher (UK) |CC: Teco Boot; manet@ietf.org; Thomas Heide Clausen |Onderwerp: Re: [manet] OLSRv2 - RouterID | |Am Monday 06 April 2009 15:26:21 schrieb Dearlove, Christopher (UK): |> There's nothing in NHDP that makes you use linklocal |> addresses. But there's nothing that stops you. Yes, |> you use those link local addresses further away (in |> NHDP two hops away). I will note that as far as I |> could tell most of the members of the autoconf |> Design Team seemed happy to use a MANET interface |> address with a MANET-wide scope. (The MANET WG has |> ducked every time it's been suggested to ask IANA |> for a specific MANET-scoped address however.) |I can imagine that would be difficult... ;) | |> But, if using link local addresses, you can't stop those |> link local addresses being seen two hops away. And it is |> essential (in NHDP) that they are unique up to two hops |> (not just one) away, as that's how symmetry advertisement |> in HELLO messages works. And once they are visible, have |> to be inspected, and have to be unique two hops away, |> putting them in Information Bases is not adding any new |> problems. |The problem with OLSR (or wireless links) are the overlapping and non- |disjoint |broadcast domains, so yes the term link-local might be a little bit |dangerous |there. | |> |Yes, I'm thinking of OLSR packets as "linklocal" packages (they only |> |travel on |> |hop away to the next OLSR instance), so they should always have the |> |linklocal |> |source IP. |> |> OK, we can discuss this "minor detail" later. |> I originally suggested usage of LLs (see Autoconf PPT last IETF). |> |> Using the RouterID as source address eliminates sending the msg-orig- |addr |> in hellos. It is more in line with Thomas his "practical addressing |> proposal" using unique host prefixes on MANET interfaces. It |introduces the |> requirement for L3 to L2 mapping (solvable). | |If you use the src-ip to transmit the router ID then you must include |the |interface IP in the message to define the "next hop" for your routing |entries |(which are done with linklocal IPs in most IPv6 routers). So I'm not |sure this |would safe much. It saves the msg-orig-addr. Interface IP is not needed, as the receiver interface is used as placeholder (sender and receiver interfaces are on = same link. RouterID could be used for next-hop. For forwarding on the medium, = the L2 address is important (far more important, as the next hop IP address = is not stored in the forwarded packet). Therefore, the need for L3 to L2 mapping. | |-------------- | |Okay, let's see if we can get back to something more "productive". OK. I am still interested in a reference document describing using RouterID doesn't work. It was mentioned there was a race condition. If there is a problem, we all know the reason for the more complex approach, with some more overhead. =20 |I will |continue to work (mostly coding it for OLSRv1 at the moment) on the |"originator-IP" idea, but maybe we can all agree to relax some = sentences |in |the OLSRv2 draft so the TC part of my concept will fit into the draft |without |changing existing implementations. The Hello part of the new concept |still |needs some work. | |Part 8.2., page 32 of the OLSRv2 draft (TC messages) says | |A TC message MUST contain: |..... | |"All of the router's interface addresses. These MUST be included in the |message's Address Blocks, unless..." | |I think this paragraph could be relaxed to "All of the router's globaly |routable IPs" or something like this. If I don't plan any routes to an |interface IP, there is no reason to put it into the header of the TC. Also, if a summary prefix is advertized, more specific prefixes do not = need to be advertized. However, topology information must be complete. |A few lines later it says: | |"If the TC message is complete, all addresses in the Advertised Address |Set |and..." | |This section points to section 6.3.1., page 19 (Advertised Neighbor |Set): | |"A router's Advertised Neighbor Set contains interface addresses of |symmetric |1-hop neighbors which are to be advertised through TC messages. ..." | |Maybe this one could be relaxed a little bit too so it's not necessary |to put |interface IPs in there but a globally routable IP of the neighbor node. | |This way an OLSR agent can decide to use originator-IPs or just drop |double |link information from the AN set. | |What do you think ? | |Henning Rogge | |************************************************* |Diplom Informatiker Henning Rogge |Forschungsgesellschaft f=FCr |Angewandte Naturwissenschaften e. V. (FGAN) |Neuenahrer Str. 20, 53343 Wachtberg, Germany |Tel.: 0049 (0)228 9435-961 |Fax: 0049 (0)228 9435-685 |E-Mail: rogge@fgan.de |Web: www.fgan.de |************************************************ |Sitz der Gesellschaft: Bonn |Registergericht: Amtsgericht Bonn VR 2530 |Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. = Dr.-Ing. |Joachim Ender (Stellv.) From chris.dearlove@baesystems.com Mon Apr 6 07:09:00 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 E19BB3A6C69 for ; Mon, 6 Apr 2009 07:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.617 X-Spam-Level: X-Spam-Status: No, score=-6.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, 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 Wy1r0qc4waFe for ; Mon, 6 Apr 2009 07:09:00 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 0246E3A67E2 for ; Mon, 6 Apr 2009 07:08:59 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36EA3KY023032 for ; Mon, 6 Apr 2009 15:10:03 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36EA3Oi029604 for ; Mon, 6 Apr 2009 15:10:03 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 15:10:03 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 15:10:02 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Apr 2009 15:10:01 +0100 Message-ID: In-Reply-To: <006001c9b6c0$fbf20c90$f3d625b0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2vh/HPo4GJ2wBRVeG6dvJFKDNowAAQ3awAACCeuA= References: <200904061119.07374.rogge@fgan.de> <200904061512.35997.rogge@fgan.de> <200904061545.43281.rogge@fgan.de> <006001c9b6c0$fbf20c90$f3d625b0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Henning Rogge" X-OriginalArrivalTime: 06 Apr 2009 14:10:02.0979 (UTC) FILETIME=[610A7B30:01C9B6C1] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 14:09:01 -0000 > Also, if a summary prefix is advertized, more specific prefixes do not need > to be advertized. That is what I meant by address aggregation. > However, topology information must be complete. And that's why the "relay only" node needs a little care. But we can give it that. ******************************************************************** 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 Mon Apr 6 07:13:18 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 118463A6C99 for ; Mon, 6 Apr 2009 07:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 hNGgylRyk6Hh for ; Mon, 6 Apr 2009 07:13:11 -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 BAF5C3A681F for ; Mon, 6 Apr 2009 07:13:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,330,1235948400"; d="scan'208";a="24054806" Received: from mp-41253.rocq.inria.fr ([128.93.41.253]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2009 16:14:14 +0200 Message-ID: <49DA0EFA.7080108@inria.fr> Date: Mon, 06 Apr 2009 16:17:30 +0200 From: jacquet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Charles E. Perkins" References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> <200904021510.58935.rogge@fgan.de><010b01c9b445$91d94c10$b58be430$@nl> <011a01c9b45c$eed44750$cc7cd5f0$@nl> <49D63C55.4070105@earthlink.net> In-Reply-To: <49D63C55.4070105@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 - RouterID 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, 06 Apr 2009 14:13:18 -0000 Hello, Charlie, Your question is very pertinent. This was indeed an old discussion, that I merely forgot. It was based on the principle that if interfaces differ too much in performance you may have uncontrolled effects, and it was difficult to taylor a proper mechanism for each special cases. One special case: assume that you have two kinds of interfaces: slow and fast. If slow means very slow, then you may have a very long flooding time for a single packet if you merge interfaces for MPR selection. You may even have no end at all;-) Consider the following network B-----D / \ / \ A \ / F \ / \ / C-----E with all interfaces of type fast excepted (B,D) and (C,E), that are slow. If all interfaces are merged for MPR calculation, then it can be that MPR of B and C are all on slow interface. Suppose MPRs of A are both B and C (there may be additional neighbors on B and C to force that). If A initiates a flood, then B and C will retransmit simultaneously on fast interface and slow interface, but fast interface arrives first on D and E, both receive first from non MPR and cannot relay. F does not receive the broadcast. When D or E eventually receive from the slow interface it could compare time stamps to actually decide that slow interface indeed had precedence on fast interface in race competition and finally to decide to actually retransmit. But again you come out with the performance of the worse interface (and a very complicated mechanism). If MPR are on per interface, then B will select E as MPR on fast interface and you gain on the fastest interface which will win the race competition. I think this was the issue (but I am not sure), but I agree that the result was a kind of compromise to keep things simple. Best regards, Philippe Charles E. Perkins a écrit : > > Hello Chris, > > Comments below... > > Dearlove, Christopher (UK) wrote: >> >>> I don't understand this. The requirement is that the set >>> of MPRs must provide connectivity to all 2-hop neighbors >>> >> >> That's not sufficient. >> > > I believe this is highly debatable. > >> >>> o Why MPR selection per interface? >>> >> >> Read the literature. And yes, that is me not putting in the effort >> to point out the race condition case and why per interface avoids >> it and per router doesn't (a subtlety in the MPR flooding proof). >> > > I read the proofs, albeit a couple of years ago, and I don't remember > anything particular about this point. Too bad I can't go back and review > this material today. > From jdean@itd.nrl.navy.mil Mon Apr 6 07:20:18 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 E8F063A6C8E for ; Mon, 6 Apr 2009 07:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_40=-0.185, HTML_MESSAGE=0.001, 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 M4FN3rD6lmsF for ; Mon, 6 Apr 2009 07:20:13 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id EC47D28C1A4 for ; Mon, 6 Apr 2009 07:20:12 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id n36EKseU013736; Mon, 6 Apr 2009 10:21:14 -0400 Received: (from bebe [132.250.93.61]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009040610211430498 ; Mon, 06 Apr 2009 10:21:14 -0400 From: "Justin Dean" To: "'Mahendra Salunke'" , References: <1a6317190904030516h165ffaa3he0f4bfef28d6987c@mail.gmail.com> In-Reply-To: <1a6317190904030516h165ffaa3he0f4bfef28d6987c@mail.gmail.com> Date: Mon, 6 Apr 2009 10:20:56 -0400 Message-ID: <00a101c9b6c2$e7069a10$b513ce30$@nrl.navy.mil> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A2_01C9B6A1.5FF4FA10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm0VhuZ3UmfFV46RMO3ihzRn9DxlgCbFOnQ Content-Language: en-us Subject: Re: [manet] Want to develop testbed for MANET? 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, 06 Apr 2009 14:20:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A2_01C9B6A1.5FF4FA10 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit NRL maintains a few open source MANET test beds code bases. You can find them at http://cs.itd.nrl.navy.mil/products/ Justin Dean From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Mahendra Salunke Sent: Friday, April 03, 2009 8:16 AM To: manet@ietf.org Subject: [manet] Want to develop testbed for MANET? Hello all, I want to develop MANET testbed using LAPTOPs and PDAs to test existing and modified protocols in MANET. Can I get guidelines for developing testbed for MANET? I want the details of hardware and software required for it. Thanks in advance. -- Mahendra B. Salunke ------=_NextPart_000_00A2_01C9B6A1.5FF4FA10 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

NRL maintains a few open source MANET test beds code bases.  You can find them at http://cs.itd.nrl.navy.mil/= products/

 

Justin Dean

 

From:= = manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Mahendra Salunke
Sent: Friday, April 03, 2009 8:16 AM
To: manet@ietf.org
Subject: [manet] Want to develop testbed for = MANET?

 

Hello all,

 

I want to develop MANET testbed using LAPTOPs and PDAs to test existing and modified protocols in = MANET.

 

Can I get guidelines for developing testbed for = MANET?

 

I want the details of hardware and software = required for it.

Thanks in advance.

 

-- 
Mahendra B. Salunke

 

------=_NextPart_000_00A2_01C9B6A1.5FF4FA10-- From sratliff@cisco.com Mon Apr 6 07:25:32 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 3F1CB3A6CA4 for ; Mon, 6 Apr 2009 07:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 rNoofTQFSAqC for ; Mon, 6 Apr 2009 07:25:30 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 108FB3A6B4B for ; Mon, 6 Apr 2009 07:25:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,330,1235952000"; d="scan'208";a="151398011" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 06 Apr 2009 14:25:52 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n36EPqeM015997; Mon, 6 Apr 2009 07:25:52 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n36EPWmQ020461; Mon, 6 Apr 2009 14:25:52 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 10:25:48 -0400 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: quoted-printable Date: Mon, 6 Apr 2009 10:25:46 -0400 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76407F617A1@xmb-rtp-208.amer.cisco.com> In-Reply-To: <200904061344.21632.rogge@fgan.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2rRCcKJ1wqbKzSRGrzTzhZuav6wAFclmA References: <200904061119.07374.rogge@fgan.de><200904061307.28277.rogge@fgan.de> <200904061344.21632.rogge@fgan.de> From: "Stan Ratliff (sratliff)" To: "Henning Rogge" , "Dearlove, Christopher (UK)" X-OriginalArrivalTime: 06 Apr 2009 14:25:48.0693 (UTC) FILETIME=[94BAFC50:01C9B6C3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2664; t=1239027952; x=1239891952; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[manet]=20OLSRv2=20-=20RouterID |Sender:=20; bh=lUQIKiCpbgSjikeQBoU7lemo2jdir6qSGm1eJ6rj11s=; b=rPmasC5JGzsU/RP/ATPLIA1t2JbAx7LzwV9L+dZYL6mWDTCNBiJXWPPr5I mnoSzfO1P1+fiGIuHd74aisWd7oPIg05QDyxw3B6aINzChkVvRlbOazvGZ6i BTWihYGf0s; Authentication-Results: sj-dkim-4; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 14:25:32 -0000 >=20 > Thats similar how it's done in NHDP now. But you can skip the=20 > interface IP if this interface has only one and it is=20 > contained in the source of the ip- datagram. >=20 It's beginning to sound like there are some assumptions being made -- = like, OLSR will *always* run on top of UDP. That's a bad idea for router = vendors. It adversely effects performance, not to mention the = "architectural argument" about running Layer 3 on top of Layer 4... ;-) Regards, Stan =20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org]=20 > On Behalf Of Henning Rogge > Sent: Monday, April 06, 2009 7:44 AM > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; Thomas Heide Clausen > Subject: Re: [manet] OLSRv2 - RouterID >=20 > Am Monday 06 April 2009 13:36:23 schrieb Dearlove, Christopher (UK): > > > If there are multiple interface IPs they can be all=20 > included in the=20 > > > message marked with LOCAL_IF(THIS_IF). > > > > Now you're including IP addresses and interface IDs in=20 > HELLO messages >=20 > interface IDs =3D router-id =3D originator-IP ? >=20 > From my first email today: > - a Hello message MUST contain the router-ID of it's OLSR node as the > =A0 originator-IP of the message > - a Hello message CAN include the interface IP of it's OLSR node as an > =A0 address tagged with LOCAL_IF(THIS_IF). The address can be omitted = if > =A0 the source IP of the package contains the interface IP >=20 > So yes, the Hello messages contain both the public/netwide IP=20 > of the router (the originator-ip), the (optional) the=20 > linklocal/interface IPs of the router and the public IPs of=20 > it's neighbors. >=20 > Should be pretty straight forward because Hellos are TTL 1=20 > messages, so linklocal IPs ARE routable IPs in this scope. >=20 > > , Not good. >=20 > Thats similar how it's done in NHDP now. But you can skip the=20 > interface IP if this interface has only one and it is=20 > contained in the source of the ip- datagram. >=20 > Henning Rogge >=20 > ************************************************* > Diplom Informatiker Henning Rogge > Forschungsgesellschaft f=FCr > Angewandte Naturwissenschaften e. V. (FGAN) Neuenahrer Str.=20 > 20, 53343 Wachtberg, Germany > Tel.: 0049 (0)228 9435-961 > Fax: 0049 (0)228 9435-685 > E-Mail: rogge@fgan.de > Web: www.fgan.de > ************************************************ > Sitz der Gesellschaft: Bonn > Registergericht: Amtsgericht Bonn VR 2530 > Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.),=20 > Prof. Dr.-Ing.=20 > Joachim Ender (Stellv.) >=20 >=20 From chris.dearlove@baesystems.com Mon Apr 6 07:29:49 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 E5A7828C1DD for ; Mon, 6 Apr 2009 07:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.617 X-Spam-Level: X-Spam-Status: No, score=-6.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, 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 vxd1xFKYDnXq for ; Mon, 6 Apr 2009 07:29:43 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id E175D28C1EF for ; Mon, 6 Apr 2009 07:28:34 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36ETQla001162 for ; Mon, 6 Apr 2009 15:29:26 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36ETQkV008512 for ; Mon, 6 Apr 2009 15:29:26 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 15:29:26 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 15:29:25 +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: Mon, 6 Apr 2009 15:29:24 +0100 Message-ID: In-Reply-To: <49DA0EFA.7080108@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2wfzb+PMIYByFSFykg7J/DatEYQAAG9bA References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> <200904021510.58935.rogge@fgan.de><010b01c9b445$91d94c10$b58be430$@nl> <011a01c9b45c$eed44750$cc7cd5f0$@nl> <49D63C55.4070105@earthlink.net> <49DA0EFA.7080108@inria.fr> From: "Dearlove, Christopher (UK)" To: "jacquet" , "Charles E. Perkins" X-OriginalArrivalTime: 06 Apr 2009 14:29:25.0761 (UTC) FILETIME=[161CEF10:01C9B6C4] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 14:29:50 -0000 Charlie Didn't see your message until Philippe replied. For some reason I think you are filtered out here - I never see your postings these days (I used to) only replies to them. What email address is your usual one (or ones) these days, I'll see if I can get them whitelisted (or whatever it takes).=20 My understanding (having posted in haste to see the literature, and Stan Ratliff also having asked for the specific posting) from Thomas is that the detail is published, but buried in some INRIA report. On the (extensive) list of things Thomas and I plan to do when time permits (which I hope doesn't mean never, but you knwo how it is) is including this, among other details, in various informational material (nature of publication TBD) we'd would really like to put out for the first time, or in a more accessible form. But don't hold your breath! Thomas said (to me) he'd put this on the list, I'm not sure if this is Philippe doing that for Thomas or independently. Of course you can ignore the issue, and things will probably work most of the time. But do you accept that a known race condition exists, or do you do something that avoids it? (Note that you really should follow the advice that I know is in OLSRv2, and I think is in RFC 3626, and although each interface has an MPR Set, and the overall MPR Set is the union, they should be calculated together, so that typically there's no serious loss in flooding efficiency.) --=20 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: jacquet [mailto:philippe.jacquet@inria.fr]=20 Sent: 06 April 2009 15:17 To: Charles E. Perkins Cc: Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Hello, Charlie, Your question is very pertinent. This was indeed an old discussion, that=20 I merely forgot. It was based on the principle that if interfaces differ=20 too much in performance you may have uncontrolled effects, and it was=20 difficult to taylor a proper mechanism for each special cases. One special case: assume that you have two kinds of interfaces: slow and=20 fast. If slow means very slow, then you may have a very long flooding=20 time for a single packet if you merge interfaces for MPR selection. You=20 may even have no end at all;-) Consider the following network B-----D / \ / \ A \ / F \ / \ / C-----E with all interfaces of type fast excepted (B,D) and (C,E), that are=20 slow. If all interfaces are merged for MPR calculation, then it can be=20 that MPR of B and C are all on slow interface. Suppose MPRs of A are both B and C (there may be additional neighbors on=20 B and C to force that). If A initiates a flood, then B and C will retransmit simultaneously on=20 fast interface and slow interface, but fast interface arrives first on D=20 and E, both receive first from non MPR and cannot relay. F does not=20 receive the broadcast. When D or E eventually receive from the slow interface it could compare=20 time stamps to actually decide that slow interface indeed had precedence=20 on fast interface in race competition and finally to decide to actually=20 retransmit. But again you come out with the performance of the worse=20 interface (and a very complicated mechanism). If MPR are on per interface, then B will select E as MPR on fast interface and you gain on the fastest interface which will win the race competition. I think this was the issue (but I am not sure), but I agree that the=20 result was a kind of compromise to keep things simple. Best regards, Philippe Charles E. Perkins a =E9crit : > > Hello Chris, > > Comments below... > > Dearlove, Christopher (UK) wrote: >> =20 >>> I don't understand this. The requirement is that the set >>> of MPRs must provide connectivity to all 2-hop neighbors >>> =20 >> >> That's not sufficient. >> =20 > > I believe this is highly debatable. > >> =20 >>> o Why MPR selection per interface? >>> =20 >> >> Read the literature. And yes, that is me not putting in the effort >> to point out the race condition case and why per interface avoids >> it and per router doesn't (a subtlety in the MPR flooding proof). >> =20 > > I read the proofs, albeit a couple of years ago, and I don't remember > anything particular about this point. Too bad I can't go back and review > this material today. > ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From chris.dearlove@baesystems.com Mon Apr 6 07:37:07 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 0A3983A6C6C for ; Mon, 6 Apr 2009 07:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.616 X-Spam-Level: X-Spam-Status: No, score=-6.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, 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 AVFDdxztlLQA for ; Mon, 6 Apr 2009 07:37:06 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id B99403A6B59 for ; Mon, 6 Apr 2009 07:37:05 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36Ec9Ja027725 for ; Mon, 6 Apr 2009 15:38:09 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36Ec9Jv030764 for ; Mon, 6 Apr 2009 15:38:09 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 15:38:09 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 15:38:09 +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: Mon, 6 Apr 2009 15:38:08 +0100 Message-ID: In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76407F617A1@xmb-rtp-208.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2rRCcKJ1wqbKzSRGrzTzhZuav6wAFclmAAABSXnA= References: <200904061119.07374.rogge@fgan.de><200904061307.28277.rogge@fgan.de> <200904061344.21632.rogge@fgan.de> <7FB7EE0A621BA44B8B69E5F0A09DC76407F617A1@xmb-rtp-208.amer.cisco.com> From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , "Henning Rogge" X-OriginalArrivalTime: 06 Apr 2009 14:38:09.0315 (UTC) FILETIME=[4E2CEF30:01C9B6C5] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 14:37:07 -0000 There's an assumption that OLSR runs on top of IP, but not necessarily using UDP. RFC 5498 gives both options, and currently NHDP/OLSRv2 says do either. There was a=20 suggestion made in San Francisco to pick one, which would have to be the same for all MANET protocols using RFC 5444 multiplexing, but this has not yet been decided. Actually of course you can run the algorithm on top of anything else that has the necessary properties. But it seemed appropriate in the IETF to make this IP. However RFC 5444 allows any size address (1 to 32 octets). If time ever permits, some sort of "where else you can use this" may be appropriate. (What properties? Well, apart from the getting the packet where it should go, using a local broadcast, it also needs a source address of the same type. Actually in NHDP you can manage without that - there's an "if" in the quoted paragraph below - but in OLSRv2 you can't.) --=20 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: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: 06 April 2009 15:26 To: Henning Rogge; Dearlove, Christopher (UK) Cc: manet@ietf.org; Thomas Heide Clausen Subject: RE: [manet] OLSRv2 - RouterID *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 >=20 > Thats similar how it's done in NHDP now. But you can skip the=20 > interface IP if this interface has only one and it is=20 > contained in the source of the ip- datagram. >=20 It's beginning to sound like there are some assumptions being made -- like,= OLSR will *always* run on top of UDP. That's a bad idea for router= vendors. It adversely effects performance, not to mention the= "architectural argument" about running Layer 3 on top of Layer 4... ;-) Regards, Stan =20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org]=20 > On Behalf Of Henning Rogge > Sent: Monday, April 06, 2009 7:44 AM > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; Thomas Heide Clausen > Subject: Re: [manet] OLSRv2 - RouterID >=20 > Am Monday 06 April 2009 13:36:23 schrieb Dearlove, Christopher (UK): > > > If there are multiple interface IPs they can be all=20 > included in the=20 > > > message marked with LOCAL_IF(THIS_IF). > > > > Now you're including IP addresses and interface IDs in=20 > HELLO messages >=20 > interface IDs =3D router-id =3D originator-IP ? >=20 > From my first email today: > - a Hello message MUST contain the router-ID of it's OLSR node as the > =A0 originator-IP of the message > - a Hello message CAN include the interface IP of it's OLSR node as an > =A0 address tagged with LOCAL_IF(THIS_IF). The address can be omitted if > =A0 the source IP of the package contains the interface IP >=20 > So yes, the Hello messages contain both the public/netwide IP=20 > of the router (the originator-ip), the (optional) the=20 > linklocal/interface IPs of the router and the public IPs of=20 > it's neighbors. >=20 > Should be pretty straight forward because Hellos are TTL 1=20 > messages, so linklocal IPs ARE routable IPs in this scope. >=20 > > , Not good. >=20 > Thats similar how it's done in NHDP now. But you can skip the=20 > interface IP if this interface has only one and it is=20 > contained in the source of the ip- datagram. >=20 > Henning Rogge >=20 > ************************************************* > Diplom Informatiker Henning Rogge > Forschungsgesellschaft f=FCr > Angewandte Naturwissenschaften e. V. (FGAN) Neuenahrer Str.=20 > 20, 53343 Wachtberg, Germany > Tel.: 0049 (0)228 9435-961 > Fax: 0049 (0)228 9435-685 > E-Mail: rogge@fgan.de > Web: www.fgan.de > ************************************************ > Sitz der Gesellschaft: Bonn > Registergericht: Amtsgericht Bonn VR 2530 > Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.),=20 > Prof. Dr.-Ing.=20 > Joachim Ender (Stellv.) >=20 >=20 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From philippe.jacquet@inria.fr Mon Apr 6 07:57:25 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 A31B43A6B4B for ; Mon, 6 Apr 2009 07:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.32 X-Spam-Level: X-Spam-Status: No, score=-5.32 tagged_above=-999 required=5 tests=[AWL=0.929, 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 k8DcYzJ+sxg3 for ; Mon, 6 Apr 2009 07:57:24 -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 6229B3A681F for ; Mon, 6 Apr 2009 07:57:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,330,1235948400"; d="scan'208";a="24058753" Received: from mp-41253.rocq.inria.fr ([128.93.41.253]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2009 16:58:29 +0200 Message-ID: <49DA1959.2030908@inria.fr> Date: Mon, 06 Apr 2009 17:01:45 +0200 From: jacquet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> <200904021510.58935.rogge@fgan.de><010b01c9b445$91d94c10$b58be430$@nl> <011a01c9b45c$eed44750$cc7cd5f0$@nl> <49D63C55.4070105@earthlink.net> <49DA0EFA.7080108@inria.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 14:57:25 -0000 Chris, How do you filter Charlie? I thought it was impossible;-) In exchange I will show you how I can filter Thomas. To be per interface or not per interface is not just a formal issue, it has impact on performance. Charlie was right to refresh this issue. But I understood that the main stream of the discussion is now mostly on the advertizement of routerID. And there is a kind of agreement that MPR selection should be done on a per interface basis. Am I right? But I wanted to be sure that no misunderstanding remains. Best regards, Philippe Dearlove, Christopher (UK) a écrit : > Charlie > > Didn't see your message until Philippe replied. For some reason > I think you are filtered out here - I never see your postings > these days (I used to) only replies to them. What email address > is your usual one (or ones) these days, I'll see if I can get > them whitelisted (or whatever it takes). > > My understanding (having posted in haste to see the literature, > and Stan Ratliff also having asked for the specific posting) > from Thomas is that the detail is published, but buried in some > INRIA report. On the (extensive) list of things Thomas and I > plan to do when time permits (which I hope doesn't mean never, > but you knwo how it is) is including this, among other details, > in various informational material (nature of publication TBD) > we'd would really like to put out for the first time, or in a > more accessible form. But don't hold your breath! > > Thomas said (to me) he'd put this on the list, I'm not sure if > this is Philippe doing that for Thomas or independently. > > Of course you can ignore the issue, and things will probably > work most of the time. But do you accept that a known race > condition exists, or do you do something that avoids it? > (Note that you really should follow the advice that I know > is in OLSRv2, and I think is in RFC 3626, and although each > interface has an MPR Set, and the overall MPR Set is the > union, they should be calculated together, so that typically > there's no serious loss in flooding efficiency.) > > From jdean@itd.nrl.navy.mil Mon Apr 6 08:11:23 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 9F9F13A68E0 for ; Mon, 6 Apr 2009 08:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, 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 7bD+oQkBg6WF for ; Mon, 6 Apr 2009 08:11:18 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 266BC28C1D3 for ; Mon, 6 Apr 2009 08:10:59 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id n36FC0j4017325 for ; Mon, 6 Apr 2009 11:12:00 -0400 Received: (from bebe [132.250.93.61]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009040611115930912 for ; Mon, 06 Apr 2009 11:11:59 -0400 From: "Justin Dean" To: References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> <200904021510.58935.rogge@fgan.de><010b01c9b445$91d94c10$b58be430$@nl> <011a01c9b45c$eed44750$cc7cd5f0$@nl> <49D63C55.4070105@earthlink.net> <49DA0EFA.7080108@inria.fr> In-Reply-To: <49DA0EFA.7080108@inria.fr> Date: Mon, 6 Apr 2009 11:11:44 -0400 Message-ID: <00b801c9b6c9$ff9b9d80$fed2d880$@nrl.navy.mil> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm2wg1PPVfisuZzRb28a1WlPo6MQwABAgRg Content-Language: en-us Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 15:11:23 -0000 Thank you Philippe you beat me to the rational for why MPR sets are = chosen per interface instead of aggregated across all interfaces of a node. I = feel that a good portion of the discussion going on about router id type of behaviors are muddling topics between NHDP and OLSRv2 and specifically routing in general. =20 NHDP is a hello protocol meant to collect 2 hop neighbor information. = For a node to discover all of a two-hop neighbors addresses a one-hop neighbor = has to convey that information somehow, and including this information in a HELLO message as opposed to a MID type message is the easiest solution, which also does a few nice things. It saves mandating generation of = another differing MID type of message within the NHDP protocol. It allows = tagging of specific addresses to discover symmetric links; It's not sufficient = for you to tell me just that you heard me, I need to know which interface address you heard me on so I know which will interface will deliver a = packet to you unless one wishes to send out all interfaces every time. Other information such as capabilities/configuration/metrics can be added via = TLVs to the appropriate links without overly complex TLV (i.e. TLVs which = include extra addresses). What including all one hop neighbors addresses in a = HELLO message does not do natively is aggregate 2-hop addresses into one = logical node, TLVs can be added for this informational purpose without breaking = how NHDP functions. =20 One may argue that not all 2-hop addresses are needed only that a node exists 2 hops away. For most MANET operations I do not agree with this argument as it oversimplifies the 2-hop network representation and = requires more complex mechanisms to solve issues which arise in non-trivial cases (multiple interfaces, link metrics, multiple operation mode OLSR/NHDP/OTHER.) Without specific link information selecting MPRs = which guarantee 2-hop deliver in the network Philippe described is not = possible. I would like to point out however that reintroducing a MID type of = message within OLSRv2 may be possible within the context of TC messages. I = would go even further and say that empty update TC message saying "no change" = might be sufficient and more efficient.=20 Justin -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of jacquet Sent: Monday, April 06, 2009 10:18 AM To: Charles E. Perkins Cc: Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID Hello, Charlie, Your question is very pertinent. This was indeed an old discussion, that = I merely forgot. It was based on the principle that if interfaces differ = too much in performance you may have uncontrolled effects, and it was=20 difficult to taylor a proper mechanism for each special cases. One special case: assume that you have two kinds of interfaces: slow and = fast. If slow means very slow, then you may have a very long flooding=20 time for a single packet if you merge interfaces for MPR selection. You = may even have no end at all;-) Consider the following network B-----D / \ / \ A \ / F \ / \ / C-----E with all interfaces of type fast excepted (B,D) and (C,E), that are=20 slow. If all interfaces are merged for MPR calculation, then it can be=20 that MPR of B and C are all on slow interface. Suppose MPRs of A are both B and C (there may be additional neighbors on = B and C to force that). If A initiates a flood, then B and C will retransmit simultaneously on=20 fast interface and slow interface, but fast interface arrives first on D = and E, both receive first from non MPR and cannot relay. F does not=20 receive the broadcast. When D or E eventually receive from the slow interface it could compare=20 time stamps to actually decide that slow interface indeed had precedence = on fast interface in race competition and finally to decide to actually=20 retransmit. But again you come out with the performance of the worse=20 interface (and a very complicated mechanism). If MPR are on per interface, then B will select E as MPR on fast = interface and you gain on the fastest interface which will win the race = competition. I think this was the issue (but I am not sure), but I agree that the=20 result was a kind of compromise to keep things simple. Best regards, Philippe Charles E. Perkins a =E9crit : > > Hello Chris, > > Comments below... > > Dearlove, Christopher (UK) wrote: >> =20 >>> I don't understand this. The requirement is that the set >>> of MPRs must provide connectivity to all 2-hop neighbors >>> =20 >> >> That's not sufficient. >> =20 > > I believe this is highly debatable. > >> =20 >>> o Why MPR selection per interface? >>> =20 >> >> Read the literature. And yes, that is me not putting in the effort >> to point out the race condition case and why per interface avoids >> it and per router doesn't (a subtlety in the MPR flooding proof). >> =20 > > I read the proofs, albeit a couple of years ago, and I don't remember > anything particular about this point. Too bad I can't go back and = review > this material today. > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From chris.dearlove@baesystems.com Mon Apr 6 08:16:06 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 E4F8C3A6926 for ; Mon, 6 Apr 2009 08:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.616 X-Spam-Level: X-Spam-Status: No, score=-6.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, 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 ztDFofVCw6eP for ; Mon, 6 Apr 2009 08:16:06 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id A8FCE3A6808 for ; Mon, 6 Apr 2009 08:16:05 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36FH9oK021608 for ; Mon, 6 Apr 2009 16:17:09 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36FH915026400 for ; Mon, 6 Apr 2009 16:17:09 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 16:17:09 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 16:17:09 +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: Mon, 6 Apr 2009 16:17:08 +0100 Message-ID: In-Reply-To: <49DA1959.2030908@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2yCihqwFmQv5xRn+tbkguxviccAAAjtkw References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> <200904021510.58935.rogge@fgan.de><010b01c9b445$91d94c10$b58be430$@nl> <011a01c9b45c$eed44750$cc7cd5f0$@nl> <49D63C55.4070105@earthlink.net> <49DA0EFA.7080108@inria.fr> <49DA1959.2030908@inria.fr> From: "Dearlove, Christopher (UK)" To: "jacquet" X-OriginalArrivalTime: 06 Apr 2009 15:17:09.0205 (UTC) FILETIME=[C0DBD050:01C9B6CA] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 15:16:07 -0000 I believe the consensus of the authors is that per interface is best, and we know why. But (based on that people like Stan and Charlie are asking the questions) although that this is the case is specified in OLSR,=20 and every OLSRv2 draft I think, it's clearly not well known, and the reasons why are even less well known. --=20 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: jacquet [mailto:philippe.jacquet@inria.fr]=20 Sent: 06 April 2009 16:02 To: Dearlove, Christopher (UK) Cc: Charles E. Perkins; manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Chris, How do you filter Charlie? I thought it was impossible;-) In exchange I=20 will show you how I can filter Thomas. To be per interface or not per interface is not just a formal issue, it=20 has impact on performance. Charlie was right to refresh this issue. But=20 I understood that the main stream of the discussion is now mostly on the=20 advertizement of routerID. And there is a kind of agreement that MPR=20 selection should be done on a per interface basis. Am I right? But I=20 wanted to be sure that no misunderstanding remains. Best regards, Philippe Dearlove, Christopher (UK) a =E9crit : > Charlie > > Didn't see your message until Philippe replied. For some reason > I think you are filtered out here - I never see your postings > these days (I used to) only replies to them. What email address > is your usual one (or ones) these days, I'll see if I can get > them whitelisted (or whatever it takes).=20 > > My understanding (having posted in haste to see the literature, > and Stan Ratliff also having asked for the specific posting) > from Thomas is that the detail is published, but buried in some > INRIA report. On the (extensive) list of things Thomas and I > plan to do when time permits (which I hope doesn't mean never, > but you knwo how it is) is including this, among other details, > in various informational material (nature of publication TBD) > we'd would really like to put out for the first time, or in a > more accessible form. But don't hold your breath! > > Thomas said (to me) he'd put this on the list, I'm not sure if > this is Philippe doing that for Thomas or independently. > > Of course you can ignore the issue, and things will probably > work most of the time. But do you accept that a known race > condition exists, or do you do something that avoids it? > (Note that you really should follow the advice that I know > is in OLSRv2, and I think is in RFC 3626, and although each > interface has an MPR Set, and the overall MPR Set is the > union, they should be calculated together, so that typically > there's no serious loss in flooding efficiency.) > > =20 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From hrogge@googlemail.com Mon Apr 6 08:25:32 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 195BE3A6C8F for ; Mon, 6 Apr 2009 08:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 xsL6IdDhdniV for ; Mon, 6 Apr 2009 08:25:19 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 281443A6CB0 for ; Mon, 6 Apr 2009 08:25:18 -0700 (PDT) Received: by ewy9 with SMTP id 9so1973253ewy.37 for ; Mon, 06 Apr 2009 08:26:23 -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=UeW7rOkxLJAl56SRjC+MTsMBnXzrcT1I0uPym+kMEkk=; b=GyqhfCBv1we+MbMha9grRZWLB5TeZooNhS31EUFVttGOHW2UPHeFa5pL1UhrcCbbKW lGJZp9dksIhkdoCJryP3zH+/WLuIB2BbNuUeTQsy/Wqpumi4EkMXFF1p7aX1OyNWq8pq /OhfObqNF+g1YiVXY0rcO5AUhqb/IvjlXElsg= 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=MlBwCawQKy9prioznMDxe1GE26Mjda7X9edsoBYabfUNKYVREGnfmUF65PnaVqOUJE pSGSLZWYjFjYC0EmamLb5TqLEmaJHFRyDRc3+egu8y0SvYOYuy2+NBat9MHwnF91ntKH RTxvo+aLGBHIWdZuzv+q0ctG0T8a0+eOV9h9g= Received: by 10.210.65.2 with SMTP id n2mr3038173eba.52.1239031583237; Mon, 06 Apr 2009 08:26:23 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 23sm6929819eya.46.2009.04.06.08.26.22 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Apr 2009 08:26:22 -0700 (PDT) From: Henning Rogge To: manet@ietf.org Date: Mon, 6 Apr 2009 17:26:16 +0200 User-Agent: KMail/1.11.1 (Linux/2.6.29-gentoo-r1; KDE/4.2.1; x86_64; ; ) References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <49D63C55.4070105@earthlink.net> <49DA0EFA.7080108@inria.fr> In-Reply-To: <49DA0EFA.7080108@inria.fr> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10159920.MLLcU4fKnm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904061726.21931.hrogge@googlemail.com> Cc: "Dearlove, Christopher \(UK\)" , jacquet Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 15:25:32 -0000 --nextPart10159920.MLLcU4fKnm Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Montag 06 April 2009 16:17:30 jacquet wrote: > Consider the following network > B-----D > / \ / \ > A \ / F > \ / \ / > C-----E =2E... > I think this was the issue (but I am not sure), but I agree that the > result was a kind of compromise to keep things simple. As soon as a routing metric enters the MPR selection it get's a little bit= =20 more complicated again. The "per interface to prevent bad links" concept=20 reminds me a little bit to the hysteresis part of OLSRv1. It was a compromi= se=20 to get a little bit more from the hopcount algorithm. On Montag 06 April 2009 16:38:08 Dearlove, Christopher (UK) wrote: > Actually of course you can run the algorithm on top of > anything else that has the necessary properties. But it > seemed appropriate in the IETF to make this IP. However > RFC 5444 allows any size address (1 to 32 octets). If > time ever permits, some sort of "where else you can use > this" may be appropriate. 1 to 16 octets, not 32. On Montag 06 April 2009 16:10:01 Dearlove, Christopher (UK) wrote: > > However, topology information must be complete. > > And that's why the "relay only" node needs a little care. > But we can give it that. Maybe we could use a phrase like "MUST contain all global routable IPs but = at=20 least one network-wide unique IP to address the node". Henning Rogge --nextPart10159920.MLLcU4fKnm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAknaHx0ACgkQcenvcwAcHWdv4gCeNPZh2Djtg22YZzF/SyCOiQmE aOIAn1OANMy6HSWv7gJJIfKK15ZMw7NB =uGLZ -----END PGP SIGNATURE----- --nextPart10159920.MLLcU4fKnm-- From chris.dearlove@baesystems.com Mon Apr 6 08:27:58 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 91A3F28C1B7 for ; Mon, 6 Apr 2009 08:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.616 X-Spam-Level: X-Spam-Status: No, score=-6.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, 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 2GryGdMTXc93 for ; Mon, 6 Apr 2009 08:27:57 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 61D5628C200 for ; Mon, 6 Apr 2009 08:27:57 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36FT1db019084 for ; Mon, 6 Apr 2009 16:29:01 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36FT1N5001542 for ; Mon, 6 Apr 2009 16:29:01 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 16:29:00 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 16:28:59 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Apr 2009 16:28:59 +0100 Message-ID: In-Reply-To: <00b801c9b6c9$ff9b9d80$fed2d880$@nrl.navy.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2wg1PPVfisuZzRb28a1WlPo6MQwABAgRgAAEtJ0A= References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> <200904021510.58935.rogge@fgan.de><010b01c9b445$91d94c10$b58be430$@nl> <011a01c9b45c$eed44750$cc7cd5f0$@nl> <49D63C55.4070105@earthlink.net><49DA0EFA.7080108@inria.fr> <00b801c9b6c9$ff9b9d80$fed2d880$@nrl.navy.mil> From: "Dearlove, Christopher (UK)" To: "Justin Dean" , X-OriginalArrivalTime: 06 Apr 2009 15:28:59.0948 (UTC) FILETIME=[687E96C0:01C9B6CC] Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 15:27:58 -0000 > Thank you Philippe you beat me to the rational for why MPR sets are chosen > per interface instead of aggregated across all interfaces of a node. I feel > that a good portion of the discussion going on about router id type of > behaviors are muddling topics between NHDP and OLSRv2 and specifically > routing in general. I may have been guilty of that. But in part deliberately. Although NHDP is a stand-alone protocol, it is also an essential underpinning of OLSRv2 (after all, it was part of OLSRv2 until we spun it out) and we need it not to become useles to OLSRv2 or, more subtlely, although (for some possible changes) apparently slightly more efficient as a stand-alone protocol, if all that saving and a lot more is lost in OLSRv2 (or in SMF) it would be a bad tradeoff. So you do need to consider OLSRv2 (and in this regard SMF is simpler or similar) as part of the question. > I would like to point out however that reintroducing a MID type of message > within OLSRv2 may be possible within the context of TC messages. There's a conceptual problem here that MID messages reported a node's own state. This appears good, but isn't, as it forces otherwise silent nodes to transmit. Furthermore there's much duplication of message headers. Putting all the work onto TC messages saves that. We don't bother in TC messages pointing out where information comes from the same node - for just routing, as long as it gets where it should go efficiently, we don't need to know that (although for any node that sends TC messages we do know that, in the Advertising Remote Router Set). > I would go > even further and say that empty update TC message saying "no change" might > be sufficient and more efficient.=20 Mostly that's not a good idea as you don't know if there are new remote nodes that need the information, and you also don't know about losses. But having said that, use of an incomplete TC message has some of that effect. (There is a detail there that you make me want to check.) ******************************************************************** 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 sratliff@cisco.com Mon Apr 6 08:31:03 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 57B033A6B59 for ; Mon, 6 Apr 2009 08:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 s0CvFNy68qVS for ; Mon, 6 Apr 2009 08:31:02 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 06CEB3A6C81 for ; Mon, 6 Apr 2009 08:31:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,331,1235952000"; d="scan'208";a="41037329" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 06 Apr 2009 15:32:07 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n36FW71o018182; Mon, 6 Apr 2009 11:32:07 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n36FW7nM002889; Mon, 6 Apr 2009 15:32:07 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 11:32:07 -0400 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: quoted-printable Date: Mon, 6 Apr 2009 11:32:06 -0400 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76407F6181B@xmb-rtp-208.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2yCihqwFmQv5xRn+tbkguxviccAAAjtkwAACQMRA= References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> <200904021510.58935.rogge@fgan.de><010b01c9b445$91d94c10$b58be430$@nl> <011a01c9b45c$eed44750$cc7cd5f0$@nl> <49D63C55.4070105@earthlink.net><49DA0EFA.7080108@inria.fr><49DA1959.2030908@inria.fr> From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" , "jacquet" X-OriginalArrivalTime: 06 Apr 2009 15:32:07.0296 (UTC) FILETIME=[D829A000:01C9B6CC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4778; t=1239031927; x=1239895927; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[manet]=20OLSRv2=20-=20RouterID |Sender:=20 |To:=20=22Dearlove,=20Christopher=20(UK)=22=20,=0A=20=20=20=20=20=20=20=20=22jacquet=22= 20; bh=lVNkZ624/4XbIXpf1abTPlAJCOXZ+bW2WnL5J8aO9lc=; b=ZyRNnTGODtBVcZH32E9d0POj/D6VS/IYFPRA6M3iGvVkiF2epNaehSeixX LO/HLfzIVoqG2mum8xzj9vtDbojoh6rRAvm6cErP5r9sKrC4SwP72KaJt1bb w/zGMOBC59; Authentication-Results: rtp-dkim-2; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 15:31:03 -0000 Chris,=20 I promise I'm not trying to be a rabble-rouser (at least this time = through... ;-). I was just wanting to understand the nature of the race = condition, and Philippe's email did a great job of explaining it.=20 Regards, Stan > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org]=20 > On Behalf Of Dearlove, Christopher (UK) > Sent: Monday, April 06, 2009 11:17 AM > To: jacquet > Cc: manet@ietf.org > Subject: Re: [manet] OLSRv2 - RouterID >=20 >=20 > I believe the consensus of the authors is that per interface=20 > is best, and we know why. But (based on that people like Stan=20 > and Charlie are asking the questions) although that this is=20 > the case is specified in OLSR, and every OLSRv2 draft I=20 > think, it's clearly not well known, and the reasons why are=20 > even less well known. >=20 > -- > Christopher Dearlove > Technology Leader, Communications Group > Networks, Security and Information Systems Department BAE=20 > Systems Advanced Technology Centre West Hanningfield Road,=20 > Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 Fax: +44 1245 242124 >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough=20 > Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered=20 > in England & Wales No: 1996687 >=20 > -----Original Message----- > From: jacquet [mailto:philippe.jacquet@inria.fr] > Sent: 06 April 2009 16:02 > To: Dearlove, Christopher (UK) > Cc: Charles E. Perkins; manet@ietf.org > Subject: Re: [manet] OLSRv2 - RouterID >=20 >=20 > *** WARNING *** >=20 > This mail has originated outside your organization, > either from an external partner or the Global Internet.=20 > Keep this in mind if you answer this message.=20 >=20 > Chris, >=20 > How do you filter Charlie? I thought it was impossible;-) In=20 > exchange I=20 > will show you how I can filter Thomas. >=20 > To be per interface or not per interface is not just a formal=20 > issue, it=20 > has impact on performance. Charlie was right to refresh this=20 > issue. But=20 > I understood that the main stream of the discussion is now=20 > mostly on the=20 > advertizement of routerID. And there is a kind of agreement that MPR=20 > selection should be done on a per interface basis. Am I right? But I=20 > wanted to be sure that no misunderstanding remains. >=20 > Best regards, > Philippe >=20 >=20 >=20 > Dearlove, Christopher (UK) a =E9crit : > > Charlie > > > > Didn't see your message until Philippe replied. For some reason > > I think you are filtered out here - I never see your postings > > these days (I used to) only replies to them. What email address > > is your usual one (or ones) these days, I'll see if I can get > > them whitelisted (or whatever it takes).=20 > > > > My understanding (having posted in haste to see the literature, > > and Stan Ratliff also having asked for the specific posting) > > from Thomas is that the detail is published, but buried in some > > INRIA report. On the (extensive) list of things Thomas and I > > plan to do when time permits (which I hope doesn't mean never, > > but you knwo how it is) is including this, among other details, > > in various informational material (nature of publication TBD) > > we'd would really like to put out for the first time, or in a > > more accessible form. But don't hold your breath! > > > > Thomas said (to me) he'd put this on the list, I'm not sure if > > this is Philippe doing that for Thomas or independently. > > > > Of course you can ignore the issue, and things will probably > > work most of the time. But do you accept that a known race > > condition exists, or do you do something that avoids it? > > (Note that you really should follow the advice that I know > > is in OLSRv2, and I think is in RFC 3626, and although each > > interface has an MPR Set, and the overall MPR Set is the > > union, they should be calculated together, so that typically > > there's no serious loss in flooding efficiency.) > > > > =20 >=20 >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 From chris.dearlove@baesystems.com Mon Apr 6 08:37:57 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 9C1BD3A6C93 for ; Mon, 6 Apr 2009 08:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.615 X-Spam-Level: X-Spam-Status: No, score=-6.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, 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 VYI9lrNux+ST for ; Mon, 6 Apr 2009 08:37:56 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 736473A6C79 for ; Mon, 6 Apr 2009 08:37:56 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36Fd0L8028931 for ; Mon, 6 Apr 2009 16:39:00 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36Fd0Ju018053 for ; Mon, 6 Apr 2009 16:39:00 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 16:39:00 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 16:38:59 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Apr 2009 16:38:59 +0100 Message-ID: In-Reply-To: <200904061726.21931.hrogge@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2zAzpDlN2fPwGQTK9FOOhKfck8AAAOpJg References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <49D63C55.4070105@earthlink.net> <49DA0EFA.7080108@inria.fr> <200904061726.21931.hrogge@googlemail.com> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 06 Apr 2009 15:38:59.0979 (UTC) FILETIME=[CE240DB0:01C9B6CD] Cc: jacquet Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 15:37:57 -0000 > As soon as a routing metric enters the MPR selection it get's a little bit=20 > more complicated again. Indeed. See draft-dearlove-olsrv2-metrics-03. There we have had to separate routing and flooding MPRs (only the latter needing to be per interface) and the concept of strictly two hop gets messy. the draft contains what should be complete algorithms - if you think there's anything missing, now would be a great time to know. > 1 to 16 octets, not 32. > Maybe we could use a phrase like "MUST contain all global routable IPs but at=20 > least one network-wide unique IP to address the node". There's at least one more detail needed (which address(es) - changing selection shouldn't be done unnecessarily and must change ANSN) that needs some thought. Possibly the solution involves using the originator address, but more thought needed to get it right. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From chris.dearlove@baesystems.com Mon Apr 6 08:46:24 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 C2F653A6C79 for ; Mon, 6 Apr 2009 08:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.615 X-Spam-Level: X-Spam-Status: No, score=-6.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, 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 zqRlHZY9NqPy for ; Mon, 6 Apr 2009 08:46:23 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 662153A6CB7 for ; Mon, 6 Apr 2009 08:46:23 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n36FlRFp025683 for ; Mon, 6 Apr 2009 16:47:27 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n36FlR7E022522 for ; Mon, 6 Apr 2009 16:47:27 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 06 Apr 2009 16:47:26 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Apr 2009 16:47:26 +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: Mon, 6 Apr 2009 16:47:25 +0100 Message-ID: In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76407F6181B@xmb-rtp-208.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID Thread-Index: Acm2yCihqwFmQv5xRn+tbkguxviccAAAjtkwAACQMRAAAEtm8A== References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> <200904021510.58935.rogge@fgan.de><010b01c9b445$91d94c10$b58be430$@nl> <011a01c9b45c$eed44750$cc7cd5f0$@nl> <49D63C55.4070105@earthlink.net><49DA0EFA.7080108@inria.fr><49DA1959.2030908@inria.fr> <7FB7EE0A621BA44B8B69E5F0A09DC76407F6181B@xmb-rtp-208.amer.cisco.com> From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , "jacquet" X-OriginalArrivalTime: 06 Apr 2009 15:47:26.0732 (UTC) FILETIME=[FC306CC0:01C9B6CE] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 15:46:24 -0000 I took your question exactly as you indicated. If I appeared to suggest otherwise, my apologies.=20 It is a tricky subject. My first semi-public work on OLSR was commenting to the authors on drafts. And one suggestion I made involved simplifying away this case, before someone from the INRIA team (I think it was Cedric Adjih) dug up the race condition case. So I've also been there, done that. It's also worth clarifying what needs (in the sense that we ae considering here) to be per interface. First without metrics - MPR selection, yes, but take union. - MPR selectors, no. - MPR Relay Set selection, is currently per interface (superset of MPR selectors). With metrics - For routing, no. - For flooding, as without metrics (although can use them) but we're intending to cut the Gordian knot and scrap the Relay Sets, using only MPR selectors, so, no for usage (but yes for selection). --=20 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: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: 06 April 2009 16:32 To: Dearlove, Christopher (UK); jacquet Cc: manet@ietf.org Subject: RE: [manet] OLSRv2 - RouterID *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Chris,=20 I promise I'm not trying to be a rabble-rouser (at least this time = through... ;-). I was just wanting to understand the nature of the race = condition, and Philippe's email did a great job of explaining it.=20 Regards, Stan > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org]=20 > On Behalf Of Dearlove, Christopher (UK) > Sent: Monday, April 06, 2009 11:17 AM > To: jacquet > Cc: manet@ietf.org > Subject: Re: [manet] OLSRv2 - RouterID >=20 >=20 > I believe the consensus of the authors is that per interface=20 > is best, and we know why. But (based on that people like Stan=20 > and Charlie are asking the questions) although that this is=20 > the case is specified in OLSR, and every OLSRv2 draft I=20 > think, it's clearly not well known, and the reasons why are=20 > even less well known. >=20 > -- > Christopher Dearlove > Technology Leader, Communications Group > Networks, Security and Information Systems Department BAE=20 > Systems Advanced Technology Centre West Hanningfield Road,=20 > Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 Fax: +44 1245 242124 >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough=20 > Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered=20 > in England & Wales No: 1996687 >=20 > -----Original Message----- > From: jacquet [mailto:philippe.jacquet@inria.fr] > Sent: 06 April 2009 16:02 > To: Dearlove, Christopher (UK) > Cc: Charles E. Perkins; manet@ietf.org > Subject: Re: [manet] OLSRv2 - RouterID >=20 >=20 > *** WARNING *** >=20 > This mail has originated outside your organization, > either from an external partner or the Global Internet.=20 > Keep this in mind if you answer this message.=20 >=20 > Chris, >=20 > How do you filter Charlie? I thought it was impossible;-) In=20 > exchange I=20 > will show you how I can filter Thomas. >=20 > To be per interface or not per interface is not just a formal=20 > issue, it=20 > has impact on performance. Charlie was right to refresh this=20 > issue. But=20 > I understood that the main stream of the discussion is now=20 > mostly on the=20 > advertizement of routerID. And there is a kind of agreement that MPR=20 > selection should be done on a per interface basis. Am I right? But I=20 > wanted to be sure that no misunderstanding remains. >=20 > Best regards, > Philippe >=20 >=20 >=20 > Dearlove, Christopher (UK) a =E9crit : > > Charlie > > > > Didn't see your message until Philippe replied. For some reason > > I think you are filtered out here - I never see your postings > > these days (I used to) only replies to them. What email address > > is your usual one (or ones) these days, I'll see if I can get > > them whitelisted (or whatever it takes).=20 > > > > My understanding (having posted in haste to see the literature, > > and Stan Ratliff also having asked for the specific posting) > > from Thomas is that the detail is published, but buried in some > > INRIA report. On the (extensive) list of things Thomas and I > > plan to do when time permits (which I hope doesn't mean never, > > but you knwo how it is) is including this, among other details, > > in various informational material (nature of publication TBD) > > we'd would really like to put out for the first time, or in a > > more accessible form. But don't hold your breath! > > > > Thomas said (to me) he'd put this on the list, I'm not sure if > > this is Philippe doing that for Thomas or independently. > > > > Of course you can ignore the issue, and things will probably > > work most of the time. But do you accept that a known race > > condition exists, or do you do something that avoids it? > > (Note that you really should follow the advice that I know > > is in OLSRv2, and I think is in RFC 3626, and although each > > interface has an MPR Set, and the overall MPR Set is the > > union, they should be calculated together, so that typically > > there's no serious loss in flooding efficiency.) > > > > =20 >=20 >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 From ogier@earthlink.net Mon Apr 6 10:46: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 51C143A6D2F for ; Mon, 6 Apr 2009 10:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[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 H4x96pyUK2qv for ; Mon, 6 Apr 2009 10:46:14 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 4588828C244 for ; Mon, 6 Apr 2009 10:45:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=RmPjppJDxitF0O5oxYmwQoYBvvLBALGbePp35musLASzRHrhGLq2APZNbRG3x0JP; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.221.32] by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LqsuI-0007wO-RE for manet@ietf.org; Mon, 06 Apr 2009 13:46:52 -0400 Message-ID: <49DA4085.5030002@earthlink.net> Date: Mon, 06 Apr 2009 10:48:53 -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: manet@ietf.org References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <200904021444.34251.rogge@fgan.de> <200904021510.58935.rogge@fgan.de><010b01c9b445$91d94c10$b58be430$@nl> <011a01c9b45c$eed44750$cc7cd5f0$@nl> <49D63C55.4070105@earthlink.net> <49DA0EFA.7080108@inria.fr> In-Reply-To: <49DA0EFA.7080108@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4787bfcd67ff3a01a6ef60762e32dc809b43ae88e86ea6b818e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.221.32 Subject: Re: [manet] OLSRv2 - RouterID 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, 06 Apr 2009 17:46:21 -0000 The race condition that Philippe described can also occur with a single interface under certain conditions. For example, suppose a MAC protocol is used that decides to "multicast" a packet by unicasting it to each neighbor, one at a time. (In some cases, this might be more efficient if there are only 2 or 3 neighbors.) Then, in Philippe's example, it is still possible for nodes D and E to receive the packet from non-MPR selector neighbors and thus not forward the packet. (Such a situation can also occur in networks with very long propagation delays, such as satellite networks, due to delay differences, but perhaps that is out of scope.) So it might be worthwhile to modify the MPR selection or the MPR flooding mechanism in order to allow the above situation. This is one of a number of drawbacks of MPRs that led me to use CDS flooding instead of MPR flooding for the MANET extension of OSPF. Richard jacquet wrote: > Hello, Charlie, > > Your question is very pertinent. This was indeed an old discussion, > that I merely forgot. It was based on the principle that if interfaces > differ too much in performance you may have uncontrolled effects, and > it was difficult to taylor a proper mechanism for each special cases. > > One special case: assume that you have two kinds of interfaces: slow > and fast. If slow means very slow, then you may have a very long > flooding time for a single packet if you merge interfaces for MPR > selection. You may even have no end at all;-) > > Consider the following network > B-----D > / \ / \ > A \ / F > \ / \ / > C-----E > with all interfaces of type fast excepted (B,D) and (C,E), that are > slow. If all interfaces are merged for MPR calculation, then it can be > that MPR of B and C are all on slow interface. > > Suppose MPRs of A are both B and C (there may be additional neighbors > on B and C to force that). > > If A initiates a flood, then B and C will retransmit simultaneously > on fast interface and slow interface, but fast interface arrives first > on D and E, both receive first from non MPR and cannot relay. F does > not receive the broadcast. > > When D or E eventually receive from the slow interface it could > compare time stamps to actually decide that slow interface indeed had > precedence on fast interface in race competition and finally to decide > to actually retransmit. But again you come out with the performance of > the worse interface (and a very complicated mechanism). > > If MPR are on per interface, then B will select E as MPR on fast > interface > and you gain on the fastest interface which will win the race > competition. > > I think this was the issue (but I am not sure), but I agree that the > result was a kind of compromise to keep things simple. > > Best regards, > Philippe > > Charles E. Perkins a écrit : > >> >> Hello Chris, >> >> Comments below... >> >> Dearlove, Christopher (UK) wrote: >> >>> >>> >>>> I don't understand this. The requirement is that the set >>>> of MPRs must provide connectivity to all 2-hop neighbors >>>> >>> >>> >>> That's not sufficient. >>> >> >> >> I believe this is highly debatable. >> >>> >>> >>>> o Why MPR selection per interface? >>>> >>> >>> >>> Read the literature. And yes, that is me not putting in the effort >>> to point out the race condition case and why per interface avoids >>> it and per router doesn't (a subtlety in the MPR flooding proof). >>> >> >> >> I read the proofs, albeit a couple of years ago, and I don't remember >> anything particular about this point. Too bad I can't go back and >> review >> this material today. >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From teco@inf-net.nl Mon Apr 6 12:49: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 B0AFB3A6C70 for ; Mon, 6 Apr 2009 12:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[AWL=-0.309, 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 p0+iaFCNLuwe for ; Mon, 6 Apr 2009 12:49:30 -0700 (PDT) Received: from CPSMTPM-EML108.kpnxchange.com (Cpsmtpm-eml108.kpnxchange.com [195.121.3.12]) by core3.amsl.com (Postfix) with ESMTP id A4F823A691C for ; Mon, 6 Apr 2009 12:49:29 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML108.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Mon, 6 Apr 2009 21:50:34 +0200 From: "Teco Boot" To: "'manet'" References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> In-Reply-To: <00c701c9b38e$18e7eb70$4ab7c250$@nl> Date: Mon, 6 Apr 2009 21:50:33 +0200 Message-ID: <000601c9b6f0$f2ca99e0$d85fcda0$@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: Acmzjhiu+S5GKrDTRq+BhF9qRRbt7QDYQptQ Content-Language: nl X-OriginalArrivalTime: 06 Apr 2009 19:50:34.0196 (UTC) FILETIME=[F2FEC940:01C9B6F0] Subject: Re: [manet] OLSRv2 - RouterID - Q1 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, 06 Apr 2009 19:49:36 -0000 Thanks for all the information on the list. It is very helpful understanding what we have. Back to my questions, some are not answered yet. |I have a question on: | |> OLSRv2 does not make any assumption about router addresses, other |> than that each router is assumed to have at least one unique and |> routable IP address for each interface that it has which participates |> in the MANET. | |Why is this? It excludes usage of link local addresses. I do not see a |hard |reason not using LLs, as long as they are unique in the MANET Routing |Domain. And LLs are not routable. I can imagine a MANET with some MANET routers with only LL addresses, as transit for other nodes. These routers would have (IPv6) LLs only. When LLs are unique (e.g. using unique Interface IDs), this would not cause any problem with current specification. Why routable ? Or: what is routable ? On uniqueness and LLs I'll open another thread. Teco. From teco@inf-net.nl Mon Apr 6 13:29:26 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 5EA3E3A6D4D for ; Mon, 6 Apr 2009 13:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.441, 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 XrID01Eeay01 for ; Mon, 6 Apr 2009 13:29:21 -0700 (PDT) Received: from CPSMTPM-EML110.kpnxchange.com (Cpsmtpm-eml110.kpnxchange.com [195.121.3.14]) by core3.amsl.com (Postfix) with ESMTP id A2A513A6D4A for ; Mon, 6 Apr 2009 13:29:19 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML110.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Mon, 6 Apr 2009 22:30:24 +0200 From: "Teco Boot" To: "'manet'" References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> In-Reply-To: <00c701c9b38e$18e7eb70$4ab7c250$@nl> Date: Mon, 6 Apr 2009 22:30:24 +0200 Message-ID: <000701c9b6f6$83ee1c80$8bca5580$@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: Acmzjhiu+S5GKrDTRq+BhF9qRRbt7QDYt3sw Content-Language: nl x-cr-hashedpuzzle: AqpC AylT A+LC BtSJ C0Rm DAAG Eprf E64I FOQ3 FXA+ GSyD GfLa H7GT IdnW IeUj Iy1I; 1; bQBhAG4AZQB0AEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {4007A22F-3B9D-4C5B-AC63-B5607DB89E2A}; dABlAGMAbwBAAGkAbgBmAC0AbgBlAHQALgBuAGwA; Mon, 06 Apr 2009 20:30:20 GMT; UgBFADoAIABbAG0AYQBuAGUAdABdACAATwBMAFMAUgB2ADIAIAAtACAAUgBvAHUAdABlAHIASQBEACAALQAgAFEAMgA= x-cr-puzzleid: {4007A22F-3B9D-4C5B-AC63-B5607DB89E2A} X-OriginalArrivalTime: 06 Apr 2009 20:30:24.0935 (UTC) FILETIME=[83FC9B70:01C9B6F6] Subject: Re: [manet] OLSRv2 - RouterID - Q2 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, 06 Apr 2009 20:29:26 -0000 My second question is why MANET unique addresses on interfaces are needed. I think the discussion is drifted to MPR selection "per interface" or "over all interfaces". My suggestion using RouterID leaves this open. In my proposal with RouterID, NHDP info is available per segment (or per interface, if one prefers this term), so MPR selection can be done per segment. I included "ifIndex" in the tables below to demonstrate the "per interface" state. I adjusted the info below, it still needs verification. The TC information is "per MANET", as its purpose is SPF calculation finding the next hop for advertized prefixes. Details on multiple links between nodes and 2-hop neighborhood is not needed for that. As Henning suggested, this idea could be implemented based on current spec as nothing really changes. It is just a matter of housekeeping available information (also to be verified). Teco. |For SPF calculation, only identifiers for the nodes and their links are |needed. A straightforward approach would be unique router identifiers |within |the routing domain and unique interface identifiers within the scope of |each |router. For the latter, ifIndex could be used and single octet provides |namespace for 256 interfaces using continuous numbering. One may think |of |extended numbering. A link is identified by a 4-tuple of RouterID and a |interface identifier, for itself and the neighbor. I don't think the |interface identifiers are needed in the NHDP and OLSRv2 messages. | |I think the problems can be circumvented by using the following |information |bases, for NHDP and OLSRv2: |(to be verified) | |Local Information Base | Local Interface Set | ifIndex # added | I_local_iface_addr # | I_manet | Removed Interface Address Set | ifIndex # added | IR_local_iface_addr | IR_time | Originator Set # not required if orig_addr is stable | O_orig_addr | O_time | Local Attached Network Set | AL_net_addr | AL_dist | |Interface Information Bases | Link Set | ifIndex # added | L_orig_addr # | # L_ifIndex not needed !! | L_HEARD_time | L_SYM_time | L_quality | L_pending | L_lost | L_time | 2-Hop Set | ifIndex # added | N2_orig_addr # | # L_ifIndex not needed !! | N2_2H_orig_addr | N2_time | |Neighbor Information Base | Neighbor Set >>> ifIndex # added | N_orig_addr # | N_symmetric | N_willingness | N_mpr | N_mpr_selector | Lost Neighbor Set >>> ifIndex # added | NL_orig_addr # | NL_time | |Topology Information Base | Advertised Neighbor Set | A_orig_addr # | Advertising Remote Router Set | AR_orig_addr # | AR_seq_number | AR_time | Topology Set | T_dest_orig_addr # | T_orig_addr | T_seq_number | T_time | Attached Network Set | AN_net_addr | AN_orig_addr | AN_dist | AN_seq_number | AN_time | Routing Set | R_dest_addr | R_next_iface_addr | R_dist | R_local_ifIndex # | |Processing and Forwarding Information Base | Received Set | RX_type | RX_orig_addr | RX_seq_number | RX_time | Processed Set | P_type | P_orig_addr | P_seq_number | P_time | Forwarded Set | F_type | F_orig_addr | F_seq_number | F_time | Relay Set >>> ifIndex # added | RY_neighbor_orig_addr # | | |As a result, the NHDP hello messages must contain msg-orig-addr (may be |suppressed if IP header source address is msg-orig-addr). This may be a |small increase of the size of the packets. But other messages would be |largely reduced in size, as not ALL addresses are advertized anymore. |Each |router identifier (orig-addr) represents all addresses of all interfaces |of the router. From teco@inf-net.nl Mon Apr 6 14:05:58 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 440133A682D for ; Mon, 6 Apr 2009 14:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 qh9w81kZpeJc for ; Mon, 6 Apr 2009 14:05:52 -0700 (PDT) Received: from CPSMTPM-EML110.kpnxchange.com (Cpsmtpm-eml110.kpnxchange.com [195.121.3.14]) by core3.amsl.com (Postfix) with ESMTP id 8B7CB3A6CCE for ; Mon, 6 Apr 2009 14:05:52 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML110.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Mon, 6 Apr 2009 23:06:57 +0200 From: "Teco Boot" To: "'manet'" Date: Mon, 6 Apr 2009 23:06:57 +0200 Message-ID: <000801c9b6fb$9f003fd0$dd00bf70$@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: Acm2+57V+9jQrp/dTnSPPsOLoHU32g== Content-Language: nl X-OriginalArrivalTime: 06 Apr 2009 21:06:57.0803 (UTC) FILETIME=[9F09B5B0:01C9B6FB] Subject: [manet] OLSRv2 and forwarding based on MPR 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, 06 Apr 2009 21:05:58 -0000 Other questions, now on forwarding. -08 - page 26 describes the algorithm. After: > 2. Otherwise: > 1. Create a Received Tuple in the Received Set for the > receiving interface with: Comes: > 2. If a Forwarded Tuple exists with: This is strange. If the tuple was not received before, how can the Forwarded Tuple exist? (assume no buggy olsr code:-) And the message is not forwarded if the upstream node was not the MPR selector, correct? For forwarding in the same segment (same interface), this would be correct. But I think that forwarding on other interfaces must take place under many more conditions. I would say, if a message is processed, other nodes in the neighborhood should also receive this message. Within the segment, it's OK that only MPRs take care of forwarding. But for other segments, I do not see a relation with MPRs, especially when MPRs are per interface. _R4 / R1-----------R2-------\ \ | | -------R3-------R5 * **R6 Line: segment 1 Asterisk: segment 2 R2 is MPR for R1 (link to R4 and R5, R3 has not). R3 does not forward TC from R1, as R1 is not MPR selector. Ditto for TC from R2 and R5. But who forwards the TC to R6? I guess I overlook something here. Teco. From philippe.jacquet@inria.fr Tue Apr 7 00:13: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 04B253A6CDD for ; Tue, 7 Apr 2009 00:13:38 -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 CiHzwXGcvh55 for ; Tue, 7 Apr 2009 00:13:37 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id AA2363A6CC9 for ; Tue, 7 Apr 2009 00:13:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,336,1235948400"; d="scan'208";a="38009917" Received: from avelizy-152-1-80-223.w86-217.abo.wanadoo.fr (HELO [192.168.0.3]) ([86.217.75.223]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Apr 2009 09:14:40 +0200 Message-ID: <49DAFD5F.6000007@inria.fr> Date: Tue, 07 Apr 2009 09:14:39 +0200 From: Philippe Jacquet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Teco Boot References: <000801c9b6fb$9f003fd0$dd00bf70$@nl> In-Reply-To: <000801c9b6fb$9f003fd0$dd00bf70$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 'manet' Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 07 Apr 2009 07:13:38 -0000 Dear Teco, In your example R6 is indeed in N2(I) of R1, since it can be reached via R3. Thus R3 is MPR of R1. R3 must be on I from R1 to be on N(I), but R6 does not need to be on I in order to be on N2(I). N2(I) contains all nodes that can be reached from those that are in N(I), indifferently of the interface. Best regards, Philippe Teco Boot a écrit : > Other questions, now on forwarding. > -08 - page 26 describes the algorithm. > > After: >> 2. Otherwise: >> 1. Create a Received Tuple in the Received Set for the >> receiving interface with: > > Comes: >> 2. If a Forwarded Tuple exists with: > > This is strange. If the tuple was not received before, how can the Forwarded > Tuple exist? (assume no buggy olsr code:-) > > > And the message is not forwarded if the upstream node was not the MPR > selector, correct? > For forwarding in the same segment (same interface), this would be correct. > But I think that forwarding on other interfaces must take place under many > more conditions. I would say, if a message is processed, other nodes in the > neighborhood should also receive this message. Within the segment, it's OK > that only MPRs take care of forwarding. But for other segments, I do not see > a relation with MPRs, especially when MPRs are per interface. > > _R4 > / > R1-----------R2-------\ > \ | | > -------R3-------R5 > * > **R6 > > Line: segment 1 > Asterisk: segment 2 > R2 is MPR for R1 (link to R4 and R5, R3 has not). > R3 does not forward TC from R1, as R1 is not MPR selector. > Ditto for TC from R2 and R5. > But who forwards the TC to R6? > > I guess I overlook something here. > > > Teco. > > > > > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > From Rogge@fgan.de Tue Apr 7 00:22: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 CED863A6D83 for ; Tue, 7 Apr 2009 00:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=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 iHV8GBZH1WZ6 for ; Tue, 7 Apr 2009 00:22:04 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id E92D03A6816 for ; Tue, 7 Apr 2009 00:20:44 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Lr5cz-0006zM-01; Tue, 07 Apr 2009 09:21:49 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1Lr5cy-0006LH-Ig; Tue, 07 Apr 2009 09:21:48 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 09:21:48 +0200 From: Henning Rogge To: manet@ietf.org Date: Tue, 7 Apr 2009 09:21:42 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.26-1-openvz-686; KDE/4.1.4; i686; ; ) References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <000601c9b6f0$f2ca99e0$d85fcda0$@nl> In-Reply-To: <000601c9b6f0$f2ca99e0$d85fcda0$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart42730206.8ODh3hvlrh"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904070921.48076.rogge@fgan.de> X-OriginalArrivalTime: 07 Apr 2009 07:21:48.0542 (UTC) FILETIME=[83A1C1E0:01C9B751] X-Virus-Scanned: yes (ClamAV 0.94.2/9210/Tue Apr 7 05:34:45 2009) by mailguard.fgan.de X-Scan-Signature: ff96b43a3b0bdca915144ec1b58e50d3 Subject: Re: [manet] OLSRv2 - RouterID - Q1 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, 07 Apr 2009 07:22:11 -0000 --nextPart42730206.8ODh3hvlrh Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Monday 06 April 2009 21:50:33 schrieb Teco Boot: > I can imagine a MANET with some MANET routers with only LL addresses, as > transit for other nodes. These routers would have (IPv6) LLs only. When L= Ls > are unique (e.g. using unique Interface IDs), this would not cause any > problem with current specification. > > Why routable ? > Or: what is routable ? I think a routable address is one that you can reach through multiple hops = in=20 the entire net. An address you can only access from one hop away would not = be=20 routable because of the configuration of the OLSR network. Henning ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart42730206.8ODh3hvlrh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkna/wYACgkQRIfGfFXsz+AF9ACgjwxqFUKOCHV9YNhgrsvpOTSM 318An09DX6ezKwq1gs1shmC9F3syaziJ =0Sip -----END PGP SIGNATURE----- --nextPart42730206.8ODh3hvlrh-- From chris.dearlove@baesystems.com Tue Apr 7 01:55:00 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 D657C28C161 for ; Tue, 7 Apr 2009 01:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.615 X-Spam-Level: X-Spam-Status: No, score=-6.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, 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 OOGP86vnHt4r for ; Tue, 7 Apr 2009 01:55:00 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id CA47F28C175 for ; Tue, 7 Apr 2009 01:54:59 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n378u3Ic007307 for ; Tue, 7 Apr 2009 09:56:03 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n378u3xB008086 for ; Tue, 7 Apr 2009 09:56:03 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 07 Apr 2009 09:56:03 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 7 Apr 2009 09:56:02 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 7 Apr 2009 09:56:00 +0100 Message-ID: In-Reply-To: <000801c9b6fb$9f003fd0$dd00bf70$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 and forwarding based on MPR Thread-Index: Acm2+57V+9jQrp/dTnSPPsOLoHU32gAYqiHg References: <000801c9b6fb$9f003fd0$dd00bf70$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "manet" X-OriginalArrivalTime: 07 Apr 2009 08:56:02.0910 (UTC) FILETIME=[ADE5D7E0:01C9B75E] Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 07 Apr 2009 08:55:00 -0000 >After: >> 2. Otherwise: >> 1. Create a Received Tuple in the Received Set for the >> receiving interface with: >Comes: >> 2. If a Forwarded Tuple exists with: > This is strange. If the tuple was not received before, how can the Forwarded > Tuple exist? (assume no buggy olsr code:-) Because there's a Received Set per interface. It even says so in what you've quoted. This case can happens if you haven't previously received on this interface, but have on another and the forwarded. No buggy OLSRv2 code needed. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From chris.dearlove@baesystems.com Tue Apr 7 02:24:18 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 C5B743A6823 for ; Tue, 7 Apr 2009 02:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.615 X-Spam-Level: X-Spam-Status: No, score=-6.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, 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 2wK64N1il-p2 for ; Tue, 7 Apr 2009 02:24:18 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 6352F3A67FD for ; Tue, 7 Apr 2009 02:24:17 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n379PL0v026739 for ; Tue, 7 Apr 2009 10:25:21 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n379PLVG028384 for ; Tue, 7 Apr 2009 10:25:21 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 07 Apr 2009 10:25:19 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 7 Apr 2009 10:25:19 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 7 Apr 2009 10:25:18 +0100 Message-ID: In-Reply-To: <000601c9b6f0$f2ca99e0$d85fcda0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - RouterID - Q1 Thread-Index: Acmzjhiu+S5GKrDTRq+BhF9qRRbt7QDYQptQABzeXEA= References: <00c701c9b38e$18e7eb70$4ab7c250$@nl> <000601c9b6f0$f2ca99e0$d85fcda0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "manet" X-OriginalArrivalTime: 07 Apr 2009 09:25:19.0097 (UTC) FILETIME=[C4AAB690:01C9B762] Subject: Re: [manet] OLSRv2 - RouterID - Q1 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, 07 Apr 2009 09:24:18 -0000 I think this is part of the tidying up and relaxing some details in OLSRv2 (but doesn't affect NHDP) that we are (I think) all agreed is in order. --=20 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: 06 April 2009 20:51 To: 'manet' Subject: Re: [manet] OLSRv2 - RouterID - Q1 *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Thanks for all the information on the list. It is very helpful understanding what we have. Back to my questions, some are not answered yet. =20 |I have a question on: | |> OLSRv2 does not make any assumption about router addresses, other |> than that each router is assumed to have at least one unique and |> routable IP address for each interface that it has which participates |> in the MANET. | |Why is this? It excludes usage of link local addresses. I do not see a |hard |reason not using LLs, as long as they are unique in the MANET Routing |Domain. And LLs are not routable. I can imagine a MANET with some MANET routers with only LL addresses, as transit for other nodes. These routers would have (IPv6) LLs only. When LLs are unique (e.g. using unique Interface IDs), this would not cause any problem with current specification. Why routable ? Or: what is routable ? On uniqueness and LLs I'll open another thread. 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. ******************************************************************** From chris.dearlove@baesystems.com Tue Apr 7 07:30: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 AF4373A6CFD for ; Tue, 7 Apr 2009 07:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.614 X-Spam-Level: X-Spam-Status: No, score=-6.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, 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 EC0jnRx6zsXo for ; Tue, 7 Apr 2009 07:30:35 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id A4D7F3A6C22 for ; Tue, 7 Apr 2009 07:30:34 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n37EVdsl020607 for ; Tue, 7 Apr 2009 15:31:39 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n37EVcO9008238 for ; Tue, 7 Apr 2009 15:31:38 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 07 Apr 2009 15:31:38 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 7 Apr 2009 15:31:38 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 7 Apr 2009 15:31:37 +0100 Message-ID: In-Reply-To: <000801c9b6fb$9f003fd0$dd00bf70$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OLSRv2 and forwarding based on MPR Thread-Index: Acm2+57V+9jQrp/dTnSPPsOLoHU32gAkMQFQ References: <000801c9b6fb$9f003fd0$dd00bf70$@nl> From: "Dearlove, Christopher (UK)" To: "manet" X-OriginalArrivalTime: 07 Apr 2009 14:31:38.0670 (UTC) FILETIME=[8FBEFCE0:01C9B78D] Subject: [manet] OLSRv2 and forwarding based on MPR 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, 07 Apr 2009 14:30:35 -0000 (This is not properly threaded, as it seems this email system doesn't like Richard as well as Charlie. I was actually checking the archive for any postings by Charlie.) Richard Ogier > The race condition that Philippe described can also occur with > a single interface under certain conditions. For example, > suppose a MAC protocol is used that decides to "multicast"=20 > a packet by unicasting it to each neighbor, one at a time. This is also a well-known result. But I do not view it as a real issue here, as I believe the cases of interest will use real wireless broadcast. The general multiple unicasting solution does not scale well (though there are approaches - I've implemented at least one) that can win back some of your loss. > (In some cases, this might be more efficient if there are only 2 or 3 > neighbors.) And you know who they are. As one of the points of NHDP is to find your neighbours, which rules out this approach. > So it might be worthwhile to modify the MPR selection or the > MPR flooding mechanism in order to allow the above situation. In this case, I don't think so. In others, this can be so. ******************************************************************** 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 mustafa_irbid@yahoo.com Tue Apr 7 12:15: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 726E03A6843 for ; Tue, 7 Apr 2009 12:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 bQ0d2dvTBC2K for ; Tue, 7 Apr 2009 12:15:34 -0700 (PDT) Received: from web52306.mail.re2.yahoo.com (web52306.mail.re2.yahoo.com [206.190.48.149]) by core3.amsl.com (Postfix) with SMTP id 15A7A3A680C for ; Tue, 7 Apr 2009 12:15:33 -0700 (PDT) Received: (qmail 87594 invoked by uid 60001); 7 Apr 2009 19:16:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1239131800; bh=ckFK00+rSmdcAw0eAyAzBLrfJCsgdf/5nho6VsSxS5k=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Qgf+YPXW4E0ds0IDFyLx4AQAeWusp3OKkxHFKosD9ckO/vs6EAIihkcU2nQMnuL1Sn3QDBtHL/PzZMBvGRYyIIF6mSixdbQkmFVaXwnbK3ONjcgiAQ/6avGX/OHE8sa0etSUhHbAtGWtwRCMGeIyEGZucbQOCUF+zUMrn4Alqck= 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:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=cXzDe0HwM7AeLO+3IkDYzIJY/H/dLKfrFvyqW84e/2WiTdJMzm5WYnI3/PSRr8vPkTb8xMzbBTBU6Bz8YtQ/ofLPqe1VfLgPHtSNSss+ZAdP2ZBCvJV+pQUFEO1BOAII6nYug1RZpIqbPT55JxcnMMTMoKfBBnIIdoT+A1xlNws=; Message-ID: <322980.84812.qm@web52306.mail.re2.yahoo.com> X-YMail-OSG: EeWhE7EVM1nJgVyPvCPiAqNgdnWsotE13QvAYH_1BmSAOIf.lPcIRSDM5Qv2RGT0lZsCpVYDd2bSGY..sgzenLnMt0.FwWEqQAdfVQDO9P6hdAj70izFT9YKWBUnWDqUZxAMGIw.nHntR9eySvuO6_SrKoAVRkuov3AVinBldFKsqIhOGQ5e_MFwdJ3PPy2eBNM8geuipTlGOVQ8mXOosPVzee1G5rnnOEfk5yjmxT1u2.5sVdmWxOLhUgJe.bzBySYL5akHWfgNzKYxsrhdjAN.3TydSEDiK7dfKPioCFdAyjkclAKl2TC2uz1VXaUVDQ0JSxmw5y_dlQRi_W1rK53t.xs- Received: from [94.249.76.199] by web52306.mail.re2.yahoo.com via HTTP; Tue, 07 Apr 2009 12:16:40 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Tue, 7 Apr 2009 12:16:40 -0700 (PDT) From: mustafa Bani- Khalaf To: manet@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-492543357-1239131800=:84812" Subject: Re: [manet] manet Digest, Vol 60, Issue 19 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mustafa_irbid@yahoo.com List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 19:15:35 -0000 --0-492543357-1239131800=:84812 Content-Type: text/plain; charset=us-ascii --- On Tue, 4/7/09, manet-request@ietf.org wrote: From: manet-request@ietf.org Subject: manet Digest, Vol 60, Issue 19 To: manet@ietf.org Date: Tuesday, April 7, 2009, 12:00 PM Send manet mailing list submissions to manet@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/manet or, via email, send a message with subject or body 'help' to manet-request@ietf.org You can reach the person managing the list at manet-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of manet digest..." Today's Topics: 1. OLSRv2 and forwarding based on MPR (Dearlove, Christopher (UK)) ---------------------------------------------------------------------- Message: 1 Date: Tue, 7 Apr 2009 15:31:37 +0100 From: "Dearlove, Christopher (UK)" Subject: [manet] OLSRv2 and forwarding based on MPR To: "manet" Message-ID: Content-Type: text/plain; charset="us-ascii" (This is not properly threaded, as it seems this email system doesn't like Richard as well as Charlie. I was actually checking the archive for any postings by Charlie.) Richard Ogier > The race condition that Philippe described can also occur with > a single interface under certain conditions. For example, > suppose a MAC protocol is used that decides to "multicast" > a packet by unicasting it to each neighbor, one at a time. This is also a well-known result. But I do not view it as a real issue here, as I believe the cases of interest will use real wireless broadcast. The general multiple unicasting solution does not scale well (though there are approaches - I've implemented at least one) that can win back some of your loss. > (In some cases, this might be more efficient if there are only 2 or 3 > neighbors.) And you know who they are. As one of the points of NHDP is to find your neighbours, which rules out this approach. > So it might be worthwhile to modify the MPR selection or the > MPR flooding mechanism in order to allow the above situation. In this case, I don't think so. In others, this can be so. ******************************************************************** 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 End of manet Digest, Vol 60, Issue 19 ************************************* --0-492543357-1239131800=:84812 Content-Type: text/html; charset=us-ascii


--- On Tue, 4/7/09, manet-request@ietf.org <manet-request@ietf.org> wrote:
From: manet-request@ietf.org <manet-request@ietf.org>
Subject: manet Digest, Vol 60, Issue 19
To: manet@ietf.org
Date: Tuesday, April 7, 2009, 12:00 PM

Send manet mailing list submissions to
	manet@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/manet
or, via email, send a message with subject or body 'help' to
	manet-request@ietf.org

You can reach the person managing the list at
	manet-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of manet digest..."


Today's
 Topics:

   1. OLSRv2 and forwarding based on MPR (Dearlove, Christopher (UK))


----------------------------------------------------------------------

Message: 1
Date: Tue, 7 Apr 2009 15:31:37 +0100
From: "Dearlove, Christopher (UK)"
<chris.dearlove@baesystems.com>
Subject: [manet] OLSRv2 and forwarding based on MPR
To: "manet" <manet@ietf.org>
Message-ID:
	<ABE739C5ADAC9A41ACCC72DF366B719D01C20174@GLKMS2100.GREENLNK.NET>
Content-Type: text/plain;	charset="us-ascii"


(This is not properly threaded, as it seems this email system
doesn't like Richard as well as Charlie. I was actually
checking the archive for any postings by Charlie.)

Richard Ogier
> The race condition that Philippe described can also occur with
> a single interface under certain conditions. For example,
> suppose a MAC protocol is used that decides to "multicast" 
> a packet by
 unicasting it to each neighbor, one at a time.

This is also a well-known result. But I do not view it as a
real issue here, as I believe the cases of interest will use
real wireless broadcast. The general multiple unicasting
solution does not scale well (though there are approaches
- I've implemented at least one) that can win back some of
your loss.

> (In some cases, this might be more efficient if there are only 2 or 3
> neighbors.)

And you know who they are. As one of the points of NHDP is
to find your neighbours, which rules out this approach.

> So it might be worthwhile to modify the MPR selection or the
> MPR flooding mechanism in order to allow the above situation.

In this case, I don't think so. In others, this can be so.

********************************************************************
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


End of manet Digest, Vol 60, Issue 19
*************************************

--0-492543357-1239131800=:84812-- From ogier@earthlink.net Tue Apr 7 22:44: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 803AB3A6969 for ; Tue, 7 Apr 2009 22:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 D1Pzo2AbHto6 for ; Tue, 7 Apr 2009 22:44:20 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 7B03A3A68AC for ; Tue, 7 Apr 2009 22:44:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=sZ+/S5GWhCxgK9AKTGJUlgHfwWNNvpV0sWn8Sv/73EhO1P15hYmaOm2/yMWm/GJd; 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.223.35] by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LrQbD-0000vT-Ua; Wed, 08 Apr 2009 01:45:26 -0400 Message-ID: <49DC3A72.8060804@earthlink.net> Date: Tue, 07 Apr 2009 22:47:30 -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: <000801c9b6fb$9f003fd0$dd00bf70$@nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4787bfcd67ff3a01a6e21e12269b9414f9b2ca018265c350f72350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.223.35 Cc: manet Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 08 Apr 2009 05:44:21 -0000 I guess the main limitation of the race condition is that MPRs must be selected per interface, as discussed. Not only would selecting MPRs per node (for all interfaces) result in more efficient flooding (see the example below), but it would also allow Flooding MPRs to be the same as Routing MPRs in draft-dearlove-olsrv2-metrics-03, thus greatly simplifying the protocol. This would also result in flooding of topology updates along the routing paths in the reverse direction (reverse path forwarding), which provides the benefit that updates related to the path to destination D are received from the next hop to D (so you know the next hop has the information it needs). I know there are methods to avoid the race condition. Philippe mentioned one, and I know of others. My point is that (in my opinion) the benefits of being able to select MPRs per node instead of per interface are great enough to justify using such an approach. At least the WG should be able to consider and experiment with such an alternative. You can say that OLSRv2 is stable, but that is without metrics. Your approach to metrics, using Routing MPRs in addition to Flooding MPRs, appears to be a patch that avoids modifying the existing flooding mechanism in OLSRv2, whereas if one started from scratch, the above simplified approach might be better (in which Flooding MPRs are the same as Routing MPRs). As shown in the following (obvious) example, having to select MPRs per interface can be very inefficient in a network that has several interfaces. In the example, each link is a separate interface; thus node A must select all neighbors as MPRs, even though only one MPR is necessary. A /|\ B C D \|/ E Richard Dearlove, Christopher (UK) wrote: >(This is not properly threaded, as it seems this email system >doesn't like Richard as well as Charlie. I was actually >checking the archive for any postings by Charlie.) > >Richard Ogier > > >>The race condition that Philippe described can also occur with >>a single interface under certain conditions. For example, >>suppose a MAC protocol is used that decides to "multicast" >>a packet by unicasting it to each neighbor, one at a time. >> >> > >This is also a well-known result. But I do not view it as a >real issue here, as I believe the cases of interest will use >real wireless broadcast. The general multiple unicasting >solution does not scale well (though there are approaches >- I've implemented at least one) that can win back some of >your loss. > > > >>(In some cases, this might be more efficient if there are only 2 or 3 >>neighbors.) >> >> > >And you know who they are. As one of the points of NHDP is >to find your neighbours, which rules out this approach. > > > >>So it might be worthwhile to modify the MPR selection or the >>MPR flooding mechanism in order to allow the above situation. >> >> > >In this case, I don't think so. In others, this can be so. > >******************************************************************** >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 Wed Apr 8 00:16:55 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 062543A6AB7 for ; Wed, 8 Apr 2009 00:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.425, 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 H9Kp4fYGiuvu for ; Wed, 8 Apr 2009 00:16:54 -0700 (PDT) Received: from CPSMTPM-EML106.kpnxchange.com (Cpsmtpm-eml106.kpnxchange.com [195.121.3.10]) by core3.amsl.com (Postfix) with ESMTP id 943253A69D6 for ; Wed, 8 Apr 2009 00:16:53 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML106.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 8 Apr 2009 09:18:00 +0200 From: "Teco Boot" To: "'Philippe Jacquet'" References: <000801c9b6fb$9f003fd0$dd00bf70$@nl> <49DAFD5F.6000007@inria.fr> In-Reply-To: <49DAFD5F.6000007@inria.fr> Date: Wed, 8 Apr 2009 09:18:01 +0200 Message-ID: <000b01c9b81a$26b8de40$742a9ac0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm3UJh3tZ8p9wvtSAqzrUzAg39jpgAxfOGQ Content-Language: nl X-OriginalArrivalTime: 08 Apr 2009 07:18:00.0312 (UTC) FILETIME=[26025F80:01C9B81A] Cc: 'manet' Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 08 Apr 2009 07:16:55 -0000 Hi Phillipe, Got it. I had the "per interface" in mind.=20 Now I know MPR selection is for EACH interface and selects MPRs for ALL 2-hop neighbors reachable via that interface.=20 However, I think this could be highly redundant. Assume the following topology: **R7 * ________R4 / / R1-----------R2-------\ ** \ |* | * \ | *R10 | * \ | | * -----R3-------R5**R8 R9 * **R6 Lines: low bandwidth - long reach, e.g. UHF low =20 Asterisk: high bandwidth - short range, e.g. UHF high Now R1 selects (R4, R2, R3) as MPR on |-segment. R2 and R3 select R5. Assume CPU is faster as transmission delay. Scenario: R9 sends TC message. R1 relays TC. R4, R2 and R3 receives this TC in parallel, all are MPR. All schedule TC transmission, it is queued for jitter and or carrier = usage. Transmission is one by one (luckily no collisions). R5 receives TC from R2 or R3, whatever is received first. R5 is MPR for = both R2 and R3. R5 schedules TC transmission. Is it correct that this TC is sent on the |-segment ***5 times***? Forwarding is straightforward (olsrv2-08 page 27): >> 3. For each OLSRv2 interface of the router ********************* So I think the answer is YES. If so, this is really bad!! Again, maybe I overlook something. Teco. |-----Oorspronkelijk bericht----- |Van: Philippe Jacquet [mailto:philippe.jacquet@inria.fr] |Verzonden: dinsdag 7 april 2009 9:15 |Aan: Teco Boot |CC: 'manet' |Onderwerp: Re: [manet] OLSRv2 and forwarding based on MPR | |Dear Teco, | |In your example R6 is indeed in N2(I) of R1, since it can be reached = via |R3. Thus R3 is MPR of R1. R3 must be on I from R1 to be on N(I), but R6 |does not need to be on I in order to be on N2(I). N2(I) contains all |nodes that can be reached from those that are in N(I), indifferently of |the interface. | |Best regards, |Philippe | |Teco Boot a =E9crit : |> Other questions, now on forwarding. |> -08 - page 26 describes the algorithm. |> |> After: |>> 2. Otherwise: |>> 1. Create a Received Tuple in the Received Set for the |>> receiving interface with: |> |> Comes: |>> 2. If a Forwarded Tuple exists with: |> |> This is strange. If the tuple was not received before, how can the |Forwarded |> Tuple exist? (assume no buggy olsr code:-) |> |> |> And the message is not forwarded if the upstream node was not the MPR |> selector, correct? |> For forwarding in the same segment (same interface), this would be |correct. |> But I think that forwarding on other interfaces must take place under |many |> more conditions. I would say, if a message is processed, other nodes |in the |> neighborhood should also receive this message. Within the segment, |it's OK |> that only MPRs take care of forwarding. But for other segments, I do |not see |> a relation with MPRs, especially when MPRs are per interface. |> |> _R4 |> / |> R1-----------R2-------\ |> \ | | |> -------R3-------R5 |> * |> **R6 |> |> Line: segment 1 |> Asterisk: segment 2 |> R2 is MPR for R1 (link to R4 and R5, R3 has not). |> R3 does not forward TC from R1, as R1 is not MPR selector. |> Ditto for TC from R2 and R5. |> But who forwards the TC to R6? |> |> I guess I overlook something here. |> |> |> Teco. |> |> |> |> |> |> |> |> |> |> _______________________________________________ |> manet mailing list |> manet@ietf.org |> https://www.ietf.org/mailman/listinfo/manet |> |> From teco@inf-net.nl Wed Apr 8 06:33:48 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 3829A3A6936 for ; Wed, 8 Apr 2009 06:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.410, 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 FyhtmUfQP72l for ; Wed, 8 Apr 2009 06:33:47 -0700 (PDT) Received: from CPSMTPM-EML104.kpnxchange.com (cpsmtpm-eml104.kpnxchange.com [195.121.3.8]) by core3.amsl.com (Postfix) with ESMTP id 9C2933A68DA for ; Wed, 8 Apr 2009 06:33:46 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 8 Apr 2009 15:34:53 +0200 From: "Teco Boot" To: "'jacquet'" , "'Charles E. Perkins'" , "'Dearlove, Christopher \(UK\)'" Date: Wed, 8 Apr 2009 15:34:54 +0200 Message-ID: <002f01c9b84e$cd26c600$67745200$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm2wi4XtMhFRefFT+maebnwydJK7gBYyI6wAApHm8A= Content-Language: nl X-OriginalArrivalTime: 08 Apr 2009 13:34:53.0177 (UTC) FILETIME=[CC53BE90:01C9B84E] Cc: manet@ietf.org Subject: [manet] OLSRv2 and "per node MPR selection" 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, 08 Apr 2009 13:33:48 -0000 Posting is delayed because attachment. This is plain text message only. Attachment is on http://www.inf-net.nl/OLSRv2-PerNodeMPRselection.pdf Teco. -----Oorspronkelijk bericht----- Van: Teco Boot [mailto:teco@inf-net.nl]=20 Verzonden: woensdag 8 april 2009 15:21 Aan: 'jacquet'; 'Charles E. Perkins'; 'Dearlove, Christopher (UK)' CC: 'manet@ietf.org' Onderwerp: OLSRv2 and "per node MPR selection" Hi Philippe, [changed subject] |One special case: assume that you have two kinds of interfaces: slow = and |fast. If slow means very slow, then you may have a very long flooding |time for a single packet if you merge interfaces for MPR selection. = You |may even have no end at all;-) | |Consider the following network B***D / \ /\ A \/ F \ /\ / C***E I adjusted diagram somewhat, did you use proportional font? The two asterisk lines are separate "slow" segments. The other lines share the "fast" segment. OK? See also attachment. |with all interfaces of type fast excepted (B,D) and (C,E), that are |slow.=20 I have problems with term "slow interfaces". Maybe the medium is "slow" = or there is some queuing (or jitter). I assume that I know what you meant: "late arrival / long delay". Personally, I am sure "fast" interfaces can connect a MANET router to a "slow segment", because this is what I = deploy in real world. Minor detail here. |If all interfaces are merged for MPR calculation, then it can be |that MPR of B and C are all on slow interface. OK: B selects D or E as MPR for path to C and F. Assume it is D. C selects D or E as MPR for path to B and F. Assume it is E. |Suppose MPRs of A are both B and C (there may be additional neighbors = on |B and C to force that). |If A initiates a flood, then B and C will retransmit simultaneously on |fast interface and slow interface, but fast interface arrives first on = D |and E, both receive first from non MPR and cannot relay. F does not |receive the broadcast. Do you mean "from non MPR selector"??? Not sure on this. Scenario: A transmits, B and C receives the message. B and C retransmit the message, one after each other, on both "fast" and "slow" interfaces D receives first on "fast" interface, from C. C is not MPR selector (2.2.3), so message is discarded. Same for E. Then D receives the message on the "slow interface", from B. Why is the packet not forwarded? Algorithm: 1: is B symmetric neighbor? Yes, continue 2: is msg received on "slow" interface before? No, continue 3: is msg forwarded before? No, continue 4: is prev_hop an MPR selector? Yes: FORWARD Same for E. What is the problem ??? Again, maybe I overlook something. |When D or E eventually receive from the slow interface it could compare |time stamps to actually decide that slow interface indeed had = precedence |on fast interface in race competition and finally to decide to actually |retransmit. But again you come out with the performance of the worse |interface (and a very complicated mechanism). | |If MPR are on per interface, then B will select E as MPR on fast |interface |and you gain on the fastest interface which will win the race |competition. | |I think this was the issue (but I am not sure), but I agree that the |result was a kind of compromise to keep things simple. Not sure what "simple" means. Side remark: both "per interface" and "per node" MPR based flooding can = be performed with RouterIDs. And the "per interface MPR selection" is maybe somewhat less complex (I wonder), but the overhead on the "slow segment" looks unacceptable to me. Again, I might overlook something here... If agreed this scenario works fine on "per node MPR selection", can = someone come up with a failing scenario? Teco. |Best regards, |Philippe | |Charles E. Perkins a =E9crit : |> |> Hello Chris, |> |> Comments below... |> |> Dearlove, Christopher (UK) wrote: |>> |>>> I don't understand this. The requirement is that the set |>>> of MPRs must provide connectivity to all 2-hop neighbors |>>> |>> |>> That's not sufficient. |>> |> |> I believe this is highly debatable. |> |>> |>>> o Why MPR selection per interface? |>>> |>> |>> Read the literature. And yes, that is me not putting in the effort |>> to point out the race condition case and why per interface avoids |>> it and per router doesn't (a subtlety in the MPR flooding proof). |>> |> |> I read the proofs, albeit a couple of years ago, and I don't remember |> anything particular about this point. Too bad I can't go back and |review |> this material today. |> | |_______________________________________________ |manet mailing list |manet@ietf.org |https://www.ietf.org/mailman/listinfo/manet From chris.dearlove@baesystems.com Wed Apr 8 07:06:48 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 A24AE3A6A43 for ; Wed, 8 Apr 2009 07:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.614 X-Spam-Level: X-Spam-Status: No, score=-6.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, 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 s3+Hc7f9LEiX for ; Wed, 8 Apr 2009 07:06:47 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 6CFB63A6A21 for ; Wed, 8 Apr 2009 07:06:45 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n38E7oTK004156 for ; Wed, 8 Apr 2009 15:07:50 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n38E7o7I028716 for ; Wed, 8 Apr 2009 15:07:50 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 08 Apr 2009 15:07:50 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 8 Apr 2009 15:07:50 +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: Wed, 8 Apr 2009 15:07:49 +0100 Message-ID: In-Reply-To: <002f01c9b84e$cd26c600$67745200$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 and "per node MPR selection" Thread-Index: Acm2wi4XtMhFRefFT+maebnwydJK7gBYyI6wAApHm8AAAO+xEA== References: <002f01c9b84e$cd26c600$67745200$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "jacquet" , "Charles E. Perkins" X-OriginalArrivalTime: 08 Apr 2009 14:07:50.0006 (UTC) FILETIME=[669BE960:01C9B853] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 and "per node MPR selection" 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, 08 Apr 2009 14:06:48 -0000 What if D uses the same interface to receive from B and C (and E likewise) although B and C use two interfaces to send on? (As you say, interfaces of any type can connect. Fast and slow is a point for an example.) The race condition stops onward transmission in that case. Incidentally note that there is also interface dependence due to OLSRv2 section 7.3 point 1. And you can't flood on router ID because a forwarded message does not contain the router ID of a forwarding node. Messages are not changed (hop count/limit aside) by forwarding - this is the intended model described in 5444 and necessary for end to end authentication as also suggested in 5444, and in real use. All you get from an intermediate node is source IP address of the datagram containing the forwarded message. (This is not the first time I've pointed that out.) --=20 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: 08 April 2009 14:35 To: 'jacquet'; 'Charles E. Perkins'; Dearlove, Christopher (UK) Cc: manet@ietf.org Subject: [manet] OLSRv2 and "per node MPR selection" *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Posting is delayed because attachment. This is plain text message only. Attachment is on http://www.inf-net.nl/OLSRv2-PerNodeMPRselection.pdf Teco. -----Oorspronkelijk bericht----- Van: Teco Boot [mailto:teco@inf-net.nl]=20 Verzonden: woensdag 8 april 2009 15:21 Aan: 'jacquet'; 'Charles E. Perkins'; 'Dearlove, Christopher (UK)' CC: 'manet@ietf.org' Onderwerp: OLSRv2 and "per node MPR selection" Hi Philippe, [changed subject] |One special case: assume that you have two kinds of interfaces: slow and |fast. If slow means very slow, then you may have a very long flooding |time for a single packet if you merge interfaces for MPR selection. You |may even have no end at all;-) | |Consider the following network B***D / \ /\ A \/ F \ /\ / C***E I adjusted diagram somewhat, did you use proportional font? The two asterisk lines are separate "slow" segments. The other lines share the "fast" segment. OK? See also attachment. |with all interfaces of type fast excepted (B,D) and (C,E), that are |slow.=20 I have problems with term "slow interfaces". Maybe the medium is "slow" or there is some queuing (or jitter). I assume that I know what you meant: "late arrival / long delay". Personally, I am sure "fast" interfaces can connect a MANET router to a "slow segment", because this is what I deploy= in real world. Minor detail here. |If all interfaces are merged for MPR calculation, then it can be |that MPR of B and C are all on slow interface. OK: B selects D or E as MPR for path to C and F. Assume it is D. C selects D or E as MPR for path to B and F. Assume it is E. |Suppose MPRs of A are both B and C (there may be additional neighbors on |B and C to force that). |If A initiates a flood, then B and C will retransmit simultaneously on |fast interface and slow interface, but fast interface arrives first on D |and E, both receive first from non MPR and cannot relay. F does not |receive the broadcast. Do you mean "from non MPR selector"??? Not sure on this. Scenario: A transmits, B and C receives the message. B and C retransmit the message, one after each other, on both "fast" and "slow" interfaces D receives first on "fast" interface, from C. C is not MPR selector (2.2.3), so message is discarded. Same for E. Then D receives the message on the "slow interface", from B. Why is the packet not forwarded? Algorithm: 1: is B symmetric neighbor? Yes, continue 2: is msg received on "slow" interface before? No, continue 3: is msg forwarded before? No, continue 4: is prev_hop an MPR selector? Yes: FORWARD Same for E. What is the problem ??? Again, maybe I overlook something. |When D or E eventually receive from the slow interface it could compare |time stamps to actually decide that slow interface indeed had precedence |on fast interface in race competition and finally to decide to actually |retransmit. But again you come out with the performance of the worse |interface (and a very complicated mechanism). | |If MPR are on per interface, then B will select E as MPR on fast |interface |and you gain on the fastest interface which will win the race |competition. | |I think this was the issue (but I am not sure), but I agree that the |result was a kind of compromise to keep things simple. Not sure what "simple" means. Side remark: both "per interface" and "per node" MPR based flooding can be performed with RouterIDs. And the "per interface MPR selection" is maybe somewhat less complex (I wonder), but the overhead on the "slow segment" looks unacceptable to me. Again, I might overlook something here... If agreed this scenario works fine on "per node MPR selection", can someone come up with a failing scenario? Teco. |Best regards, |Philippe | |Charles E. Perkins a =E9crit : |> |> Hello Chris, |> |> Comments below... |> |> Dearlove, Christopher (UK) wrote: |>> |>>> I don't understand this. The requirement is that the set |>>> of MPRs must provide connectivity to all 2-hop neighbors |>>> |>> |>> That's not sufficient. |>> |> |> I believe this is highly debatable. |> |>> |>>> o Why MPR selection per interface? |>>> |>> |>> Read the literature. And yes, that is me not putting in the effort |>> to point out the race condition case and why per interface avoids |>> it and per router doesn't (a subtlety in the MPR flooding proof). |>> |> |> I read the proofs, albeit a couple of years ago, and I don't remember |> anything particular about this point. Too bad I can't go back and |review |> this material today. |> | |_______________________________________________ |manet mailing list |manet@ietf.org |https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This 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 richard.ogier@sri.com Wed Apr 8 07:46:34 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 1E26D3A69B7 for ; Wed, 8 Apr 2009 07:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oJ6ve0PlvpZ for ; Wed, 8 Apr 2009 07:46:33 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 324423A6953 for ; Wed, 8 Apr 2009 07:46:33 -0700 (PDT) Received: from [66.81.220.148] by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LrZ3z-0000qx-Ff for manet@ietf.org; Wed, 08 Apr 2009 10:47:40 -0400 Message-ID: <49DCB98B.2060705@sri.com> Date: Wed, 08 Apr 2009 07:49:47 -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: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4787bfcd67ff3a01a6e5613509c5b7d23e398e11a03a1062720350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.220.148 Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 08 Apr 2009 14:51:03 -0000 Teco Boot wrote: >Is it correct that this TC is sent on the |-segment ***5 times***? > >Forwarding is straightforward (olsrv2-08 page 27): > > >>>3. For each OLSRv2 interface of the router >>> >>> > ********************* >So I think the answer is YES. If so, this is really bad!! > Teco, Although I am not sure that transmitting the TC message 5 times can be avoided in your example, selecting MPRs per interface certainly can result in inefficiency due to unnecessary forwarding. I also discussed this in my post yesterday, which I am repeating below since my previous post was from my earthlink address, which some people are not receiving. I guess the main limitation of the race condition is that MPRs must be selected per interface, as discussed. Not only would selecting MPRs per node (for all interfaces) result in more efficient flooding (see the example below), but it would also allow Flooding MPRs to be the same as Routing MPRs in draft-dearlove-olsrv2-metrics-03, thus greatly simplifying the protocol. This would also result in flooding of topology updates along the routing paths in the reverse direction (reverse path forwarding), which provides the benefit that updates related to the path to destination D are received from the next hop to D (so you know the next hop has the information it needs). I know there are methods to avoid the race condition. Philippe mentioned one, and I know of others. My point is that (in my opinion) the benefits of being able to select MPRs per node instead of per interface are great enough to justify using such an approach. At least the WG should be able to consider and experiment with such an alternative. You can say that OLSRv2 is stable, but that is without metrics. Your approach to metrics, using Routing MPRs in addition to Flooding MPRs, appears to be a patch that avoids modifying the existing flooding mechanism in OLSRv2, whereas if one started from scratch, the above simplified approach might be better (in which Flooding MPRs are the same as Routing MPRs). As shown in the following (obvious) example, having to select MPRs per interface can be very inefficient in a network that has several interfaces. In the example, each link is a separate interface; thus node A must select all neighbors as MPRs, even though only one MPR is necessary. A /|\ B C D \|/ E Richard From richard.ogier@sri.com Wed Apr 8 08:44: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 1AC283A6A73 for ; Wed, 8 Apr 2009 08:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 7dPiZiH4GB+r for ; Wed, 8 Apr 2009 08:44:18 -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 1D9063A68A4 for ; Wed, 8 Apr 2009 08:44:18 -0700 (PDT) Received: from [66.81.220.148] by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LrZxr-0003g5-Qk; Wed, 08 Apr 2009 11:45:25 -0400 Message-ID: <49DCC713.8040100@sri.com> Date: Wed, 08 Apr 2009 08:47:31 -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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4787bfcd67ff3a01a6e9b371a8362827ef85ae4c452becfd911350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.220.148 Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 and "per node MPR selection" 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, 08 Apr 2009 15:44:19 -0000 Teco Boot wrote: >Not sure on this. >Scenario: >A transmits, B and C receives the message. >B and C retransmit the message, one after each other, >on both "fast" and "slow" interfaces >D receives first on "fast" interface, from C. >C is not MPR selector (2.2.3), so message is discarded. >Same for E. >Then D receives the message on the "slow interface", from B. >Why is the packet not forwarded? Algorithm: > 1: is B symmetric neighbor? Yes, continue > 2: is msg received on "slow" interface before? No, continue > > Philippe was showing that there can be a problem if MPRs are selected per node instead of per interface. In that case, the algorithm would naturally be modified by changing step 2 above to "was msg received on any interface before". However, if the above step 2 is used, so that the first reception of the msg on *each* interface is considered, then it appears to work fine. A key point (which Christopher's example, which was not clear to me, may have missed) is that if MPRs are not per interface, then neither are MPR selectors, and so D would forward the msg received from B regardless of which interface it was received on. Therefore, you may have shown that MPRs can be selected per node (for all interfaces), in which case the spec should be changed to do that. Maybe someone can provide a clear example that shows I am wrong (or can prove that I am right). Richard > 3: is msg forwarded before? No, continue > 4: is prev_hop an MPR selector? Yes: FORWARD >Same for E. > >What is the problem ??? > >Again, maybe I overlook something. > > >|When D or E eventually receive from the slow interface it could compare >|time stamps to actually decide that slow interface indeed had precedence >|on fast interface in race competition and finally to decide to actually >|retransmit. But again you come out with the performance of the worse >|interface (and a very complicated mechanism). >| >|If MPR are on per interface, then B will select E as MPR on fast >|interface >|and you gain on the fastest interface which will win the race >|competition. >| >|I think this was the issue (but I am not sure), but I agree that the >|result was a kind of compromise to keep things simple. > >Not sure what "simple" means. > >Side remark: both "per interface" and "per node" MPR based flooding can be >performed with RouterIDs. And the "per interface MPR selection" is maybe >somewhat less complex (I wonder), but the overhead on the "slow segment" >looks unacceptable to me. > >Again, I might overlook something here... > >If agreed this scenario works fine on "per node MPR selection", can someone >come up with a failing scenario? > > >Teco. > > >|Best regards, >|Philippe >| >|Charles E. Perkins a écrit : >|> >|> Hello Chris, >|> >|> Comments below... >|> >|> Dearlove, Christopher (UK) wrote: >|>> >|>>> I don't understand this. The requirement is that the set >|>>> of MPRs must provide connectivity to all 2-hop neighbors >|>>> >|>> >|>> That's not sufficient. >|>> >|> >|> I believe this is highly debatable. >|> >|>> >|>>> o Why MPR selection per interface? >|>>> >|>> >|>> Read the literature. And yes, that is me not putting in the effort >|>> to point out the race condition case and why per interface avoids >|>> it and per router doesn't (a subtlety in the MPR flooding proof). >|>> >|> >|> I read the proofs, albeit a couple of years ago, and I don't remember >|> anything particular about this point. Too bad I can't go back and >|review >|> this material today. >|> >| >|_______________________________________________ >|manet mailing list >|manet@ietf.org >|https://www.ietf.org/mailman/listinfo/manet > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet > > > From teco@inf-net.nl Wed Apr 8 08:46:26 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 7D6043A6A8E for ; Wed, 8 Apr 2009 08:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 ZfmrrOYW0t59 for ; Wed, 8 Apr 2009 08:46:25 -0700 (PDT) Received: from CPSMTPM-EML107.kpnxchange.com (Cpsmtpm-eml107.kpnxchange.com [195.121.3.11]) by core3.amsl.com (Postfix) with ESMTP id E87A73A6A7A for ; Wed, 8 Apr 2009 08:46:24 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML107.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 8 Apr 2009 17:47:31 +0200 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'jacquet'" , "'Charles E. Perkins'" References: <002f01c9b84e$cd26c600$67745200$@nl> In-Reply-To: Date: Wed, 8 Apr 2009 17:47:32 +0200 Message-ID: <004001c9b861$54d12160$fe736420$@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: Acm2wi4XtMhFRefFT+maebnwydJK7gBYyI6wAApHm8AAAO+xEAAAhj2A Content-Language: nl X-OriginalArrivalTime: 08 Apr 2009 15:47:31.0441 (UTC) FILETIME=[53D27610:01C9B861] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 and "per node MPR selection" 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, 08 Apr 2009 15:46:26 -0000 |What if D uses the same interface to receive from |B and C (and E likewise) although B and C use two |interfaces to send on? (As you say, interfaces of |any type can connect. Fast and slow is a point for |an example.) The race condition stops onward |transmission in that case. To line up on terminology: 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. Some __physical__ router interfaces can connect to multiple MANET segments. I assume the driver for such an interfaces provide __separate virtual interfaces__. I can imagine that a router has multiple interfaces to the same segment. For example for redundancy, for Rx diversity or whatever. One is used for Tx, or even both (Tx diversity). I assume the interfaces have the same IP address and MAC address. So for other nodes, this is transparent. All of this doesn't cause the race condition. When B-D (and C-E) are on the same "fast" MANET segment, and forwarding of relayed msg by B is delayed (jitter, queuing), msg from C would arrive first. Or D or E is the MPR for C, in this case it is E. E forwards, D does not. What is the problem? Question: what is the difference with "per interface MPR selection"? Now we have single segment / single interface. If you provide some more guidelines for the scenario, I'm happy to produce another analysis document. |Incidentally note that there is also interface |dependence due to OLSRv2 section 7.3 point 1. Yes, it is in my flow chart. |And you can't flood on router ID because a forwarded |message does not contain the router ID of a forwarding |node. Yes, it is. In my proposal, all messages are sent with the RouterID as source address, e.g. the protocol binds to the loopback interface, or the "unnumbered interface" model is used. I moved somewhat towards the addressing model of Thomas / Ulrich. With the loopback interface approach, L3 to L2 address mapping must be handled. One can think of snooping or proxy-arp/nd. There could be more options, so this is not blocking. Snooping is a nice feature, implemented as plug-in in olsr.org code already. |Messages are not changed (hop count/limit aside) |by forwarding - this is the intended model described |in 5444 and necessary for end to end authentication |as also suggested in 5444, and in real use. All you get |from an intermediate node is source IP address of the |datagram containing the forwarded message. (This is not |the first time I've pointed that out.) Works fine for me. A I am more and more convinced RouterID works fine, I could write an I-D for it. Few cycles left in coming weeks. Or maybe Henning is producing something. For "per node MPR selection", I'll wait on a scenario that breaks this model. If no one can come up with it, I do not see a reason for not accepting it by the WG. Teco. From chris.dearlove@baesystems.com Wed Apr 8 09:08:48 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 8FBFD3A68E4 for ; Wed, 8 Apr 2009 09:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.614 X-Spam-Level: X-Spam-Status: No, score=-6.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, 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 gTxjpOWb1xXk for ; Wed, 8 Apr 2009 09:08:48 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id B0F0A3A6856 for ; Wed, 8 Apr 2009 09:08:47 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n38G9rZF021247 for ; Wed, 8 Apr 2009 17:09:53 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n38G9ram001618 for ; Wed, 8 Apr 2009 17:09:53 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 08 Apr 2009 17:09:52 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 8 Apr 2009 17:09:52 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 8 Apr 2009 17:09:51 +0100 Message-ID: In-Reply-To: <49DCB98B.2060705@sri.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 and forwarding based on MPR Thread-Index: Acm4WaFsXeYExHD1Q3au5ARcOu+yywACpkaw References: <49DCB98B.2060705@sri.com> From: "Dearlove, Christopher (UK)" To: "Richard Ogier" , X-OriginalArrivalTime: 08 Apr 2009 16:09:52.0607 (UTC) FILETIME=[733826F0:01C9B864] Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 08 Apr 2009 16:08:48 -0000 Ricahrd Ogier > the above simplified approach might be better > (in which Flooding MPRs are the same as Routing MPRs). Not if metrics are asymmetric. That's actually a fundamental reason for separating the two. They use the opposite direction metrics. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From chris.dearlove@baesystems.com Wed Apr 8 09:10:02 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 83DF528C167 for ; Wed, 8 Apr 2009 09:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.613 X-Spam-Level: X-Spam-Status: No, score=-6.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, 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 GWBuF9Y2a0ho for ; Wed, 8 Apr 2009 09:10:01 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id A049528C10A for ; Wed, 8 Apr 2009 09:10:01 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n38GB6Qi020846 for ; Wed, 8 Apr 2009 17:11:06 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n38GB6NS002239 for ; Wed, 8 Apr 2009 17:11:06 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 08 Apr 2009 17:11:05 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 8 Apr 2009 17:11:05 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 8 Apr 2009 17:11:04 +0100 Message-ID: In-Reply-To: <49DCC713.8040100@sri.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 and "per node MPR selection" Thread-Index: Acm4YRsrklWytKSuRjS9dgN1IUsu9gAA2LeQ References: <49DCC713.8040100@sri.com> From: "Dearlove, Christopher (UK)" To: "Richard Ogier" , "Teco Boot" X-OriginalArrivalTime: 08 Apr 2009 16:11:05.0451 (UTC) FILETIME=[9EA343B0:01C9B864] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 and "per node MPR selection" 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, 08 Apr 2009 16:10:02 -0000 Richard Ogier=20 > Therefore, you may have shown that MPRs can be selected per node > (for all interfaces) Not and avoid the race condition. See an earlier email of mine. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From chris.dearlove@baesystems.com Wed Apr 8 09:18:50 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 A325728C10A for ; Wed, 8 Apr 2009 09:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.613 X-Spam-Level: X-Spam-Status: No, score=-6.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, 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 yyspPYiNmsdK for ; Wed, 8 Apr 2009 09:18:49 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 5840028C1F9 for ; Wed, 8 Apr 2009 09:16:59 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n38GI5be023705 for ; Wed, 8 Apr 2009 17:18:05 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n38GI44x025871 for ; Wed, 8 Apr 2009 17:18:04 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 08 Apr 2009 17:18:04 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 8 Apr 2009 17:18:04 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 8 Apr 2009 17:18:03 +0100 Message-ID: In-Reply-To: <004001c9b861$54d12160$fe736420$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 and "per node MPR selection" Thread-Index: Acm2wi4XtMhFRefFT+maebnwydJK7gBYyI6wAApHm8AAAO+xEAAAhj2AAAQgVzA= References: <002f01c9b84e$cd26c600$67745200$@nl> <004001c9b861$54d12160$fe736420$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "jacquet" , "Charles E. Perkins" X-OriginalArrivalTime: 08 Apr 2009 16:18:04.0388 (UTC) FILETIME=[9857FA40:01C9B865] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 and "per node MPR selection" 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, 08 Apr 2009 16:18:50 -0000 > What is the problem? The problem is when the ordering of different transmissions of the same message is not well-defined. That ordering is an assumption of the mathematical theorems that allow MPRs to work (including such efficiency savings as that a first reception from a non-MPR selecor blocks a later reception from an MPR selector from being forwarded, significantly saving on transmissions). Philippe's example (when you consider reception by single interfaces) shows such a case, where the conditions are violated, and the flooding fails. Per interface selection avoids this case. ******************************************************************** 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 richard.ogier@sri.com Wed Apr 8 09:50:28 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 9C06C3A6E7E for ; Wed, 8 Apr 2009 09:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cw2m2HBdVSWq for ; Wed, 8 Apr 2009 09:50:27 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 856253A6E7C for ; Wed, 8 Apr 2009 09:50:27 -0700 (PDT) Received: from [66.81.216.251] by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lrazt-0005VN-OE; Wed, 08 Apr 2009 12:51:34 -0400 Message-ID: <49DCD695.5010708@sri.com> Date: Wed, 08 Apr 2009 09:53:41 -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: <002f01c9b84e$cd26c600$67745200$@nl> <004001c9b861$54d12160$fe736420$@nl> In-Reply-To: <004001c9b861$54d12160$fe736420$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4787bfcd67ff3a01a6ecdb13d79884dfe83a27d540639bfcbcd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.216.251 Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 and "per node MPR selection" 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, 08 Apr 2009 16:50:28 -0000 Teco Boot wrote: >I am more and more convinced RouterID works fine, I could write an I-D for >it. Few cycles left in coming weeks. Or maybe Henning is producing >something. > > I agree with the above. Note that in OSPFv3 (RFC 5340), each OSPF message includes the sender's Router ID in the OSPF header. There is no reason why the same cannot be done here. >For "per node MPR selection", I'll wait on a scenario that breaks this >model. If no one can come up with it, I do not see a reason for not >accepting it by the WG. > > I also agree with this. Christopher has not yet provided a clear example that shows per node MPR selection will not work when the first reception of a given message on *each* interface is considered for forwarding. As you pointed out, Philippe's example does not show failure under this assumption. (He assumed that only the first reception of a given message on *any* interface is considered for forwarding.) Richard > >Teco. > > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet > > > From chris.dearlove@baesystems.com Wed Apr 8 09:54: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 2C3353A6B16 for ; Wed, 8 Apr 2009 09:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.613 X-Spam-Level: X-Spam-Status: No, score=-6.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, 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 2cmUw4ZEoo4z for ; Wed, 8 Apr 2009 09:54:09 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 14F883A68C4 for ; Wed, 8 Apr 2009 09:54:08 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n38GtDTS002679 for ; Wed, 8 Apr 2009 17:55:14 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n38GtDSm018529 for ; Wed, 8 Apr 2009 17:55:13 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 08 Apr 2009 17:55:13 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 8 Apr 2009 17:55:13 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 8 Apr 2009 17:55:12 +0100 Message-ID: In-Reply-To: <49DCD695.5010708@sri.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 and "per node MPR selection" Thread-Index: Acm4akyFMmwJMnP+R/qmMHXJiJZN7gAABdAA References: <002f01c9b84e$cd26c600$67745200$@nl><004001c9b861$54d12160$fe736420$@nl> <49DCD695.5010708@sri.com> From: "Dearlove, Christopher (UK)" To: "Richard Ogier" , "Teco Boot" X-OriginalArrivalTime: 08 Apr 2009 16:55:13.0391 (UTC) FILETIME=[C8EED7F0:01C9B86A] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 and "per node MPR selection" 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, 08 Apr 2009 16:54:10 -0000 > I agree with the above. Note that in OSPFv3 (RFC 5340), each OSPF message > includes the sender's Router ID in the OSPF header. There is no reason > why the same cannot be done here. See my previous postings and RFC 5444 for why this is not done. > I also agree with this. Christopher has not yet provided a clear > example that shows per node MPR selection will not work when > the first reception of a given message on *each* interface is > considered for forwarding. As I have mentioned, that is inefficient, it means that there are always extra messages sent when using multiple interfaces, not just sometimes. ******************************************************************** 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 richard.ogier@sri.com Wed Apr 8 10:25: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 AB6433A6E77 for ; Wed, 8 Apr 2009 10:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 LlS8cTLAVMgC for ; Wed, 8 Apr 2009 10:25:07 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 59AF13A6E78 for ; Wed, 8 Apr 2009 10:25:07 -0700 (PDT) Received: from [66.81.217.152] by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LrbXQ-0000yK-QU; Wed, 08 Apr 2009 13:26:13 -0400 Message-ID: <49DCDEB4.1070101@sri.com> Date: Wed, 08 Apr 2009 10:28:20 -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: <002f01c9b84e$cd26c600$67745200$@nl> <004001c9b861$54d12160$fe736420$@nl> <49DCD695.5010708@sri.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4787bfcd67ff3a01a6ee24f425ff6d5c38d866af61c445b02cc350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.217.152 Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 and "per node MPR selection" 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, 08 Apr 2009 17:25:11 -0000 Dearlove, Christopher (UK) wrote: >>I also agree with this. Christopher has not yet provided a clear >>example that shows per node MPR selection will not work when >>the first reception of a given message on *each* interface is >>considered for forwarding. >> >> > >As I have mentioned, that is inefficient, it means that there are >always extra messages sent when using multiple interfaces, not >just sometimes. > OK, you now agree it works. But you are saying it is inefficient because a given message is considered for forwarding the first time it is received on each interface (not just the first interface). But as Teco pointed out, and as specified in Step 2.1 of Section 7.3, a received message is discarded only if it was already received on the *same* interface. Therefore, olsrv2 already considers a message for forwarding the first time it is received on each interface! Therefore, the proposed modification is not less efficient, but is more efficient because a single set of MPRs is selected for all interfaces (not per interface). Richard From teco@inf-net.nl Wed Apr 8 10:52:32 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 69C7228C266 for ; Wed, 8 Apr 2009 10:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.395, 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 QTNpzXSDV8g7 for ; Wed, 8 Apr 2009 10:52:31 -0700 (PDT) Received: from CPSMTPM-EML109.kpnxchange.com (Cpsmtpm-eml109.kpnxchange.com [195.121.3.13]) by core3.amsl.com (Postfix) with ESMTP id 75E2428C26D for ; Wed, 8 Apr 2009 10:52:30 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML109.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 8 Apr 2009 19:53:37 +0200 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'jacquet'" , "'Charles E. Perkins'" References: <002f01c9b84e$cd26c600$67745200$@nl> <004001c9b861$54d12160$fe736420$@nl> In-Reply-To: Date: Wed, 8 Apr 2009 19:53:39 +0200 Message-ID: <004e01c9b872$f2a82c60$d7f88520$@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: Acm2wi4XtMhFRefFT+maebnwydJK7gBYyI6wAApHm8AAAO+xEAAAhj2AAAQgVzAAAzlzoA== Content-Language: nl X-OriginalArrivalTime: 08 Apr 2009 17:53:37.0605 (UTC) FILETIME=[F19B7750:01C9B872] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 and "per node MPR selection" 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, 08 Apr 2009 17:52:32 -0000 |> What is the problem? | |The problem is when the ordering of different transmissions |of the same message is not well-defined. That ordering is an |assumption of the mathematical theorems that allow MPRs to |work (including such efficiency savings as that a first |reception from a non-MPR selecor blocks a later reception |from an MPR selector from being forwarded, significantly |saving on transmissions). Philippe's example (when you consider |reception by single interfaces) shows such a case, where the |conditions are violated, and the flooding fails. Per interface |selection avoids this case. Again, if one comes up with more detailed description of the race condition, I am happy to analyze this. Philippe's example with "single interfaces" is working fine. For now, I assert "per node MPR selection" does not have problems. Teco. From richard.ogier@sri.com Wed Apr 8 21:02:17 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 5AA503A6911 for ; Wed, 8 Apr 2009 21:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 417C5xe4On+C for ; Wed, 8 Apr 2009 21:02:16 -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 928A33A68CC for ; Wed, 8 Apr 2009 21:02:16 -0700 (PDT) Received: from [66.81.222.10] by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LrlU3-000359-9H; Thu, 09 Apr 2009 00:03:24 -0400 Message-ID: <49DD7409.9050700@sri.com> Date: Wed, 08 Apr 2009 21:05:29 -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: <49DCB98B.2060705@sri.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4787bfcd67ff3a01a6ecd0c74a51ce60e1f69597f5666070aff350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.222.10 Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 09 Apr 2009 04:02:17 -0000 I have an additional comment below, in response to an earlier post. Dearlove, Christopher (UK) wrote: >Richard Ogier wrote: > > >>the above simplified approach might be better >>(in which Flooding MPRs are the same as Routing MPRs). >> >> > >Not if metrics are asymmetric. That's actually a fundamental >reason for separating the two. They use the opposite direction >metrics. > > > It is good to allow the flexibility to use metrics in that manner to select flooding MPRs. But it would also be good to allow the flexibility to select flooding MPRs to be the same as routing MPRs for simplicity when metrics are not used, or even when metrics are used. (In the latter case, TC messages are forwarded along shortest paths in the reverse direction, which may not be optimal, but the benefit is simplicity.) But this option is possible only if MPRs are selected per node and not per interface. (The arguments in favor of per-node MPRs are building up.) Also, since your last post claimed that the proposed method is inefficient, I want to repeat the following example as a reminder that selecting MPRs per node can be MUCH more efficient than selecting MPRs per interface. In the example, each link is a separate interface; thus node A must select all neighbors as MPRs, even though only one MPR is necessary. This seems like a no brainer to me. A /|\ B C D \|/ E Richard From philippe.jacquet@inria.fr Thu Apr 9 01:48:49 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 D594B3A6B7E for ; Thu, 9 Apr 2009 01:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.784 X-Spam-Level: X-Spam-Status: No, score=-5.784 tagged_above=-999 required=5 tests=[AWL=0.465, 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 kLKEwl60RaZy for ; Thu, 9 Apr 2009 01:48:49 -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 9A2D63A6E8B for ; Thu, 9 Apr 2009 01:48:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,159,1238968800"; d="scan'208";a="24264002" Received: from unknown (HELO [128.93.41.39]) ([128.93.41.39]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Apr 2009 10:49:54 +0200 Message-ID: <49DDB6B2.6030109@inria.fr> Date: Thu, 09 Apr 2009 10:49:54 +0200 From: Philippe Jacquet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Teco Boot References: <002f01c9b84e$cd26c600$67745200$@nl> <004001c9b861$54d12160$fe736420$@nl> <004e01c9b872$f2a82c60$d7f88520$@nl> In-Reply-To: <004e01c9b872$f2a82c60$d7f88520$@nl> 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 and "per node MPR selection" 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, 09 Apr 2009 08:48:49 -0000 Hi, Teco, These new rules would align the performances on the worse interface and very likely generate more packets than with the previous rule and with much more delays. But maybe I understood wrongly. Are you proposing 1. per node MPR selection 2. forward if there is an interface where you receive first from one MPR selector? Then the following example fails: B-----E * --/ / ** C*****D I mean (B,E) and (B,D) on interface -- (C,D) and (C,E) on interface ** MPR of B is E and MPR of C is D. B shoots first on interface ***, C shoots first on interface --. Then E and D receive both first from non MPR selector. In conclusion the order per interfaces does not generate a founded order on the packets, as soon you have more than two interfaces. When the MPR are selected per interface makes the order founded again. One possible alternative well founded order with per node selection is to use the emitter ID, but in this case you have no bound on how long you have to wait to determine which is the smallest ID of the emitters and to retransmit if the smallest ID is an MPR selector. In general it turns out to retransmit more packets and align again on the performance of the worse interface. Best regards, Philippe Teco Boot a écrit : > |> What is the problem? > | > |The problem is when the ordering of different transmissions > |of the same message is not well-defined. That ordering is an > |assumption of the mathematical theorems that allow MPRs to > |work (including such efficiency savings as that a first > |reception from a non-MPR selecor blocks a later reception > |from an MPR selector from being forwarded, significantly > |saving on transmissions). Philippe's example (when you consider > |reception by single interfaces) shows such a case, where the > |conditions are violated, and the flooding fails. Per interface > |selection avoids this case. > > Again, if one comes up with more detailed description of the race condition, > I am happy to analyze this. > Philippe's example with "single interfaces" is working fine. > > For now, I assert "per node MPR selection" does not have problems. > > Teco. > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > From philippe.jacquet@inria.fr Thu Apr 9 02:27: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 361A83A6BD3 for ; Thu, 9 Apr 2009 02:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.939 X-Spam-Level: X-Spam-Status: No, score=-5.939 tagged_above=-999 required=5 tests=[AWL=0.310, 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 JzdzRIGSPPSm for ; Thu, 9 Apr 2009 02:27:21 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id E22853A6A4D for ; Thu, 9 Apr 2009 02:27:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,431,1233529200"; d="scan'208";a="27353977" Received: from unknown (HELO [128.93.41.39]) ([128.93.41.39]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Apr 2009 11:28:27 +0200 Message-ID: <49DDBFBA.601@inria.fr> Date: Thu, 09 Apr 2009 11:28:26 +0200 From: Philippe Jacquet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Teco Boot References: <002f01c9b84e$cd26c600$67745200$@nl> In-Reply-To: <002f01c9b84e$cd26c600$67745200$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: [manet] flooding MPRs and metric MPRs 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, 09 Apr 2009 09:27:22 -0000 Hi Teco, I change subject but I take the opportunity of your nice diagrams in http://www.inf-net.nl/OLSRv2-PerNodeMPRselection.pdf There is a recurrent proposal to use the metric MPRs as flooding MPR. Chris already said that this won't work because metric MPRs don't necessarily cover the two hop neighbor, since they may be well within the node neighborhood (very likely among the closest node). If one wants a flooding via metric MPR one must change the condition "is srce sym neigh?" (if no, then "discard") probably by something like "is srce last relay in an inbound shortest path" (if no, then discard) which is more complicated to implement. If one does indeed implement this, that would be more or less equivalent to artificially reduce the neighborhood of each nodes to its closest neighbor (wrt metric). And therefore have a much larger ratio #MPR over #neighbor. Basically this ratio determines the performance ratio between MPR flooding and basic flooding. Best regards, Philippe Teco Boot a écrit : > Posting is delayed because attachment. This is plain text message only. > Attachment is on http://www.inf-net.nl/OLSRv2-PerNodeMPRselection.pdf > Teco. > From chris.dearlove@baesystems.com Thu Apr 9 03:22:33 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 EF73A3A6A92 for ; Thu, 9 Apr 2009 03:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.613 X-Spam-Level: X-Spam-Status: No, score=-6.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, 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 vs9YP8k3baPU for ; Thu, 9 Apr 2009 03:22:33 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id CD95B3A67D9 for ; Thu, 9 Apr 2009 03:22:32 -0700 (PDT) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n39ANcnZ008267 for ; Thu, 9 Apr 2009 11:23:38 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n39ANcFs025647 for ; Thu, 9 Apr 2009 11:23:38 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 09 Apr 2009 11:23:38 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 9 Apr 2009 11:23:37 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 9 Apr 2009 11:23:36 +0100 Message-ID: In-Reply-To: <49DCDEB4.1070101@sri.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 and "per node MPR selection" Thread-Index: Acm4byABTF3daKdpTaen7loRA1CpoAAjHb3Q References: <002f01c9b84e$cd26c600$67745200$@nl> <004001c9b861$54d12160$fe736420$@nl> <49DCD695.5010708@sri.com> <49DCDEB4.1070101@sri.com> From: "Dearlove, Christopher (UK)" To: "Richard Ogier" X-OriginalArrivalTime: 09 Apr 2009 10:23:37.0783 (UTC) FILETIME=[3EDF5470:01C9B8FD] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 and "per node MPR selection" 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, 09 Apr 2009 10:22:34 -0000 > OK, you now agree it works. I'm not sure which "it" you are referring to. I agree that there are variations you can make that work, though some allow the race condition and just hope it is rare enough to ignore, and some are clearly inefficient. But (see Philippe) there's work that indicates why the current approach (which is - presentation aside - essentially that of OLSRv1, a tried and tested protocol with many deployments) is that included. I don't agree that all of the variants that have been suggested work, and some have definitely bad requirements. Two more points. One is that I'm shortly away for over a week, so failure to comment is not agreement. The other is that over three years ago now, we agreed to create OLSRv2 as the Standards Track protocol, a key advantage being that in most regards (flooding is one) we get to know how it behaves - it's like OLSRv1. Even where things aren't exactly as OLSRv1, it's actually getting the same performance (or sometimes slightly better in handling some address change transient issues) with fewer messages. I have no desire to see the MANET WG degenerate to the state it was half a dozen years ago where all the time was spent arguing over these points. What we need (have needed for two or three years in fact) is to get this done, not reopen old discussions. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From chris.dearlove@baesystems.com Thu Apr 9 03:28:17 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 4C6B23A6C0D for ; Thu, 9 Apr 2009 03:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.612 X-Spam-Level: X-Spam-Status: No, score=-6.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, 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 4o4c7tvwJxot for ; Thu, 9 Apr 2009 03:28:16 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 51F283A6BFE for ; Thu, 9 Apr 2009 03:28:16 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n39ATLoS010785 for ; Thu, 9 Apr 2009 11:29:21 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n39ATLWQ022502 for ; Thu, 9 Apr 2009 11:29:21 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 09 Apr 2009 11:29:21 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 9 Apr 2009 11:29:21 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 9 Apr 2009 11:29:20 +0100 Message-ID: In-Reply-To: <004e01c9b872$f2a82c60$d7f88520$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 and "per node MPR selection" Thread-Index: Acm2wi4XtMhFRefFT+maebnwydJK7gBYyI6wAApHm8AAAO+xEAAAhj2AAAQgVzAAAzlzoAAi5o6Q References: <002f01c9b84e$cd26c600$67745200$@nl><004001c9b861$54d12160$fe736420$@nl> <004e01c9b872$f2a82c60$d7f88520$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "jacquet" , "Charles E. Perkins" X-OriginalArrivalTime: 09 Apr 2009 10:29:21.0191 (UTC) FILETIME=[0B8F3B70:01C9B8FE] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 and "per node MPR selection" 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, 09 Apr 2009 10:28:17 -0000 > For now, I assert "per node MPR selection" does not have problems. Assertions aren't worth much, especially ones just "for now". I prefer mathematical proofs. And those exist, but with ordering requirements which multiple interfaces and simple MPR selection don't satisfy. And a problem case has been pointed out (with the point that the receiving nodes use a single interface in this case) which shows that simply removing that requirement doesn't work. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From chris.dearlove@baesystems.com Thu Apr 9 04:16: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 E5FF13A69DB for ; Thu, 9 Apr 2009 04:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.612 X-Spam-Level: X-Spam-Status: No, score=-6.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, 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 Y+3DRodYgf+9 for ; Thu, 9 Apr 2009 04:16:04 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 8E7693A6999 for ; Thu, 9 Apr 2009 04:15:58 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n39BH4mg024234 for ; Thu, 9 Apr 2009 12:17:04 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n39BH4PC018765 for ; Thu, 9 Apr 2009 12:17:04 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 09 Apr 2009 12:17:03 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 9 Apr 2009 12:17:03 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 9 Apr 2009 12:17:02 +0100 Message-ID: In-Reply-To: <49DD7409.9050700@sri.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 and forwarding based on MPR Thread-Index: Acm4yQe0e8ynf6WmQ9a+0Q5BIQYstQANSV7w References: <49DCB98B.2060705@sri.com> <49DD7409.9050700@sri.com> From: "Dearlove, Christopher (UK)" To: "Richard Ogier" X-OriginalArrivalTime: 09 Apr 2009 11:17:03.0254 (UTC) FILETIME=[B57B6360:01C9B904] Cc: manet@ietf.org Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 09 Apr 2009 11:16:05 -0000 > But it would also be good to > allow the flexibility to select flooding MPRs to be the same > as routing MPRs for simplicity when metrics are not used Always possible, because the algorithm isn't specified, only its properties. There's plenty of scope for intelligent tradeoffs of how to do things. > or even when metrics are used. (In the latter case, TC messages > are forwarded along shortest paths in the reverse direction, > which may not be optimal, but the benefit is simplicity.) There's actually no necessity to use metrics at all for flooding. (It just improves some things. But for routing use of metrics is essential.) > But this option is possible only if MPRs are selected per node > and not per interface. Not so, you can always select per interface even when you don't have to (i.e for routing). That's if you value making the same selection more highly than making an efficient selection. Adter all, it's even legal to use the simplest MPR selection algorithm of all - pick all your neighbours. But if you do, I'll pick someone else's implementation. ******************************************************************** 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 richard.ogier@sri.com Thu Apr 9 09:41: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 ED9AD3A69B6 for ; Thu, 9 Apr 2009 09:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yv0OHmE0GtKv for ; Thu, 9 Apr 2009 09:41:12 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 72FDD3A6A2C for ; Thu, 9 Apr 2009 09:40:44 -0700 (PDT) Received: from [66.81.218.14] by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LrxJz-0005Jj-R3; Thu, 09 Apr 2009 12:41:49 -0400 Message-ID: <49DE25CD.1080304@sri.com> Date: Thu, 09 Apr 2009 09:43:57 -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: <002f01c9b84e$cd26c600$67745200$@nl> <004001c9b861$54d12160$fe736420$@nl> <004e01c9b872$f2a82c60$d7f88520$@nl> <49DDB6B2.6030109@inria.fr> In-Reply-To: <49DDB6B2.6030109@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4787bfcd67ff3a01a6e19433cde407b7ed95fdc88b4e49b24b1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.218.14 Cc: chris.dearlove@baesystems.com, manet@ietf.org Subject: Re: [manet] OLSRv2 and "per node MPR selection" 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, 09 Apr 2009 16:41:13 -0000 Philippe, Thanks for your example. I believe that is what Teco and I were both looking for. I am now convinced that MPRs cannot be selected per node, without using emitter ID to establish order or selecting MPRs in a special way as discussed below. Another alternative (though less efficient) is to select MPRs so that the neighbor with the largest RID that covers a given 2-hop neighbor is always selected as an MPR. (This can also be achieved using self-selected MPRs.) In your example, B and C would both select E as an MPR (assuming E has a larger RID than D). I hope that olsrv2 is flexible enough to allow such a selection, thus essentially allowing per-node MPRs by making it unnecessary for the MPR set for each interface to cover all 2-hop neighbors. However, Section 14 of the draft does not currently allow this, so I hope this can modified to allow more flexibility. Chris said "There's plenty of scope for intelligent tradeoffs of how to do things", but this appears to be a significant limitation. BTW, you had a typo which is corrected as follows: I mean (B,E) and (C,E) on interface -- (C,D) and (B,D) on interface ** Richard Philippe Jacquet wrote: > Hi, Teco, > > These new rules would align the performances on the worse interface > and very likely generate more packets than with the previous rule and > with much more delays. But maybe I understood wrongly. Are you proposing > 1. per node MPR selection > 2. forward if there is an interface where you receive first from one > MPR selector? > > Then the following example fails: > > B-----E > * --/ > / ** > C*****D > > I mean (B,E) and (B,D) on interface -- > (C,D) and (C,E) on interface ** > > MPR of B is E and MPR of C is D. B shoots first on interface ***, C > shoots first on interface --. Then E and D receive both first from non > MPR selector. > > In conclusion the order per interfaces does not generate a founded > order on the packets, as soon you have more than two interfaces. When > the MPR are selected per interface makes the order founded again. > > One possible alternative well founded order with per node selection is > to use the emitter ID, but in this case you have no bound on how long > you have to wait to determine which is the smallest ID of the emitters > and to retransmit if the smallest ID is an MPR selector. In general it > turns out to retransmit more packets and align again on the > performance of the worse interface. > > Best regards, > Philippe > > Teco Boot a écrit : > >> |> What is the problem? >> | >> |The problem is when the ordering of different transmissions >> |of the same message is not well-defined. That ordering is an >> |assumption of the mathematical theorems that allow MPRs to >> |work (including such efficiency savings as that a first >> |reception from a non-MPR selecor blocks a later reception >> |from an MPR selector from being forwarded, significantly >> |saving on transmissions). Philippe's example (when you consider >> |reception by single interfaces) shows such a case, where the >> |conditions are violated, and the flooding fails. Per interface >> |selection avoids this case. >> >> Again, if one comes up with more detailed description of the race >> condition, >> I am happy to analyze this. >> Philippe's example with "single interfaces" is working fine. >> For now, I assert "per node MPR selection" does not have problems. >> >> Teco. >> >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From teco@inf-net.nl Thu Apr 9 12:50: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 AB5813A6BDA for ; Thu, 9 Apr 2009 12:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.382, 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 wjcqHQktr2hF for ; Thu, 9 Apr 2009 12:50:14 -0700 (PDT) Received: from CPSMTPM-EML106.kpnxchange.com (Cpsmtpm-eml106.kpnxchange.com [195.121.3.10]) by core3.amsl.com (Postfix) with ESMTP id AF7DA3A6AE0 for ; Thu, 9 Apr 2009 12:50:13 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML106.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Thu, 9 Apr 2009 21:51:21 +0200 From: "Teco Boot" To: "'Philippe Jacquet'" References: <002f01c9b84e$cd26c600$67745200$@nl> <004001c9b861$54d12160$fe736420$@nl> <004e01c9b872$f2a82c60$d7f88520$@nl> <49DDB6B2.6030109@inria.fr> In-Reply-To: <49DDB6B2.6030109@inria.fr> Date: Thu, 9 Apr 2009 21:51:20 +0200 Message-ID: <000101c9b94c$8e214d50$aa63e7f0$@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: Acm48ExjA4L0sqUzRqWpoYNheErFmQABZrIw Content-Language: nl X-OriginalArrivalTime: 09 Apr 2009 19:51:21.0091 (UTC) FILETIME=[8E2FA530:01C9B94C] Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] OLSRv2 and "per node MPR selection" 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, 09 Apr 2009 19:50:14 -0000 Hi Phillipe, [lots of interruptions while responding...] |Then the following example fails: | | B-----E | * --/ | / ** | C*****D | |I mean (B,E) and (B,D) on interface -- | (C,D) and (C,E) on interface ** Split your diagram in two: Interface -- B-----E ___/ / C D This is (B,E) and (C,E). Interface ** B E ** *** C*****D This is (B,D) and (C,D). [as Richard also noticed] |MPR of B is E and MPR of C is D. B shoots first on interface ***, C |shoots first on interface --. Then E and D receive both first from non |MPR selector. OK. Now E and D process the message, but they do not forward. Thinks can happen. But B shoots also on ---, C on ***. These will arrive on both E and D MPRs and MUST be forwarded. This indeed need the adjusted forwarding algorithm, updating the "received on this interface before" check, as Richard pointed out. Question is: update to "received before?", or just skip the check. I have to read more on this. Teco. From richard.ogier@sri.com Thu Apr 9 13:30:20 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 0B56F3A694F for ; Thu, 9 Apr 2009 13:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLLKIb2-Efjr for ; Thu, 9 Apr 2009 13:30:18 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id E9EC93A696C for ; Thu, 9 Apr 2009 13:30:17 -0700 (PDT) Received: from [66.81.218.36] by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Ls0uA-0000bT-6M; Thu, 09 Apr 2009 16:31:23 -0400 Message-ID: <49DE5B9C.2060805@sri.com> Date: Thu, 09 Apr 2009 13:33:32 -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: <002f01c9b84e$cd26c600$67745200$@nl> <004001c9b861$54d12160$fe736420$@nl> <004e01c9b872$f2a82c60$d7f88520$@nl> <49DDB6B2.6030109@inria.fr> In-Reply-To: <49DDB6B2.6030109@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4787bfcd67ff3a01a6ecc5f158773c27881df12f72faa9263c1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.218.36 Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] OLSRv2 and "per node MPR selection" 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, 09 Apr 2009 20:30:20 -0000 I thought of a better solution that does not require the MPR set for each interface to cover all 2-hop neighbors. Unlike the (inefficient) solution I mentioned that gives priority to neighbors with larger Router IDs, my proposed solution gives priority to interfaces with larger network addresses. (If an interface has multiple addresses, use the largest one.) This can be achieved by modifying the following bullet from Section 7: 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. The modified bullet is: 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, EXCLUDING routers that are symmetric strict 2-hop neighbors through an interface with a larger address, will receive that message on a symmetric link. Thus, the interface with largest address will have a "full" set of MPRs that cover 2-hop neighbors, but a lower numbered interface need not have a full set of MPRs if some of the 2-hop neighbors are covered by MPRs on a higher numbered interface. This solution works for both of Philippe's examples, assuming that a given message is forwarded if there exists an interface on which the message is first received from an MPR selector. In Philippe's last example, assuming that E's interface has a larger address than D's interface, both B and C would select E as MPR (as in the current draft), but would not select D as MPR (unlike the current draft). If the above modification does indeed work while reducing the number of MPRs, then it probably should be incorporated in the draft. Richard P.S. In Philippe's last example, he is assuming that B and C send the same message, originated by another router A that is not shown. This might not have been clear. From xuzhon@gmail.com Sat Apr 11 18:53: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 502063A6B6A for ; Sat, 11 Apr 2009 18:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 w9cPwOYeLGJS for ; Sat, 11 Apr 2009 18:53:20 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 927553A6AF9 for ; Sat, 11 Apr 2009 18:53:20 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1594481wfg.31 for ; Sat, 11 Apr 2009 18:54:30 -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:content-transfer-encoding; bh=RSoWU4LZKFKpS5V16YCaoh3TFI3JnCIveLB+4JXqRh4=; b=EcGlmINZhxxHbHD+s81Xd/5iqpnKR8oSgn0adOk3PWjS+jxnoGVO8oWNPLdt8Urh4a yycj+4a7A331+2vKHOc/p3IK8GwWEu8uaqOZdDnt/yyfm6nvgNa4ncna7wWAvvXD+6QK qHJnw6gWxc5UlGoys/edwIUqQbtBVhMOkhyJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=vE7DAk2xbaglg68Ff4ncVqsZShj12vFHMWgWeCXFZqssYehBWBeSErSQwz7g87s9kr /m5nvQztiLER7iEoxIwGP9HB2UOXqa0QOxtP/su3JSWhwsO4K20poVsav+4D36szGnbY LMQNtcID2h1D5WBBPUb5nAGyKGvh/vKGyCBWI= MIME-Version: 1.0 Received: by 10.142.43.7 with SMTP id q7mr1993534wfq.282.1239501270406; Sat, 11 Apr 2009 18:54:30 -0700 (PDT) Date: Sun, 12 Apr 2009 09:54:30 +0800 Message-ID: <60167b7b0904111854g6b54cb7bk5898c9ceb547fff7@mail.gmail.com> From: Zhong Xu To: manet@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [manet] Problem with OLSR 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: Sun, 12 Apr 2009 01:53:21 -0000 Hi$B!$(B when i did some experiments with OLSR using one PC$B!J(Bcalled node A, OS is windows xp$B!K(B and one embedded board$B!J(Bcalled node B, OS is linux$B!K(B, I met a strange problem. One node can find the other in its neighbour list, but the neighbour sometimes cannot be found in its routing table. This may happens frequently sometimes. In our experiments, each node is equipped with an additional antenna connecting to the 802.11b/g wireless card to enlarge the transmission range. The distance between the two communication nodes is between 300m and 1500m, and under this condtion the link is good and ping is always successful. The configurable parameters of olsr are same in two nodes. By the way we repeat the expriment above in a room (the two nodes are in the room without antenas), the problem hardly ever ocurrs. Any possible reasons given would help me a lot. thanks. 2009-04-12 -- Zhong Xu Ph.D. candidate Northwestern Polytechnical University McGill University zhongxu@cs.mcgill.ca From teco@inf-net.nl Tue Apr 14 02:17:49 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 46DB93A6880 for ; Tue, 14 Apr 2009 02:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[AWL=-0.974, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 Ltz0syC8I6g4 for ; Tue, 14 Apr 2009 02:17:48 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 2F01C3A6A15 for ; Tue, 14 Apr 2009 02:17:47 -0700 (PDT) Received: (qmail 5735 invoked from network); 14 Apr 2009 11:18:55 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 14 Apr 2009 11:18:55 +0200 From: "Teco Boot" To: "'Philippe Jacquet'" References: <002f01c9b84e$cd26c600$67745200$@nl> <004001c9b861$54d12160$fe736420$@nl> <004e01c9b872$f2a82c60$d7f88520$@nl> <49DDB6B2.6030109@inria.fr> In-Reply-To: <49DDB6B2.6030109@inria.fr> Date: Tue, 14 Apr 2009 11:18:31 +0200 Message-ID: <000701c9bce2$0cef2600$26cd7200$@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: Acm48ExjA4L0sqUzRqWpoYNheErFmQD6cCfA Content-Language: nl Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: [manet] MPR selection per interface - race conditions 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, 14 Apr 2009 09:17:49 -0000 Hi Philippe, |In conclusion the order per interfaces does not generate a founded order |on the packets, as soon you have more than two interfaces. When the MPR |are selected per interface makes the order founded again. Do you mean the "per interface MPR selection" method guarantees the requirements for circumventing the race condition? What if the interface connects to a multi-hop sub-IP layer network, like for example Ethernet (or sub-IP multi-hop wireless network)? +---+ +--------+ +---+ /| B |---| switch |---| E |\ / +---+ +--------+ +---+ \ +---+/ | \+---+ | A | | | F | +---+\ | /+---+ \ +---+ +--------+ +---+ / \| C |---| switch |---| D |/ +---+ +--------+ +---+ Network B-C-D-E id full connected. B selects D as MPR. C selects E as MPR. Packets sent by B are received by E before received by D. Packets sent by C are received by D before received by E. I can imagine a future generation radio system that has similar behavior. The system would have time synchronization and multi-channel facilities (FDMA or CDMA). B and C are allowed to send in parallel and both D and E can receive both signals. E is close to B and D is close to C. No jitter, or jitter is neutralized by time synchronization. +---+ +---+ /| B |z------z| E |\ / +---+|\ /|+---+ \ | | | || | | | | || | | | | || | | | | || | +---+/ | \ / | \+---+ | A | | == | | F | +---+\ | / \ | /+---+ | | | || | | | | || | | | | || | | | | || | \ +---+|/ \|+---+ / \| C |z------z| D |/ +---+ +---+ Again, maybe I overlook something. Teco. From ogier@earthlink.net Tue Apr 14 21:11: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 B00B53A6AA2 for ; Tue, 14 Apr 2009 21:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=-0.835, 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 P1b3yK6cFegJ for ; Tue, 14 Apr 2009 21:11:58 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 9AB7E3A6A35 for ; Tue, 14 Apr 2009 21:11:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ZLBykgszW+PWUu6A3ZnE5aJ8/z5LkPetQ6gpDKAxxUY62mg8mr6zcoMe/u8wdA1u; 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.221.10] by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LtwUn-0005gW-5p; Wed, 15 Apr 2009 00:13:10 -0400 Message-ID: <49E55F69.5090607@earthlink.net> Date: Tue, 14 Apr 2009 21:15:37 -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: <000801c9b6fb$9f003fd0$dd00bf70$@nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4787bfcd67ff3a01a6e6be00866698d8222d4247ae41d1ef478350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.221.10 Cc: manet Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 15 Apr 2009 04:11:59 -0000 Dearlove, Christopher (UK) wrote: >(This is not properly threaded, as it seems this email system >doesn't like Richard as well as Charlie. I was actually >checking the archive for any postings by Charlie.) > >Richard Ogier > > >>The race condition that Philippe described can also occur with >>a single interface under certain conditions. For example, >>suppose a MAC protocol is used that decides to "multicast" >>a packet by unicasting it to each neighbor, one at a time. >> >> > >This is also a well-known result. But I do not view it as a >real issue here, as I believe the cases of interest will use >real wireless broadcast. The general multiple unicasting >solution does not scale well (though there are approaches >- I've implemented at least one) that can win back some of >your loss. > > > >>(In some cases, this might be more efficient if there are only 2 or 3 >>neighbors.) >> >> > >And you know who they are. As one of the points of NHDP is >to find your neighbours, which rules out this approach. > > > But the underlying link layer can perform its own neighbor discovery and thus know about (and unicast packets to) neighbors that OLSRv2 has not yet discovered, so my point is still valid in that case. Also, as Teco has shown, the underlying link layer can be a multihop network, in which a packet sent at the same time by two routers (B and C) can arrive at two neighbors (D and E) in different orders, thus causing flooding failure due to the race condition. I was surprised that the draft states "OLSRv2 makes no assumptions about the underlying link layer". I think it is clear that SOME assumptions are needed, unless the rule for forwarding TC messages is modified. But frankly, I prefer that the race condition be avoided using the known solution that Philippe mentioned, so that the above cases can be supported, and so that multiple interfaces can be supported without having to select a full set of MPRs for each interface, thus improving efficiency. The known solution is to wait a short interval, e.g., up to 100 ms, and then forward a given message only if the neighbor with the largest RID from which the message has been received (so far) is an MPR selector. Some MANET implementations delay the forwarding of topology updates anyway, to allow multiple updates to be coalesced in a single packet. As Philippe mentioned, this solution can cause some redundant transmissions, but at least it works without making any assumptions about the link layer! Also, efficiency is potentially improved for multiple interfaces as mentioned above, by allowing MPRs to be selected per node. Richard From teco@inf-net.nl Wed Apr 15 00:40: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 44E4E3A6A21 for ; Wed, 15 Apr 2009 00:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.376, 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 jRtLqesCKGfG for ; Wed, 15 Apr 2009 00:40:09 -0700 (PDT) Received: from CPSMTPM-EML103.kpnxchange.com (cpsmtpm-eml103.kpnxchange.com [195.121.3.7]) by core3.amsl.com (Postfix) with ESMTP id DF43F3A6944 for ; Wed, 15 Apr 2009 00:40:08 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML103.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 15 Apr 2009 09:41:19 +0200 From: "Teco Boot" To: "'Richard Ogier'" , "'Dearlove, Christopher \(UK\)'" References: <000801c9b6fb$9f003fd0$dd00bf70$@nl> <49E55F69.5090607@earthlink.net> In-Reply-To: <49E55F69.5090607@earthlink.net> Date: Wed, 15 Apr 2009 09:41:25 +0200 Message-ID: <002001c9bd9d$94c392d0$be4ab870$@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: Acm9gLBqZ/q0BzFrQ7KeM+yAG4RwSAAFuf8Q Content-Language: nl X-OriginalArrivalTime: 15 Apr 2009 07:41:19.0280 (UTC) FILETIME=[90C03300:01C9BD9D] Cc: 'manet' Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 15 Apr 2009 07:40:10 -0000 Before we step into solution space, I want to see full agreement on the problem. If so, we shall describe limitations of MPR flooding in the OLSRv2 document. Text proposal: MPR flooding in OLSRv2 makes the assumption about the underlying link layer that all receivers of a transmitted packet has the same time of arrival. This may not be true for all types of link layers, e.g. where pseudo-broadcast is used or in multi-hop sub-IP networks. The alternative would be fixing the problem. Side remark here, I think agreement on the problem means opening the discussion on MPR selection per interface. It would be a MAY (or SHOULD), and not a MUST. On solution space: The first one I think of is using jitter (MUST instead of MAY). Jitter timing should be (far) larger than the differences in time of arrival. The problem with this is delayed flooding of important information (e.g. loop avoidance messages). And slowing down convergence in general. Forwarding based on RouterID as Richard suggests may have bad side effects. I think it could initiate flooding back to the originator. There could be solutions based on clock synchronization. Not sure on going that way. Before making decisions here, we have to carefully quantify effects of the remedies. Teco. |-----Oorspronkelijk bericht----- |Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens |Richard Ogier |Verzonden: woensdag 15 april 2009 6:16 |Aan: Dearlove, Christopher (UK) |CC: manet |Onderwerp: Re: [manet] OLSRv2 and forwarding based on MPR | |Dearlove, Christopher (UK) wrote: | |>(This is not properly threaded, as it seems this email system |>doesn't like Richard as well as Charlie. I was actually |>checking the archive for any postings by Charlie.) |> |>Richard Ogier |> |> |>>The race condition that Philippe described can also occur with |>>a single interface under certain conditions. For example, |>>suppose a MAC protocol is used that decides to "multicast" |>>a packet by unicasting it to each neighbor, one at a time. |>> |>> |> |>This is also a well-known result. But I do not view it as a |>real issue here, as I believe the cases of interest will use |>real wireless broadcast. The general multiple unicasting |>solution does not scale well (though there are approaches |>- I've implemented at least one) that can win back some of |>your loss. |> |> |> |>>(In some cases, this might be more efficient if there are only 2 or 3 |>>neighbors.) |>> |>> |> |>And you know who they are. As one of the points of NHDP is |>to find your neighbours, which rules out this approach. |> |> |> | |But the underlying link layer can perform its own neighbor discovery and |thus know about (and unicast packets to) neighbors that OLSRv2 has not |yet discovered, so my point is still valid in that case. | |Also, as Teco has shown, the underlying link layer can be a multihop |network, in which a packet sent at the same time by two routers (B and |C) can arrive at two neighbors (D and E) in different orders, thus |causing flooding failure due to the race condition. | |I was surprised that the draft states "OLSRv2 makes no assumptions about |the underlying link layer". I think it is clear that SOME assumptions |are needed, unless the rule for forwarding TC messages is modified. | |But frankly, I prefer that the race condition be avoided using the known |solution that Philippe mentioned, so that the above cases can be |supported, and so that multiple interfaces can be supported without |having to select a full set of MPRs for each interface, thus improving |efficiency. | |The known solution is to wait a short interval, e.g., up to 100 ms, and |then forward a given message only if the neighbor with the largest RID |from which the message has been received (so far) is an MPR selector. |Some MANET implementations delay the forwarding of topology updates |anyway, to allow multiple updates to be coalesced in a single packet. | |As Philippe mentioned, this solution can cause some redundant |transmissions, but at least it works without making any assumptions |about the link layer! Also, efficiency is potentially improved for |multiple interfaces as mentioned above, by allowing MPRs to be selected |per node. | |Richard | | | |_______________________________________________ |manet mailing list |manet@ietf.org |https://www.ietf.org/mailman/listinfo/manet From Thomas@ThomasClausen.org Wed Apr 15 00:45:55 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 5496F3A67EE for ; Wed, 15 Apr 2009 00:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8gai6bO3KsZ for ; Wed, 15 Apr 2009 00:45:54 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id C62BE3A6911 for ; Wed, 15 Apr 2009 00:45:43 -0700 (PDT) Received: from aste-genev-bois-153-1-11-46.w83-112.abo.wanadoo.fr ([83.112.73.46] helo=[192.168.147.109]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Ltzpe-000HYQ-MB; Wed, 15 Apr 2009 07:46:54 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.73.46 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/c1JDLtVNaB2QYB0NbzRLb In-Reply-To: <002001c9bd9d$94c392d0$be4ab870$@nl> References: <000801c9b6fb$9f003fd0$dd00bf70$@nl> <49E55F69.5090607@earthlink.net> <002001c9bd9d$94c392d0$be4ab870$@nl> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <41CE0ACD-59CF-4849-8A56-99B77469B237@ThomasClausen.org> Content-Transfer-Encoding: 7bit From: Thomas Heide Clausen Date: Wed, 15 Apr 2009 09:47:12 +0200 To: "Teco Boot" X-Mailer: Apple Mail (2.753.1) Cc: "'Dearlove, Christopher \(UK\)'" , 'Richard Ogier' , 'manet' Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 15 Apr 2009 07:45:55 -0000 Teco, On Apr 15, 2009, at 09:41 AM, Teco Boot wrote: > Before we step into solution space, I want to see full agreement on > the > problem. If so, we shall describe limitations of MPR flooding in > the OLSRv2 > document. > > Text proposal: > MPR flooding in OLSRv2 makes the assumption about the underlying > link layer > that all receivers of a transmitted packet has the same time of > arrival. > This may not be true for all types of link layers, e.g. where > pseudo-broadcast is used or in multi-hop sub-IP networks. But, that's incorrect. The present proposed algorithm in the I-D does not require this, but works correctly. > The alternative would be fixing the problem. I believe that the problem was identified years back, fixed then -- and that this fix still applies? > Side remark here, I think agreement on the problem means opening the > discussion on MPR selection per interface. It would be a MAY (or > SHOULD), > and not a MUST. I disagree. > > > On solution space: > > The first one I think of is using jitter (MUST instead of MAY). Jitter > timing should be (far) larger than the differences in time of > arrival. The > problem with this is delayed flooding of important information > (e.g. loop > avoidance messages). And slowing down convergence in general. I disagree. L2s differ, the choice of jitter should too. This is documented in 5148. Thomas > > Forwarding based on RouterID as Richard suggests may have bad side > effects. > I think it could initiate flooding back to the originator. > > There could be solutions based on clock synchronization. Not sure > on going > that way. > > Before making decisions here, we have to carefully quantify effects > of the > remedies. > > > > > Teco. > > > > > |-----Oorspronkelijk bericht----- > |Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens > |Richard Ogier > |Verzonden: woensdag 15 april 2009 6:16 > |Aan: Dearlove, Christopher (UK) > |CC: manet > |Onderwerp: Re: [manet] OLSRv2 and forwarding based on MPR > | > |Dearlove, Christopher (UK) wrote: > | > |>(This is not properly threaded, as it seems this email system > |>doesn't like Richard as well as Charlie. I was actually > |>checking the archive for any postings by Charlie.) > |> > |>Richard Ogier > |> > |> > |>>The race condition that Philippe described can also occur with > |>>a single interface under certain conditions. For example, > |>>suppose a MAC protocol is used that decides to "multicast" > |>>a packet by unicasting it to each neighbor, one at a time. > |>> > |>> > |> > |>This is also a well-known result. But I do not view it as a > |>real issue here, as I believe the cases of interest will use > |>real wireless broadcast. The general multiple unicasting > |>solution does not scale well (though there are approaches > |>- I've implemented at least one) that can win back some of > |>your loss. > |> > |> > |> > |>>(In some cases, this might be more efficient if there are only 2 > or 3 > |>>neighbors.) > |>> > |>> > |> > |>And you know who they are. As one of the points of NHDP is > |>to find your neighbours, which rules out this approach. > |> > |> > |> > | > |But the underlying link layer can perform its own neighbor > discovery and > |thus know about (and unicast packets to) neighbors that OLSRv2 has > not > |yet discovered, so my point is still valid in that case. > | > |Also, as Teco has shown, the underlying link layer can be a multihop > |network, in which a packet sent at the same time by two routers (B > and > |C) can arrive at two neighbors (D and E) in different orders, thus > |causing flooding failure due to the race condition. > | > |I was surprised that the draft states "OLSRv2 makes no assumptions > about > |the underlying link layer". I think it is clear that SOME > assumptions > |are needed, unless the rule for forwarding TC messages is modified. > | > |But frankly, I prefer that the race condition be avoided using the > known > |solution that Philippe mentioned, so that the above cases can be > |supported, and so that multiple interfaces can be supported without > |having to select a full set of MPRs for each interface, thus > improving > |efficiency. > | > |The known solution is to wait a short interval, e.g., up to 100 > ms, and > |then forward a given message only if the neighbor with the largest > RID > |from which the message has been received (so far) is an MPR selector. > |Some MANET implementations delay the forwarding of topology updates > |anyway, to allow multiple updates to be coalesced in a single packet. > | > |As Philippe mentioned, this solution can cause some redundant > |transmissions, but at least it works without making any assumptions > |about the link layer! Also, efficiency is potentially improved for > |multiple interfaces as mentioned above, by allowing MPRs to be > selected > |per node. > | > |Richard > | > | > | > |_______________________________________________ > |manet mailing list > |manet@ietf.org > |https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Wed Apr 15 01:31: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 6F10E3A6A99 for ; Wed, 15 Apr 2009 01:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 zoo8FOBdAely for ; Wed, 15 Apr 2009 01:31: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 D31F23A6A86 for ; Wed, 15 Apr 2009 01:31:40 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML105.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 15 Apr 2009 10:32:51 +0200 From: "Teco Boot" To: "'Thomas Heide Clausen'" References: <000801c9b6fb$9f003fd0$dd00bf70$@nl> <49E55F69.5090607@earthlink.net> <002001c9bd9d$94c392d0$be4ab870$@nl> <41CE0ACD-59CF-4849-8A56-99B77469B237@ThomasClausen.org> In-Reply-To: <41CE0ACD-59CF-4849-8A56-99B77469B237@ThomasClausen.org> Date: Wed, 15 Apr 2009 10:32:57 +0200 Message-ID: <002b01c9bda4$c7bda2f0$5738e8d0$@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: Acm9nn+ZcOqX3hTCRd+axoOnjf5OEgABSDWg Content-Language: nl X-OriginalArrivalTime: 15 Apr 2009 08:32:51.0796 (UTC) FILETIME=[C408B140:01C9BDA4] Cc: "'Dearlove, Christopher \(UK\)'" , 'Richard Ogier' , 'manet' Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 15 Apr 2009 08:31:42 -0000 Hi Thomas, Can you comment on the separate thread, describing the problem? http://www.ietf.org/mail-archive/web/manet/current/msg11061.html I changed the subject to "MPR selection per interface - race conditions" FYI, B and C has other neighbors enforcing MPR for A (same as multi interface scenario). Again, I might overlook the fix. I am afraid there isn't. And I am not a "believer" :-) Teco. |-----Oorspronkelijk bericht----- |Van: Thomas Heide Clausen [mailto:Thomas@ThomasClausen.org] |Verzonden: woensdag 15 april 2009 9:47 |Aan: Teco Boot |CC: 'Richard Ogier'; 'Dearlove, Christopher (UK)'; 'manet' |Onderwerp: [SPAM] Re: [manet] OLSRv2 and forwarding based on MPR |Urgentie: Laag | |Teco, | |On Apr 15, 2009, at 09:41 AM, Teco Boot wrote: | |> Before we step into solution space, I want to see full agreement on |> the |> problem. If so, we shall describe limitations of MPR flooding in |> the OLSRv2 |> document. |> |> Text proposal: |> MPR flooding in OLSRv2 makes the assumption about the underlying |> link layer |> that all receivers of a transmitted packet has the same time of |> arrival. |> This may not be true for all types of link layers, e.g. where |> pseudo-broadcast is used or in multi-hop sub-IP networks. | |But, that's incorrect. The present proposed algorithm in the I-D does |not require this, but works correctly. | |> The alternative would be fixing the problem. | |I believe that the problem was identified years back, fixed then -- |and that this fix still applies? | |> Side remark here, I think agreement on the problem means opening the |> discussion on MPR selection per interface. It would be a MAY (or |> SHOULD), |> and not a MUST. | |I disagree. | |> |> |> On solution space: |> |> The first one I think of is using jitter (MUST instead of MAY). Jitter |> timing should be (far) larger than the differences in time of |> arrival. The |> problem with this is delayed flooding of important information |> (e.g. loop |> avoidance messages). And slowing down convergence in general. | |I disagree. L2s differ, the choice of jitter should too. This is |documented in 5148. | |Thomas | |> |> Forwarding based on RouterID as Richard suggests may have bad side |> effects. |> I think it could initiate flooding back to the originator. |> |> There could be solutions based on clock synchronization. Not sure |> on going |> that way. |> |> Before making decisions here, we have to carefully quantify effects |> of the |> remedies. |> |> |> |> |> Teco. |> |> |> |> |> |-----Oorspronkelijk bericht----- |> |Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens |> |Richard Ogier |> |Verzonden: woensdag 15 april 2009 6:16 |> |Aan: Dearlove, Christopher (UK) |> |CC: manet |> |Onderwerp: Re: [manet] OLSRv2 and forwarding based on MPR |> | |> |Dearlove, Christopher (UK) wrote: |> | |> |>(This is not properly threaded, as it seems this email system |> |>doesn't like Richard as well as Charlie. I was actually |> |>checking the archive for any postings by Charlie.) |> |> |> |>Richard Ogier |> |> |> |> |> |>>The race condition that Philippe described can also occur with |> |>>a single interface under certain conditions. For example, |> |>>suppose a MAC protocol is used that decides to "multicast" |> |>>a packet by unicasting it to each neighbor, one at a time. |> |>> |> |>> |> |> |> |>This is also a well-known result. But I do not view it as a |> |>real issue here, as I believe the cases of interest will use |> |>real wireless broadcast. The general multiple unicasting |> |>solution does not scale well (though there are approaches |> |>- I've implemented at least one) that can win back some of |> |>your loss. |> |> |> |> |> |> |> |>>(In some cases, this might be more efficient if there are only 2 |> or 3 |> |>>neighbors.) |> |>> |> |>> |> |> |> |>And you know who they are. As one of the points of NHDP is |> |>to find your neighbours, which rules out this approach. |> |> |> |> |> |> |> | |> |But the underlying link layer can perform its own neighbor |> discovery and |> |thus know about (and unicast packets to) neighbors that OLSRv2 has |> not |> |yet discovered, so my point is still valid in that case. |> | |> |Also, as Teco has shown, the underlying link layer can be a multihop |> |network, in which a packet sent at the same time by two routers (B |> and |> |C) can arrive at two neighbors (D and E) in different orders, thus |> |causing flooding failure due to the race condition. |> | |> |I was surprised that the draft states "OLSRv2 makes no assumptions |> about |> |the underlying link layer". I think it is clear that SOME |> assumptions |> |are needed, unless the rule for forwarding TC messages is modified. |> | |> |But frankly, I prefer that the race condition be avoided using the |> known |> |solution that Philippe mentioned, so that the above cases can be |> |supported, and so that multiple interfaces can be supported without |> |having to select a full set of MPRs for each interface, thus |> improving |> |efficiency. |> | |> |The known solution is to wait a short interval, e.g., up to 100 |> ms, and |> |then forward a given message only if the neighbor with the largest |> RID |> |from which the message has been received (so far) is an MPR selector. |> |Some MANET implementations delay the forwarding of topology updates |> |anyway, to allow multiple updates to be coalesced in a single packet. |> | |> |As Philippe mentioned, this solution can cause some redundant |> |transmissions, but at least it works without making any assumptions |> |about the link layer! Also, efficiency is potentially improved for |> |multiple interfaces as mentioned above, by allowing MPRs to be |> selected |> |per node. |> | |> |Richard |> | |> | |> | |> |_______________________________________________ |> |manet mailing list |> |manet@ietf.org |> |https://www.ietf.org/mailman/listinfo/manet |> |> _______________________________________________ |> manet mailing list |> manet@ietf.org |> https://www.ietf.org/mailman/listinfo/manet From philippe.jacquet@inria.fr Wed Apr 15 05:18:32 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 383723A694A for ; Wed, 15 Apr 2009 05:18:32 -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 xnkwo3ArZemI for ; Wed, 15 Apr 2009 05:18:31 -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 D4E723A6945 for ; Wed, 15 Apr 2009 05:18:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,192,1238968800"; d="scan'208";a="24626091" Received: from avelizy-152-1-42-114.w82-120.abo.wanadoo.fr (HELO mp-r8.local) ([82.120.245.114]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Apr 2009 14:19:39 +0200 Message-ID: <49E5D1C4.1090802@inria.fr> Date: Wed, 15 Apr 2009 14:23:32 +0200 From: jacquet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Teco Boot References: <002f01c9b84e$cd26c600$67745200$@nl> <004001c9b861$54d12160$fe736420$@nl> <004e01c9b872$f2a82c60$d7f88520$@nl> <49DDB6B2.6030109@inria.fr> <000701c9bce2$0cef2600$26cd7200$@nl> In-Reply-To: <000701c9bce2$0cef2600$26cd7200$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] MPR selection per interface - race conditions 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, 15 Apr 2009 12:18:32 -0000 Hi, Teco, The case you describe sounds to me like an interface with significant propagation delay jitter. While frequently ignored in simple wireless interface, the propagation jitter adds to contention jitter. Of course MANET protocol delay tolerance (and therefore flooding jitter) must be statistically larger than those delays. If propagation jitters are too large then protocols must be designed as in DTNRG that addresses issues about traffic buffering and outdated topology informations. Maybe more on http://www.dtnrg.org/wiki Best regards, Philippe Teco Boot a écrit : > Hi Philippe, > > |In conclusion the order per interfaces does not generate a founded order > |on the packets, as soon you have more than two interfaces. When the MPR > |are selected per interface makes the order founded again. > > Do you mean the "per interface MPR selection" method guarantees the > requirements for circumventing the race condition? > > > What if the interface connects to a multi-hop sub-IP layer network, like for > example Ethernet (or sub-IP multi-hop wireless network)? > > +---+ +--------+ +---+ > /| B |---| switch |---| E |\ > / +---+ +--------+ +---+ \ > +---+/ | \+---+ > | A | | | F | > +---+\ | /+---+ > \ +---+ +--------+ +---+ / > \| C |---| switch |---| D |/ > +---+ +--------+ +---+ > > Network B-C-D-E id full connected. > B selects D as MPR. > C selects E as MPR. > Packets sent by B are received by E before received by D. > Packets sent by C are received by D before received by E. > > > I can imagine a future generation radio system that has similar behavior. > The system would have time synchronization and multi-channel facilities > (FDMA or CDMA). B and C are allowed to send in parallel and both D and E can > receive both signals. E is close to B and D is close to C. No jitter, or > jitter is neutralized by time synchronization. > > +---+ +---+ > /| B |z------z| E |\ > / +---+|\ /|+---+ \ > | | | || | > | | | || | > | | | || | > | | | || | > +---+/ | \ / | \+---+ > | A | | == | | F | > +---+\ | / \ | /+---+ > | | | || | > | | | || | > | | | || | > | | | || | > \ +---+|/ \|+---+ / > \| C |z------z| D |/ > +---+ +---+ > > > Again, maybe I overlook something. > > > Teco. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > From sratliff@cisco.com Wed Apr 15 07:11:51 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 431023A69CF for ; Wed, 15 Apr 2009 07:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 cAmNroZqgXPv for ; Wed, 15 Apr 2009 07:11:50 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3D7CE3A6946 for ; Wed, 15 Apr 2009 07:11:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,192,1238976000"; d="scan'208";a="153503784" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2009 14:13:02 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3FED2sG013013; Wed, 15 Apr 2009 07:13:02 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3FED2Hp001973; Wed, 15 Apr 2009 14:13:02 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 10:13:02 -0400 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: quoted-printable Date: Wed, 15 Apr 2009 10:13:01 -0400 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76407FF8208@xmb-rtp-208.amer.cisco.com> In-Reply-To: <49E55F69.5090607@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 and forwarding based on MPR Thread-Index: Acm9gINx1LioHtUVRMKfa4E3R6fi/gAUpdIQ References: <000801c9b6fb$9f003fd0$dd00bf70$@nl> <49E55F69.5090607@earthlink.net> From: "Stan Ratliff (sratliff)" To: "Richard Ogier" , "Dearlove, Christopher (UK)" X-OriginalArrivalTime: 15 Apr 2009 14:13:02.0153 (UTC) FILETIME=[498E0390:01C9BDD4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4192; t=1239804782; x=1240668782; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[manet]=20OLSRv2=20and=20forwarding=20b ased=20on=20MPR |Sender:=20; bh=VbVJ3duLPQIKh/UsTZMTwOyiP6W5UkqlzaIR8AhIg/M=; b=YJjF9FGrEW1iy2m+dEr9iEp7rK6hRG4QE/G6KPKeQah2GlFQQeULBa4Itd XrNKZ6CS/DGaqF16Dbm8w6uIIFDnBy8QWxS9TWNS1/Tm+Y26y3erobBFUNmv n2s9lRuTxGpkaCSrca1jR+Gh8vkIwv4Ea4wDe5ax24sM0GUhJ7jsA=; Authentication-Results: sj-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: manet Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 15 Apr 2009 14:11:51 -0000 >=20 > But frankly, I prefer that the race condition be avoided=20 > using the known solution that Philippe mentioned, so that the=20 > above cases can be supported, and so that multiple interfaces=20 > can be supported without having to select a full set of MPRs=20 > for each interface, thus improving efficiency. >=20 I agree with Richard - OLSR should be capable of supporting multiple interfaces with a single set of MPR's. I know this discussion has come up *extremely* late in the process, but it's something the WG should pursue. As to the mechanics of *how* to pursue it (e.g. should the current draft be held up, or should this take the form of a subsequent draft), I have no opinion.=20 Regards, Stan > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org]=20 > On Behalf Of Richard Ogier > Sent: Wednesday, April 15, 2009 12:16 AM > To: Dearlove, Christopher (UK) > Cc: manet > Subject: Re: [manet] OLSRv2 and forwarding based on MPR >=20 > Dearlove, Christopher (UK) wrote: >=20 > >(This is not properly threaded, as it seems this email=20 > system doesn't=20 > >like Richard as well as Charlie. I was actually checking the archive=20 > >for any postings by Charlie.) > > > >Richard Ogier > > =20 > > > >>The race condition that Philippe described can also occur with a=20 > >>single interface under certain conditions. For example,=20 > suppose a MAC=20 > >>protocol is used that decides to "multicast" > >>a packet by unicasting it to each neighbor, one at a time. > >> =20 > >> > > > >This is also a well-known result. But I do not view it as a=20 > real issue=20 > >here, as I believe the cases of interest will use real wireless=20 > >broadcast. The general multiple unicasting solution does not=20 > scale well=20 > >(though there are approaches > >- I've implemented at least one) that can win back some of your loss. > > > > =20 > > > >>(In some cases, this might be more efficient if there are=20 > only 2 or 3 > >>neighbors.) > >> =20 > >> > > > >And you know who they are. As one of the points of NHDP is=20 > to find your=20 > >neighbours, which rules out this approach. > > > > =20 > > >=20 > But the underlying link layer can perform its own neighbor=20 > discovery and thus know about (and unicast packets to)=20 > neighbors that OLSRv2 has not yet discovered, so my point is=20 > still valid in that case. >=20 > Also, as Teco has shown, the underlying link layer can be a=20 > multihop network, in which a packet sent at the same time by=20 > two routers (B and > C) can arrive at two neighbors (D and E) in different orders,=20 > thus causing flooding failure due to the race condition. >=20 > I was surprised that the draft states "OLSRv2 makes no=20 > assumptions about the underlying link layer". I think it is=20 > clear that SOME assumptions are needed, unless the rule for=20 > forwarding TC messages is modified. >=20 > But frankly, I prefer that the race condition be avoided=20 > using the known solution that Philippe mentioned, so that the=20 > above cases can be supported, and so that multiple interfaces=20 > can be supported without having to select a full set of MPRs=20 > for each interface, thus improving efficiency. >=20 > The known solution is to wait a short interval, e.g., up to=20 > 100 ms, and then forward a given message only if the neighbor=20 > with the largest RID from which the message has been received=20 > (so far) is an MPR selector. =20 > Some MANET implementations delay the forwarding of topology=20 > updates anyway, to allow multiple updates to be coalesced in=20 > a single packet. >=20 > As Philippe mentioned, this solution can cause some redundant=20 > transmissions, but at least it works without making any=20 > assumptions about the link layer! Also, efficiency is=20 > potentially improved for multiple interfaces as mentioned=20 > above, by allowing MPRs to be selected per node. >=20 > Richard >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 From teco@inf-net.nl Wed Apr 15 07:13: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 549BB28C1EC for ; Wed, 15 Apr 2009 07:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.364, 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 8qR44enIwwCK for ; Wed, 15 Apr 2009 07:13:37 -0700 (PDT) Received: from CPSMTPM-EML104.kpnxchange.com (cpsmtpm-eml104.kpnxchange.com [195.121.3.8]) by core3.amsl.com (Postfix) with ESMTP id C784328C1E7 for ; Wed, 15 Apr 2009 07:13:36 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 15 Apr 2009 16:14:48 +0200 From: "Teco Boot" To: "'jacquet'" References: <002f01c9b84e$cd26c600$67745200$@nl> <004001c9b861$54d12160$fe736420$@nl> <004e01c9b872$f2a82c60$d7f88520$@nl> <49DDB6B2.6030109@inria.fr> <000701c9bce2$0cef2600$26cd7200$@nl> <49E5D1C4.1090802@inria.fr> In-Reply-To: <49E5D1C4.1090802@inria.fr> Date: Wed, 15 Apr 2009 16:14:54 +0200 Message-ID: <001c01c9bdd4$8cb469c0$a61d3d40$@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: Acm9xJxIIvtAFoDfSTCfUxGaKIbI1wACcVRg Content-Language: nl X-OriginalArrivalTime: 15 Apr 2009 14:14:48.0209 (UTC) FILETIME=[88C4E010:01C9BDD4] Cc: "'Dearlove, Christopher \(UK\)'" , manet@ietf.org Subject: Re: [manet] MPR selection per interface - race conditions 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, 15 Apr 2009 14:13:38 -0000 Hi Philippe, |The case you describe sounds to me like an interface with significant |propagation delay jitter. No, the scenario is using just a couple of switches. The hop-by-hop delay is a little longer than jitter due to processing a TC message. Assume no RFC5148 jitter, so TC from A (at T0) is relayed by B and C immediately (at T1). Because they can send to the switch in parallel, and the two switches relay this broadcast in parallel, the TC is received (at T3) by D (from C only), E (from B only) and on both switches (from opposite switch, from the MPR selector) simultaneously. So both D and E receives at T3 the TC from the non-MPR selector, and these are stored in the Received Sets, but not forwarded to F. Both switches forward both the TC messages, switch above the TC relayed by C and the switch below the TC relayed by B. Finally, the TC is received at both D and E (at T4). But these TC messages are also not forwarded to F, because the "seen before on this_interface" check. So F will not receive the TC messages send (or relayed) by A. It doesn't matter how large intervals between T0 to T4 are, less than a millisecond would be enough. The scenario on a hulti-hop wireless sub-IP network is very similar. I would depict a (few) node(s) between (B,E) and (C,D). Assume no hidden terminal problem (e.g. PGM or NORM, but also at sub-IP layer, or TDMA or whatever). Mix of both Ethernet and wireless multi-hop will do also, e.g. the two switches interconnected with a wireless point-to-point bridge. | While frequently ignored in simple wireless |interface, the propagation jitter adds to contention jitter. Yes. But this doesn't matter. The problem occurs because the TC flooding starts in parallel and delivery to the non-MPR selector first is caused by multi-hop. I assume jitter caused by frequency or contention is less than multi-hop forwarding | Of course |MANET protocol delay tolerance (and therefore flooding jitter) must be |statistically larger than those delays. I am not sure if you meant RFC5148 jitter. This is a MAY. I would not use it on Ethernet segments. For the failing scenario, it is disabled. Yes, routing protocols shall tolerate delay / jitter in packet delivery. Unfortunately, this could be a reason for routing loops. A bit out of topic here. |If propagation jitters are too large then protocols must be designed as |in DTNRG that addresses issues about traffic buffering and outdated |topology informations. Maybe more on http://www.dtnrg.org/wiki I would not say a network with a couple of Ethernet switches is a scenario for DTN. Regards, Teco |> What if the interface connects to a multi-hop |> sub-IP layer network, like for example |> Ethernet (or sub-IP multi-hop wireless network)? |> |> +---+ +--------+ +---+ |> /| B |---| switch |---| E |\ |> / +---+ +--------+ +---+ \ |> +---+/ | \+---+ |> | A | | | F | |> +---+\ | /+---+ |> \ +---+ +--------+ +---+ / |> \| C |---| switch |---| D |/ |> +---+ +--------+ +---+ |> |> Network B-C-D-E is full connected. |> B selects D as MPR. |> C selects E as MPR. |> Packets sent by B are received by E before received by D. |> Packets sent by C are received by D before received by E. From ogier@earthlink.net Wed Apr 15 10:41:27 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 C717E3A68C2 for ; Wed, 15 Apr 2009 10:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.651, 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 iJBWk95TRBsM for ; Wed, 15 Apr 2009 10:41:26 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id BCF153A68D5 for ; Wed, 15 Apr 2009 10:41:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=mvbOaxlJaKDwcTXdIjNbFHhVb10oXR0nbph9UeiTWMhuUaVr+EzNFCbT9vD5Tx40; 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.216.95] by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lu987-0005ZO-8d; Wed, 15 Apr 2009 13:42:36 -0400 Message-ID: <49E61D1D.9060901@earthlink.net> Date: Wed, 15 Apr 2009 10:45:01 -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: <000801c9b6fb$9f003fd0$dd00bf70$@nl> <49E55F69.5090607@earthlink.net> <002001c9bd9d$94c392d0$be4ab870$@nl> In-Reply-To: <002001c9bd9d$94c392d0$be4ab870$@nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4787bfcd67ff3a01a6e983a4245f82b04cc4a2c5b6d9248e242350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.216.95 Cc: "'Dearlove, Christopher \(UK\)'" , 'manet' Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 15 Apr 2009 17:41:27 -0000 Teco Boot wrote: >Forwarding based on RouterID as Richard suggests may have bad side effects. >I think it could initiate flooding back to the originator. I can see how this could happen, but simulations should be performed to see if it is really a problem. One way to avoid this is to use the (well-known) MPR-CDS approach, so that a router forwards a message only if its largest-RID neighbor is an MPR selector (or the router itself has a larger RID than all of its neighbors). This way the forwarding rule does not depend on the order in which packets are received from neighbors. The drawback is that messages are not flooded along shortest paths, but on average they are flooded along nearly shortest paths. (If flooding along shortest paths is desired, a router can in addition forward messages based on the current rule.) Philippe wrote: >|If propagation jitters are too large then protocols must be designed as >|in DTNRG that addresses issues about traffic buffering and outdated >|topology informations. Maybe more on http://www.dtnrg.org/wiki I agree with Teco that the cases we are talking about are not DTN cases. The above DTNRG site includes the following sentence, which is not what we are talking about: > Members of DTNRG are concerned with how to address the architectural > and protocol design principles arising from the need to provide > interoperable communications with and among extreme and > performance-challenged environments where continuous end-to-end > connectivity cannot be assumed. Richard From philippe.jacquet@inria.fr Thu Apr 16 05:02:51 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 902F33A6B86 for ; Thu, 16 Apr 2009 05:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.232, 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 cgTn3JMN11d1 for ; Thu, 16 Apr 2009 05:02:50 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 27B423A6B16 for ; Thu, 16 Apr 2009 05:02:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,431,1233529200"; d="scan'208";a="27786481" Received: from mp-41253.rocq.inria.fr ([128.93.41.253]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Apr 2009 14:04:01 +0200 Message-ID: <49E71FA0.5010902@inria.fr> Date: Thu, 16 Apr 2009 14:08:00 +0200 From: jacquet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Richard Ogier References: <000801c9b6fb$9f003fd0$dd00bf70$@nl> <49E55F69.5090607@earthlink.net> <002001c9bd9d$94c392d0$be4ab870$@nl> <49E61D1D.9060901@earthlink.net> In-Reply-To: <49E61D1D.9060901@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "'Dearlove, Christopher \(UK\)'" , 'manet' Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 16 Apr 2009 12:02:51 -0000 Richard, Sorry my last posting was too much elliptic. Regarding DTNRG charter I was merely looking to the sentence: "Said another way, we are concerned with interconnecting highly heterogeneous networks together even if end-to-end connectivity may never be available." In the case presented by Teco, I thought that the "switch" interface was providing very heterogeneous performances. But it is not the case, and the jitter should solve the race problem as mentioned by Thomas. Going back to per node MPR selection versus per interface selection (this was not the point of Teco posting, based on only one interface), my main point was that merging all interfaces for MPR selection may degenerate in DTN situation wrt flooding when interfaces present very heterogeneous performance. In this case I would favor per interface strategy. Let assume that one interface has the longest range. As a natural consequence most MPR will be chosen on this interface. And if this interface is very poor and very slow, then the flooding will be very slow and unreliable. MPR-CDS would not help here. If we would go to a per node strategy then we should probably introduce some limitations on performance discrepancies among interfaces, and consequently limit the use of MANET. Best regards, Philippe Richard Ogier a écrit : > Teco Boot wrote: > >> Forwarding based on RouterID as Richard suggests may have bad side >> effects. >> I think it could initiate flooding back to the originator. > > > I can see how this could happen, but simulations should be performed to > see if it is really a problem. One way to avoid this is to use the > (well-known) MPR-CDS approach, so that a router forwards a message only > if its largest-RID neighbor is an MPR selector (or the router itself has > a larger RID than all of its neighbors). This way the forwarding rule > does not depend on the order in which packets are received from > neighbors. The drawback is that messages are not flooded along > shortest paths, but on average they are flooded along nearly shortest > paths. (If flooding along shortest paths is desired, a router can > in addition forward messages based on the current rule.) > > Philippe wrote: > >> |If propagation jitters are too large then protocols must be designed as >> |in DTNRG that addresses issues about traffic buffering and outdated >> |topology informations. Maybe more on http://www.dtnrg.org/wiki > > > I agree with Teco that the cases we are talking about are not DTN cases. > The above DTNRG site includes the following sentence, which is not what > we are talking about: > >> Members of DTNRG are concerned with how to address the architectural >> and protocol design principles arising from the need to provide >> interoperable communications with and among extreme and >> performance-challenged environments where continuous end-to-end >> connectivity cannot be assumed. > > > Richard > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > From ogier@earthlink.net Thu Apr 16 22:54: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 514603A6800 for ; Thu, 16 Apr 2009 22:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.488, 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 kHmz31-yPGPC for ; Thu, 16 Apr 2009 22:54:37 -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 0EA7F3A6A6C for ; Thu, 16 Apr 2009 22:54:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=NvI9qf1VU9mL822jFqt9XHCUKkFBZqoqwyhdAiJH/Cv+P6tmBW6C/vO3rqlUkEy/; 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.220.93] by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Luh3E-0005xj-Pi; Fri, 17 Apr 2009 01:55:50 -0400 Message-ID: <49E81A7D.2080006@earthlink.net> Date: Thu, 16 Apr 2009 22:58:21 -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: jacquet References: <000801c9b6fb$9f003fd0$dd00bf70$@nl> <49E55F69.5090607@earthlink.net> <002001c9bd9d$94c392d0$be4ab870$@nl> <49E61D1D.9060901@earthlink.net> <49E71FA0.5010902@inria.fr> In-Reply-To: <49E71FA0.5010902@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4787bfcd67ff3a01a6ec4139900d67ab59fc3078c9b6d1e4f16350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.220.93 Cc: 'manet' Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 17 Apr 2009 05:54:38 -0000 jacquet wrote: > Richard, > > Sorry my last posting was too much elliptic. Regarding DTNRG charter I > was merely looking to the sentence: > > "Said another way, we are concerned with interconnecting highly > heterogeneous networks together even if end-to-end connectivity may > never be available." > > In the case presented by Teco, I thought that the "switch" interface > was providing very heterogeneous performances. But it is not the case, > and the jitter should solve the race problem as mentioned by Thomas. > > Going back to per node MPR selection versus per interface selection > (this was not the point of Teco posting, based on only one interface), > my main point was that merging all interfaces for MPR selection may > degenerate in DTN situation wrt flooding when interfaces present very > heterogeneous performance. > > In this case I would favor per interface strategy. Let assume that one > interface has the longest range. As a natural consequence most MPR > will be chosen on this interface. And if this interface is very poor > and very slow, then the flooding will be very slow and unreliable. > MPR-CDS would not help here. Even in the above case, it is still not necessary to define a complete set of MPRs per interface, as I will explain. All you need is to define an ordering on MANET segments (as Teco defined). The ordering can be based on both speed and network addresses, so that faster segments are always preferred, and network addresses are used to break ties. (Metrics can also be used to select MPRs, but what I am proposing should work even if metrics are not used.) The modified MPR property (from Section 14) that I proposed on 4/9 can be rewritten using the above ordering on MANET segments/interfaces. Informally, the property is as follows: The MPRs for a given interface must cover each 2-hop neighbor through that interface that is not also a 2-hop neighbor through a "better" interface. This works on the last example you described (on 4/9), since both B and C will select E as MPR (assuming E is on the better interface). I will show that this also works on the case you described above, which can be represented by the following example, in which *** indicates the fast/better segment. A --- B --- C * / \ * * / \ * D *** E In the naive per-node solution, A would select only B as MPR, so that flooding is through the slow segment. But with the proposed strategy, since *** is the better segment and E is a 2-hop neighbor of A through that segment, A must select D as MPR. In this case, A also selects B as MPR to cover C. But if C is removed from the network, then A would not select B (since E is covered by D through the better interface), in contrast to the per-interface strategy. Richard > > If we would go to a per node strategy then we should probably > introduce some limitations on performance discrepancies among > interfaces, and consequently limit the use of MANET. > > Best regards, > Philippe > > Richard Ogier a écrit : > >> Teco Boot wrote: >> >>> Forwarding based on RouterID as Richard suggests may have bad side >>> effects. >>> I think it could initiate flooding back to the originator. >> >> >> >> I can see how this could happen, but simulations should be performed to >> see if it is really a problem. One way to avoid this is to use the >> (well-known) MPR-CDS approach, so that a router forwards a message only >> if its largest-RID neighbor is an MPR selector (or the router itself has >> a larger RID than all of its neighbors). This way the forwarding rule >> does not depend on the order in which packets are received from >> neighbors. The drawback is that messages are not flooded along >> shortest paths, but on average they are flooded along nearly shortest >> paths. (If flooding along shortest paths is desired, a router can >> in addition forward messages based on the current rule.) >> >> Philippe wrote: >> >>> |If propagation jitters are too large then protocols must be >>> designed as >>> |in DTNRG that addresses issues about traffic buffering and outdated >>> |topology informations. Maybe more on http://www.dtnrg.org/wiki >> >> >> >> I agree with Teco that the cases we are talking about are not DTN cases. >> The above DTNRG site includes the following sentence, which is not what >> we are talking about: >> >>> Members of DTNRG are concerned with how to address the architectural >>> and protocol design principles arising from the need to provide >>> interoperable communications with and among extreme and >>> performance-challenged environments where continuous end-to-end >>> connectivity cannot be assumed. >> >> >> >> Richard >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From teco@inf-net.nl Fri Apr 17 00:44:07 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 339C23A68DB for ; Fri, 17 Apr 2009 00:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 jpfpxDJaom8H for ; Fri, 17 Apr 2009 00:44:06 -0700 (PDT) Received: from CPSMTPM-EML103.kpnxchange.com (cpsmtpm-eml103.kpnxchange.com [195.121.3.7]) by core3.amsl.com (Postfix) with ESMTP id 434BC3A6821 for ; Fri, 17 Apr 2009 00:44:05 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML103.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 17 Apr 2009 09:45:17 +0200 From: "Teco Boot" To: "'jacquet'" , "'Thomas Heide Clausen'" , "'manet'" References: <000801c9b6fb$9f003fd0$dd00bf70$@nl> <49E55F69.5090607@earthlink.net> <002001c9bd9d$94c392d0$be4ab870$@nl> <49E61D1D.9060901@earthlink.net> <49E71FA0.5010902@inria.fr> In-Reply-To: <49E71FA0.5010902@inria.fr> Date: Fri, 17 Apr 2009 09:45:17 +0200 Message-ID: <001401c9bf30$73d0a9c0$5b71fd40$@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: Acm+i5QHUbs756zgSO2Dm4pmQ6FQswAoRsvg Content-Language: nl X-OriginalArrivalTime: 17 Apr 2009 07:45:17.0494 (UTC) FILETIME=[73904560:01C9BF30] Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 17 Apr 2009 07:44:07 -0000 Philippe, Thomas, all, Philippe wrote: |In the case presented by Teco, I thought that the "switch" interface was |providing very heterogeneous performances. But it is not the case, and |the jitter should solve the race problem as mentioned by Thomas. The comments from Thomas were: .... > But, that's incorrect. The present proposed algorithm in the > I-D does not require this, but works correctly. .... > I disagree. L2s differ, the choice of jitter should too. This is > documented in 5148. .... I am lost. First, text update is not needed (it works ALWAYS), then jitter solves the problem (there is NO problem?). My suggestion is rewording in the OLSRv2 text: - There IS an assumption on the underlying link layer - Explain what the assumption is (separate section) - Make jitter a SHOULD, reference to the assumption - Make "per interface MPR selection" a SHOULD, reference to the assumption Now we have two remedies for the race condition. The update on text would not slow down progress that much. Acceptable? Teco. From nhv@crhc.uiuc.edu Fri Apr 17 09:34:30 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 B7A063A6E20 for ; Fri, 17 Apr 2009 09:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 vBuvkYZ7gMJ6 for ; Fri, 17 Apr 2009 09:34:29 -0700 (PDT) Received: from expredir6.cites.uiuc.edu (expredir6.cites.uiuc.edu [128.174.5.97]) by core3.amsl.com (Postfix) with ESMTP id CEEE83A6962 for ; Fri, 17 Apr 2009 09:34:29 -0700 (PDT) Received: from darwin.crhc.uiuc.edu (darwin.crhc.uiuc.edu [130.126.142.206]) by expredir6.cites.uiuc.edu (8.14.2/8.14.2) with ESMTP id n3HGZgPf013111 for ; Fri, 17 Apr 2009 11:35:42 -0500 (CDT) Date: Fri, 17 Apr 2009 11:35:42 -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] Illinois Wireless Summer School 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: Fri, 17 Apr 2009 16:34:30 -0000 Illinois Wireless Summer School =============================== University of Illinois, Urbana-Champaign August 3-7, 2009 Illinois Center for Wireless Systems at the University of Illinois will organize a "Wireless Summer School" during August 3-7, 2009 at Urbana, Illinois. * Travel support to attend the summer school is available. Please apply for travel support at the website below. * There is no registration fee for the summer school. * Attendance at the summer school is open to students and faculty from all universities, and colleagues from industry and government organizations. The total number of attendees will be limited: please apply at the website below if you would like to attend the summer school. * The topics to be covered in the summer school will include antennas, physical layer issues, wireless networking protocols, wireless security, and wireless standards. The summer school will provide the attendees an opportunity to learn about issues affecting various aspects of a wireless system, and also an opportunity to interact with each other. For more information, visit http://www.icws.illinois.edu/school.html The summer school is supported by ACM SIGMOBILE Rockwell Collins Qualcomm Incorporated Microsoft Research NEC Labs If your organization may be able to provide financial support for the summer school, please contact Prof. Nitin Vaidya (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 Chris.Dearlove@baesystems.com Mon Apr 20 02:15:05 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 459CF3A6DAA for ; Mon, 20 Apr 2009 02:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF+XXiLXUdIs for ; Mon, 20 Apr 2009 02:15:04 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by core3.amsl.com (Postfix) with ESMTP id 530243A692D for ; Mon, 20 Apr 2009 02:15:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,216,1238972400"; d="scan'208";a="600188" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 20 Apr 2009 10:16:19 +0100 Received: from glkms1101.GREENLNK.NET (glkms1101.greenlnk.net [10.15.184.109]) by baemasmds009.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n3K9GDit011534; Mon, 20 Apr 2009 10:16:18 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 20 Apr 2009 10:16:18 +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: Mon, 20 Apr 2009 10:16:17 +0100 Message-ID: In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76407FF8208@xmb-rtp-208.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 and forwarding based on MPR Thread-Index: Acm9gINx1LioHtUVRMKfa4E3R6fi/gAUpdIQAPFAneA= References: <000801c9b6fb$9f003fd0$dd00bf70$@nl> <49E55F69.5090607@earthlink.net> <7FB7EE0A621BA44B8B69E5F0A09DC76407FF8208@xmb-rtp-208.amer.cisco.com> From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , "Richard Ogier" X-OriginalArrivalTime: 20 Apr 2009 09:16:18.0744 (UTC) FILETIME=[A9F62380:01C9C198] Cc: manet Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 20 Apr 2009 09:15:05 -0000 Stan > I agree with Richard - OLSR should be capable of supporting multiple > interfaces with a single set of MPR's. It is. You select MPRs per interface, but then you use a single MPR set that combines them all into a single set for use. Only the selecting node is aware of the per interface stuff, the communication to other nodes simply reports MPR status. That's true in 3626 and in OLSRv2. (Of course you should intelligently select the MPRs so that you don't pick an over-large set. There are several possible ways to do this.) ******************************************************************** 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 ian.chakeres@gmail.com Mon Apr 20 05:47: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 155C73A6C89 for ; Mon, 20 Apr 2009 05:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MSbzV31g6jw for ; Mon, 20 Apr 2009 05:47:18 -0700 (PDT) Received: from mail-qy0-f136.google.com (mail-qy0-f136.google.com [209.85.221.136]) by core3.amsl.com (Postfix) with ESMTP id C27D128C251 for ; Mon, 20 Apr 2009 05:45:45 -0700 (PDT) Received: by qyk42 with SMTP id 42so2337610qyk.29 for ; Mon, 20 Apr 2009 05:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date:cc :x-mailer; bh=9iv+vCRcXuMpjx/QcZgcxuOQ1KGWUScoH+WkRiguasc=; b=HqrDVJfRWgUyobHsfGY6KA5hSWdZ0wQ6cLDXho74h+ggzekb+HXfuKK+4TbSoWvSAZ mVhdcu6S55stYxuij959WzDwDUlrdznVSKexc1AxW9qnNoPbF2qW+vMlmMoXxe+pOMv9 XqC+IzpB9h5J+Zg9NVD96y/aSynJBJ0vg01Nk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:cc:x-mailer; b=xWo+xNAiBWKoJotF0Pr69CTJRKwjPl+PgiVQSObUB+3/YQlloBr5WDCt37GBP4CLA1 sCLNtLPL7Fj6EHbLEnaaGEwwhLQ3wdI9FRkStg/LKnCa/PBVlN7brAtF44CPwWzevqq1 mms8g1NoPRvByyapzQZg2Wp08qnrvVn5pt5Lg= Received: by 10.224.11.1 with SMTP id r1mr6037294qar.42.1240231621232; Mon, 20 Apr 2009 05:47:01 -0700 (PDT) Received: from idc.internal.cengen.com ([12.86.3.234]) by mx.google.com with ESMTPS id 4sm4785190qwe.14.2009.04.20.05.47.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Apr 2009 05:47:00 -0700 (PDT) Message-Id: <9F2C1AD5-FD19-4DBA-971F-3B511377B700@gmail.com> From: Ian Chakeres To: manet Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 20 Apr 2009 08:46:59 -0400 X-Mailer: Apple Mail (2.930.3) Subject: [manet] IP protocol 138 and UDP port 269 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, 20 Apr 2009 12:47:19 -0000 Currently IANA has allocated the IP protocol number 138 and UDP port number 269 for use by protocols using PacketBB (RFC 5444). I have initiated this email thread to discuss the default mode of operation for interoperable MANET implementations. Please reply to this thread with your opinion. Thanks. Ian Chakeres From ian.chakeres@gmail.com Mon Apr 20 05:49:20 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 C5E8028C126 for ; Mon, 20 Apr 2009 05:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQC6PLEXtsa0 for ; Mon, 20 Apr 2009 05:49:20 -0700 (PDT) Received: from mail-qy0-f136.google.com (mail-qy0-f136.google.com [209.85.221.136]) by core3.amsl.com (Postfix) with ESMTP id 017063A6F59 for ; Mon, 20 Apr 2009 05:49:19 -0700 (PDT) Received: by qyk42 with SMTP id 42so2339987qyk.29 for ; Mon, 20 Apr 2009 05:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=8yELRpbWbMa/oBWGxiQ8kUEDQRRhFCoC8gOi21XWpNA=; b=WCDxhhyRLF5pf7yFQdfhC8mxkJiModu0ycdfZuCJ8+Ayu5HAFmnPGsRgE3/fDL7zyl cwVYsAgXhZhAJs7w305lzV9105Bf+9b0UQH96SY+arcjKLc0N2tp/F9nBs3ds3jg6/I5 ZEPcAyJnIzyde2Yc6hNf/AEQQ9s5ASmSPNqus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=neNQ6wJ1Eqchq8BDa4FNuD3uyRBDnrCkyZuywqNcqEgG4v4q5cGADLltLi2W9kYcXu dOzXjogD6e7dJRAvqkafv8EkNOzBYJODkqab+vnFDKcrqGqMqO6xEvk/hCyt8mugQJid W9P2VCEaT7v6T8aURVZk5BkXSa8rLe1plCgSU= Received: by 10.224.74.11 with SMTP id s11mr6025756qaj.326.1240231835526; Mon, 20 Apr 2009 05:50:35 -0700 (PDT) Received: from idc.internal.cengen.com ([12.86.3.234]) by mx.google.com with ESMTPS id 5sm1601107qwh.50.2009.04.20.05.50.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Apr 2009 05:50:34 -0700 (PDT) Message-Id: <633EA51C-DD5C-45AA-A894-5E02489C1EA8@gmail.com> From: Ian Chakeres To: manet In-Reply-To: <9F2C1AD5-FD19-4DBA-971F-3B511377B700@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 20 Apr 2009 08:50:33 -0400 References: <9F2C1AD5-FD19-4DBA-971F-3B511377B700@gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [manet] IP protocol 138 and UDP port 269 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, 20 Apr 2009 12:49:20 -0000 My own opinion is that we should use the IP protocol number 138. I feel using an IP protocol number is more common in routing protocols (e.g. OSPF, ISIS) and easily identifies the traffic. Ian Chakeres On Apr 20, 2009, at 8:46 AM, Ian Chakeres wrote: > Currently IANA has allocated the IP protocol number 138 and UDP port > number 269 for use by protocols using PacketBB (RFC 5444). > > I have initiated this email thread to discuss the default mode of > operation for interoperable MANET implementations. > > Please reply to this thread with your opinion. > > Thanks. > Ian Chakeres > From alexandru.petrescu@gmail.com Mon Apr 20 06:57:46 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 55C113A6AE4 for ; Mon, 20 Apr 2009 06:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 LJlf7wOHdZqt for ; Mon, 20 Apr 2009 06:57:45 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id CCBD228C2BF for ; Mon, 20 Apr 2009 06:57:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n3KDuKtu026923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Apr 2009 15:56:20 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n3KE1jNX015042; Mon, 20 Apr 2009 16:01:45 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n3KDwLRo000931; Mon, 20 Apr 2009 15:58:21 +0200 Message-ID: <49EC7F7D.1020200@gmail.com> Date: Mon, 20 Apr 2009 15:58:21 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ian Chakeres References: <9F2C1AD5-FD19-4DBA-971F-3B511377B700@gmail.com> <633EA51C-DD5C-45AA-A894-5E02489C1EA8@gmail.com> In-Reply-To: <633EA51C-DD5C-45AA-A894-5E02489C1EA8@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: manet Subject: Re: [manet] IP protocol 138 and UDP port 269 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, 20 Apr 2009 13:57:46 -0000 Ian Chakeres a écrit : > My own opinion is that we should use the IP protocol number 138. I feel > using an IP protocol number is more common in routing protocols (e.g. > OSPF, ISIS) and easily identifies the traffic. A comment to this would be that it is more straightforward to write UDP applications with UDP port numbers and sockets. (for IP protocol number one would have to use more special RAW sockets, among other alternatives of course). Alex > > Ian Chakeres > > On Apr 20, 2009, at 8:46 AM, Ian Chakeres wrote: > >> Currently IANA has allocated the IP protocol number 138 and UDP port >> number 269 for use by protocols using PacketBB (RFC 5444). >> >> I have initiated this email thread to discuss the default mode of >> operation for interoperable MANET implementations. >> >> Please reply to this thread with your opinion. >> >> Thanks. >> Ian Chakeres >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From csosa@euroempaque.com.mx Mon Apr 20 16:09:39 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 8D7043A6A2D for ; Mon, 20 Apr 2009 16:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 IHBx3Ahg1N-1 for ; Mon, 20 Apr 2009 16:09:38 -0700 (PDT) Received: from mail4.correonegocios.com (mail4.correonegocios.com [200.57.129.36]) by core3.amsl.com (Postfix) with ESMTP id 7C6C73A689E for ; Mon, 20 Apr 2009 16:09:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,330,1233554400"; d="scan'208,217";a="990706119" Received: from smtp.correonegocios.com (HELO mtysmtp06.mexico.hosting.triara) ([200.57.145.15]) by apiron02.correonegocios.com with ESMTP; 20 Apr 2009 18:09:51 -0500 Received: from MTYEXVS11.mexico.hosting.triara ([172.17.30.61]) by mtysmtp06.mexico.hosting.triara with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 18:14:44 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C20D.9A233389" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 20 Apr 2009 18:13:23 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SINR or SNR Thread-Index: AcnCDZoXCOC0wmZMRiOwG67vfL+UuQ== From: "csosa" To: X-OriginalArrivalTime: 20 Apr 2009 23:14:44.0704 (UTC) FILETIME=[CAA67600:01C9C20D] Subject: [manet] SINR or SNR 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, 20 Apr 2009 23:09:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C20D.9A233389 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I wondering if any of you have seen the definition of SNIR or SNR as = follows: $SINR=3D(P/(1+\sigma^{2}))$=20 or if any has an idea about this definition. Thanks=20 Carlos Sosa ------_=_NextPart_001_01C9C20D.9A233389 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SINR or SNR

Dear all,

I wondering if any of you have seen the definition of SNIR or SNR as = follows:

$SINR=3D(P/(1+\sigma^{2}))$


or if any has an idea about this definition.


Thanks


Carlos Sosa

------_=_NextPart_001_01C9C20D.9A233389-- From teco@inf-net.nl Tue Apr 21 00:18:46 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 8D1823A6967 for ; Tue, 21 Apr 2009 00:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 brFpLcozm14R for ; Tue, 21 Apr 2009 00:18:45 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 665E33A67A3 for ; Tue, 21 Apr 2009 00:18:44 -0700 (PDT) Received: (qmail 25182 invoked from network); 21 Apr 2009 09:19:59 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 21 Apr 2009 09:19:59 +0200 From: "Teco Boot" To: "'Ian Chakeres'" , "'manet'" References: <9F2C1AD5-FD19-4DBA-971F-3B511377B700@gmail.com> In-Reply-To: <9F2C1AD5-FD19-4DBA-971F-3B511377B700@gmail.com> Date: Tue, 21 Apr 2009 09:19:20 +0200 Message-ID: <000001c9c251$900647c0$b012d740$@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: AcnBtpexM5BunvxFTbOUPn0Uxl8F/AADBWQg Content-Language: nl Subject: Re: [manet] IP protocol 138 and UDP port 269 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, 21 Apr 2009 07:18:46 -0000 Lets ensure implementations does not lock out each other. I would say: o A standard compliant implementation supports both types of encapsulation o IP encapsulation is the recommended default o UDP encapsulation is used where needed Examples where UDP is used: o link layer does not provide checksums o link layer performance for UDP is better (e.g. header compression) o UDP circumvents problems (e.g. some kind of TCP / UDP firewall) Teco. |-----Oorspronkelijk bericht----- |Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens Ian |Chakeres |Verzonden: maandag 20 april 2009 14:47 |Aan: manet |Onderwerp: [manet] IP protocol 138 and UDP port 269 | |Currently IANA has allocated the IP protocol number 138 and UDP port |number 269 for use by protocols using PacketBB (RFC 5444). | |I have initiated this email thread to discuss the default mode of |operation for interoperable MANET implementations. | |Please reply to this thread with your opinion. | |Thanks. |Ian Chakeres | |_______________________________________________ |manet mailing list |manet@ietf.org |https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Wed Apr 22 08:41: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 7831E28C4CF for ; Wed, 22 Apr 2009 08:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[AWL=-0.392, 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 8YOeCkdwsV4B for ; Wed, 22 Apr 2009 08:41:30 -0700 (PDT) Received: from CPSMTPM-EML101.kpnxchange.com (cpsmtpm-eml101.kpnxchange.com [195.121.3.5]) by core3.amsl.com (Postfix) with ESMTP id 3591528C268 for ; Wed, 22 Apr 2009 08:41:29 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML101.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 22 Apr 2009 17:42:45 +0200 From: "Teco Boot" To: "'manet'" Date: Wed, 22 Apr 2009 17:42:36 +0200 Message-ID: <00a201c9c360$f639f540$e2addfc0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnDYPXz5H9kOTP+SFKQ7UKc35OZAA== Content-Language: nl X-OriginalArrivalTime: 22 Apr 2009 15:42:45.0241 (UTC) FILETIME=[FB044E90:01C9C360] Subject: [manet] Compressed TC and Hello message headers 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, 22 Apr 2009 15:41:31 -0000 A repeating comment on PacketBB was the large overhead for signaling = only a single bit or octet with separate TLVs. I think we can repair = some of this. Below a proposal for more compact TC and Hello message = headers. I used PacketBB syntax for describing the headers. There is no impact on the protocols itself. It is just syntax. If = accepted, drafts need some rewording. Comments? Teco. OLSRv2 - TC message header: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D is defined by: :=3D ? ? where: is a 8-bit field, specifying the interpretation of the remainder of the TC-header: bit 0 (Incomplete): If cleared ('0'), then the TC message is=20 complete. If set ('1'), then TC message is incomplete. bit 1 (TChasInterval): If cleared ('0'), then is = not included in the . If set ('1'), then is included in the . bit 2 (TChasValidity): If cleared ('0'), then is = not included in the . If set ('1'), then is included in the . bits 3-7: Are RESERVED and SHOULD each be cleared ('0') on transmission and SHOULD be ignored on reception. The example in OLSRv2 Appendix E would change from: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1| INTERVAL_TIME |0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1| Value | VALIDITY_TIME |0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1| Value | CONT_SEQ_NUM |0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 0| Value (ANSN) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ to: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| TC_HEADER |0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0 1| TC-flags | TC-ANSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TC-Interval | TC-Validity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLVs size is decreased from 13 to 8 octets (-38%). And there are 5 spare = flag bits. =20 NHDP - Hello message header: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =E2=80=83 is defined by: :=3D ? where: is a 8-bit field, specifying the interpretation of the remainder of the H-header: bit 0 (HhasInterval): If cleared ('0'), then is not included in the . If set ('1'), then is included in the . bits 1-7: Are RESERVED and SHOULD each be cleared ('0') on transmission and SHOULD be ignored on reception. The example in Appendix C would change from: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0| INTERVAL_TIME |0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ to: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0| H_HEADER |0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 1| H-flags | H-Validity | H-Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLVs size is decreased from 8 to 6 octets (-25%). And there are 7 spare = flag bits. =20 From hrogge@googlemail.com Wed Apr 22 08:52:29 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 2690928C585 for ; Wed, 22 Apr 2009 08:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 NLTdaAHygNDN for ; Wed, 22 Apr 2009 08:52:11 -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 D6ABA3A6F3E for ; Wed, 22 Apr 2009 08:52:10 -0700 (PDT) Received: by ewy24 with SMTP id 24so42821ewy.37 for ; Wed, 22 Apr 2009 08:53:27 -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=V2xZUrt7tsP9+qXvyMtur1ai/ONySJO49mrqLsLqGQI=; b=tQFG3IGN/EbV32jv4TVFavJpGJ6wfTmlmjGusFikXQJ271W2fa0y6+NwmwFwAuXxQr J/4FnUq7lvy0hOGM/dp3U/LgYoIKCnstHNpT6WYOs2KeT4hMtENCq+N+/MxS58IWuzxY xpJXFEmMvgmEyfQVA3Tu1sqH5APefW/yUZIV4= 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=tTHMAfZvvQq3Wx1DTX1WnWSmTK+8lCh3UDluJY7KGA+mt5uFXgHALqpm2hFIhHYeDc GVm+Oo2UyVIbgDrweEkACdXsQvOYma8Io48UCmmIKRoPqKn4MjZN4GKU3/SJPQunyJl1 fX59eHpX+KTu1koPDYVHom+yPKNV9vu3SDMi0= Received: by 10.210.71.12 with SMTP id t12mr5546747eba.42.1240415607381; Wed, 22 Apr 2009 08:53:27 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 5sm349840eyf.14.2009.04.22.08.53.26 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Apr 2009 08:53:26 -0700 (PDT) From: Henning Rogge To: manet@ietf.org Date: Wed, 22 Apr 2009 17:53:20 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.29-gentoo-r1; KDE/4.2.2; x86_64; ; ) References: <00a201c9c360$f639f540$e2addfc0$@nl> In-Reply-To: <00a201c9c360$f639f540$e2addfc0$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1564387.WuZ9X7pdQn"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904221753.25551.hrogge@googlemail.com> Subject: Re: [manet] Compressed TC and Hello message headers 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, 22 Apr 2009 15:52:29 -0000 --nextPart1564387.WuZ9X7pdQn Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mittwoch 22 April 2009 17:42:36 Teco Boot wrote: > A repeating comment on PacketBB was the large overhead for signaling only= a > single bit or octet with separate TLVs. I think we can repair some of thi= s. > Below a proposal for more compact TC and Hello message headers. I used > PacketBB syntax for describing the headers. There is no impact on the > protocols itself. It is just syntax. If accepted, drafts need some > rewording. > > Comments? > TC... > TLVs size is decreased from 13 to 8 octets (-38%). And there are 5 spare > flag bits. > Hello... > TLVs size is decreased from 8 to 6 octets (-25%). And there are 7 spare > flag bits. I don't think this is a good idea. You gain a few bytes (constant, not per hello/tc address entry) and loose=20 parts of the flexibility of PacketBB. It's just 5/2 bytes... of potential hundreds of bytes of the message. So it= 's=20 no big gain. PacketBB can be easily parsed by a SAX-style parser, just add a listener fo= r=20 every TLV you are interested in. We would loose this if we start got back t= o=20 the binary syntax. What if we want to add another variable to your header ? We would loose=20 backward compatiblity, because older versions don't know they have to skip = a=20 byte (or a few bytes) if the corresponding bit is set. Henning Rogge --nextPart1564387.WuZ9X7pdQn 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) iEYEABECAAYFAknvPXUACgkQcenvcwAcHWfkswCeOqD2UiGY4FYsTpziZCGxFiym Y8oAnAs3oI/ftOkQYN6csNJPY73xYAHS =8d4e -----END PGP SIGNATURE----- --nextPart1564387.WuZ9X7pdQn-- From ulrich@herberg.name Wed Apr 22 09:02:53 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 9111328C268 for ; Wed, 22 Apr 2009 09:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 pwFm7fUgcDjT for ; Wed, 22 Apr 2009 09:02:52 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 3C32E3A686C for ; Wed, 22 Apr 2009 09:02:51 -0700 (PDT) Received: by bwz7 with SMTP id 7so42092bwz.37 for ; Wed, 22 Apr 2009 09:04:08 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.103.198.20 with SMTP id a20mr4643834muq.63.1240416248559; Wed, 22 Apr 2009 09:04:08 -0700 (PDT) In-Reply-To: <200904221753.25551.hrogge@googlemail.com> References: <00a201c9c360$f639f540$e2addfc0$@nl> <200904221753.25551.hrogge@googlemail.com> Date: Wed, 22 Apr 2009 18:04:08 +0200 X-Google-Sender-Auth: fcbd5ffa53980bcd Message-ID: <25c114b90904220904u6b2db42fl66b3fa3366e5dae@mail.gmail.com> From: Ulrich Herberg To: Henning Rogge Content-Type: multipart/alternative; boundary=0016369fa20dde7985046826e99c Cc: manet@ietf.org Subject: Re: [manet] Compressed TC and Hello message headers 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, 22 Apr 2009 16:02:53 -0000 --0016369fa20dde7985046826e99c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I completely agree with Henning. While the gain is relatively small (consider non-empty-HELLOs using IPv6 could be several hundreds of bytes long), we lose all flexibility of packetbb. As Henning said, one big advantage of packetbb is that it allows a large flexibility while in the same time keeping backwards compatibility. Ulrich On Wed, Apr 22, 2009 at 5:53 PM, Henning Rogge wrote: > On Mittwoch 22 April 2009 17:42:36 Teco Boot wrote: > > A repeating comment on PacketBB was the large overhead for signaling only > a > > single bit or octet with separate TLVs. I think we can repair some of > this. > > Below a proposal for more compact TC and Hello message headers. I used > > PacketBB syntax for describing the headers. There is no impact on the > > protocols itself. It is just syntax. If accepted, drafts need some > > rewording. > > > > Comments? > > > TC... > > TLVs size is decreased from 13 to 8 octets (-38%). And there are 5 spare > > flag bits. > > > Hello... > > TLVs size is decreased from 8 to 6 octets (-25%). And there are 7 spare > > flag bits. > I don't think this is a good idea. > > You gain a few bytes (constant, not per hello/tc address entry) and loose > parts of the flexibility of PacketBB. > > It's just 5/2 bytes... of potential hundreds of bytes of the message. So > it's > no big gain. > > PacketBB can be easily parsed by a SAX-style parser, just add a listener > for > every TLV you are interested in. We would loose this if we start got back > to > the binary syntax. > > What if we want to add another variable to your header ? We would loose > backward compatiblity, because older versions don't know they have to skip > a > byte (or a few bytes) if the corresponding bit is set. > > Henning Rogge > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --0016369fa20dde7985046826e99c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I completely agree with Henning. While the gain is relatively sm= all (consider non-empty-HELLOs using IPv6 could be several hundreds of byte= s long), we lose all flexibility of packetbb. As Henning said, one big adva= ntage of packetbb is that it allows a large flexibility while in the same t= ime keeping backwards compatibility.

Ulrich

On Wed, Apr 22, 2009 at 5:53 P= M, Henning Rogge <hrogge@googlemail.com> wrote:
On Mittwoch 22 April 2009 17:42:36 Teco Boot wrote:
> A repeating comment on PacketBB was the large overhead for signaling o= nly a
> single bit or octet with separate TLVs. I think we can repair some of = this.
> Below a proposal for more compact TC and Hello message headers. I used=
> PacketBB syntax for describing the headers. There is no impact on the<= br> > protocols itself. It is just syntax. If accepted, drafts need some
> rewording.
>
> Comments?

> TC...
> TLVs size is decreased from 13 to 8 octets (-38%). And there are = 5 spare
> flag bits.

> Hello...
> TLVs size is decreased from 8 to 6 octets (-25%). And there are 7= spare
> flag bits.
I don't think this is a good idea.

You gain a few bytes (constant, not per hello/tc address entry) and loose parts of the flexibility of PacketBB.

It's just 5/2 bytes... of potential hundreds of bytes of the message. S= o it's
no big gain.

PacketBB can be easily parsed by a SAX-style parser, just add a listener fo= r
every TLV you are interested in. We would loose this if we start got back t= o
the binary syntax.

What if we want to add another variable to your header ? We would loose
backward compatiblity, because older versions don't know they have to s= kip a
byte (or a few bytes) if the corresponding bit is set.

Henning Rogge

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


--0016369fa20dde7985046826e99c-- From ietf@thomasclausen.org Wed Apr 22 11:41:45 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 223493A7167 for ; Wed, 22 Apr 2009 11:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 7IXa973-98dq for ; Wed, 22 Apr 2009 11:41:44 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id BA45A3A716A for ; Wed, 22 Apr 2009 11:41:26 -0700 (PDT) Received: from aste-genev-bois-153-1-10-151.w83-112.abo.wanadoo.fr ([83.112.72.151] helo=[192.168.147.109]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LwhP8-000H9s-OM; Wed, 22 Apr 2009 18:42:43 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.72.151 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18qshNAvpgyUpZ6MIQymV9T In-Reply-To: <25c114b90904220904u6b2db42fl66b3fa3366e5dae@mail.gmail.com> References: <00a201c9c360$f639f540$e2addfc0$@nl> <200904221753.25551.hrogge@googlemail.com> <25c114b90904220904u6b2db42fl66b3fa3366e5dae@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/alternative; boundary=Apple-Mail-19-125583871 Message-Id: From: Thomas Heide Clausen Date: Wed, 22 Apr 2009 20:43:08 +0200 To: Ulrich Herberg X-Mailer: Apple Mail (2.753.1) Cc: manet@ietf.org Subject: Re: [manet] Compressed TC and Hello message headers 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, 22 Apr 2009 18:41:45 -0000 --Apple-Mail-19-125583871 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I agree fully with Henning and Ulrich on this matter: a small gain at a huge loss in flexibility is not a trade-off that I think appropriate. Thomas On Apr 22, 2009, at 18:04 PM, Ulrich Herberg wrote: > Hi, > > I completely agree with Henning. While the gain is relatively small > (consider non-empty-HELLOs using IPv6 could be several hundreds of > bytes long), we lose all flexibility of packetbb. As Henning said, > one big advantage of packetbb is that it allows a large flexibility > while in the same time keeping backwards compatibility. > > Ulrich > > On Wed, Apr 22, 2009 at 5:53 PM, Henning Rogge > wrote: > On Mittwoch 22 April 2009 17:42:36 Teco Boot wrote: > > A repeating comment on PacketBB was the large overhead for > signaling only a > > single bit or octet with separate TLVs. I think we can repair > some of this. > > Below a proposal for more compact TC and Hello message headers. I > used > > PacketBB syntax for describing the headers. There is no impact on > the > > protocols itself. It is just syntax. If accepted, drafts need some > > rewording. > > > > Comments? > > > TC... > > TLVs size is decreased from 13 to 8 octets (-38%). And there are > 5 spare > > flag bits. > > > Hello... > > TLVs size is decreased from 8 to 6 octets (-25%). And there are 7 > spare > > flag bits. > I don't think this is a good idea. > > You gain a few bytes (constant, not per hello/tc address entry) and > loose > parts of the flexibility of PacketBB. > > It's just 5/2 bytes... of potential hundreds of bytes of the > message. So it's > no big gain. > > PacketBB can be easily parsed by a SAX-style parser, just add a > listener for > every TLV you are interested in. We would loose this if we start > got back to > the binary syntax. > > What if we want to add another variable to your header ? We would > loose > backward compatiblity, because older versions don't know they have > to skip a > byte (or a few bytes) if the corresponding bit is set. > > Henning Rogge > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-19-125583871 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII I agree fully with Henning and Ulrich on this matter: a small gain at a = huge loss in flexibility is not a trade-off that I think = appropriate.

Thomas

On Apr 22, = 2009, at 18:04 PM, Ulrich Herberg wrote:

Hi,

I= completely agree with Henning. While the gain is relatively small = (consider non-empty-HELLOs using IPv6 could be several hundreds of bytes = long), we lose all flexibility of packetbb. As Henning said, one big = advantage of packetbb is that it allows a large flexibility while in the = same time keeping backwards compatibility.

Ulrich

On Wed, Apr 22, 2009 at 5:53 PM, Henning Rogge = <hrogge@googlemail.com> = wrote:
On Mittwoch 22 April 2009 17:42:36 Teco Boot wrote:
> A = repeating comment on PacketBB was the large overhead for signaling only = a
> single bit or octet with separate TLVs. I think we can repair = some of this.
> Below a proposal for more compact TC and Hello = message headers. I used
> PacketBB syntax for describing the = headers. There is no impact on the
> protocols itself. It is just = syntax. If accepted, drafts need some
> rewording.
>
> = Comments?

> TC...
> TLVs size is decreased from = 13 to 8 octets (-38%). And there are 5 spare
> flag bits.

=
> Hello...
> TLVs size is decreased from 8 to 6 octets = (-25%). And there are 7 spare
> flag bits.
I don't think = this is a good idea.

You gain a few bytes (constant, not per = hello/tc address entry) and loose
parts of the flexibility of = PacketBB.

It's just 5/2 bytes... of potential hundreds of bytes = of the message. So it's
no big gain.

PacketBB can be easily = parsed by a SAX-style parser, just add a listener for
every TLV you = are interested in. We would loose this if we start got back to
the = binary syntax.

What if we want to add another variable to your = header ? We would loose
backward compatiblity, because older = versions don't know they have to skip a
byte (or a few bytes) if the = corresponding bit is set.

Henning = Rogge

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

manet mailing list
=

= --Apple-Mail-19-125583871-- From teco@inf-net.nl Wed Apr 22 12:55:17 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 E802B3A6816 for ; Wed, 22 Apr 2009 12:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.359, 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 UZVlmUIbkszj for ; Wed, 22 Apr 2009 12:55:16 -0700 (PDT) Received: from CPSMTPM-EML104.kpnxchange.com (cpsmtpm-eml104.kpnxchange.com [195.121.3.8]) by core3.amsl.com (Postfix) with ESMTP id ECBA528C53D for ; Wed, 22 Apr 2009 12:55:15 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 22 Apr 2009 21:56:31 +0200 From: "Teco Boot" To: "'Thomas Heide Clausen'" , "'Ulrich Herberg'" References: <00a201c9c360$f639f540$e2addfc0$@nl> <200904221753.25551.hrogge@googlemail.com> <25c114b90904220904u6b2db42fl66b3fa3366e5dae@mail.gmail.com> In-Reply-To: Date: Wed, 22 Apr 2009 21:56:22 +0200 Message-ID: <000801c9c384$699399b0$3cbacd10$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnDemQfEZ5o1l5lT+6UsOfb14PhsQAAYd+A Content-Language: nl X-OriginalArrivalTime: 22 Apr 2009 19:56:31.0980 (UTC) FILETIME=[6EDC4AC0:01C9C384] Cc: manet@ietf.org Subject: Re: [manet] Compressed TC and Hello message headers 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, 22 Apr 2009 19:55:18 -0000 Hi Henning, Ulrich and Thomas, I fully agree: the proposal is a small gain. Dutch saying: "wie het kleine niet eert, is het grote niet weerd". This means: "who refuses what's small, doesn't deserve what's big". By the way, we had discussions on few octets before. And keep in mind = the TC header may appear in a packet many times. And TCs would be small = if topology reduction works fine. I strongly disagree with "huge loss in flexibility", because it is = incorrect. But yes, it is time to carefully verify what function is = mandatory and what is not. When the std is published, all additions are = optional. We can use spare flags (to be ignored on reception by nodes = that doesn't support the option) or a new TLVs. Why do you think my = suggestion blocks any of this ?? I do not understand Hennings parsing argument. Packet and message header = are parsed exactly as what I suggest for TC and Hello headers. So = parsing logic is already there. And the header fields must be supported, = so all implementations must parse it. Yes, I think we should not add optional header fields and indicate this = with flags. Same comment applies for RFC5444, so nothing new here.=20 Comment on Ulrich his statement that IPv6 hellos are "long". There is no = reason for this, as packetBB can compress IPv6 to the same length as = IPv4 IDs. It is a matter of addressing scheme. This area is my day to = job (or struggle..) in real world ad hoc networks. I may need IPv6 for = good reasons. And I definitely need efficient transport of data, also = for good reasons. My split mind: unique addresses by nature (random, = EUI-64, etc.) are great for reducing network management efforts, but at = the same time the addresses are hard to compress. This is one of the = reasons I am working on RouterIDs, msgs will be compact as long as the = RouterIDs and delegated prefixes can be compressed. This is doable. Please think again on the proposal. I know it is a small gain. But = still: it is gain. There is no disadvantage. Not at all !! Teco. NB.=20 I corrected TC-header. TC-Validity is always there so flag is not = needed. See adjusted proposal below. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens = Thomas Heide Clausen Verzonden: woensdag 22 april 2009 20:43 Aan: Ulrich Herberg CC: manet@ietf.org Onderwerp: Re: [manet] Compressed TC and Hello message headers I agree fully with Henning and Ulrich on this matter: a small gain at a = huge loss in flexibility is not a trade-off that I think appropriate. Thomas On Apr 22, 2009, at 18:04 PM, Ulrich Herberg wrote: Hi, I completely agree with Henning. While the gain is relatively small = (consider non-empty-HELLOs using IPv6 could be several hundreds of bytes = long), we lose all flexibility of packetbb. As Henning said, one big = advantage of packetbb is that it allows a large flexibility while in the = same time keeping backwards compatibility. Ulrich On Wed, Apr 22, 2009 at 5:53 PM, Henning Rogge = wrote: On Mittwoch 22 April 2009 17:42:36 Teco Boot wrote: > A repeating comment on PacketBB was the large overhead for signaling = only a > single bit or octet with separate TLVs. I think we can repair some of = this. > Below a proposal for more compact TC and Hello message headers. I used > PacketBB syntax for describing the headers. There is no impact on the > protocols itself. It is just syntax. If accepted, drafts need some > rewording. > > Comments? > TC... > TLVs size is decreased from 13 to 8 octets (-38%). And there are 5 = spare > flag bits. > Hello... > TLVs size is decreased from 8 to 6 octets (-25%). And there are 7 = spare > flag bits. I don't think this is a good idea. You gain a few bytes (constant, not per hello/tc address entry) and = loose parts of the flexibility of PacketBB. It's just 5/2 bytes... of potential hundreds of bytes of the message. So = it's no big gain. PacketBB can be easily parsed by a SAX-style parser, just add a listener = for every TLV you are interested in. We would loose this if we start got = back to the binary syntax. What if we want to add another variable to your header ? We would loose backward compatiblity, because older versions don't know they have to = skip a byte (or a few bytes) if the corresponding bit is set. Henning Rogge _______________________________________________ OLSRv2 - TC message header: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D is defined by: :=3D ? where: is a 8-bit field, specifying the interpretation of the remainder of the TC-header: bit 0 (Incomplete): If cleared ('0'), then the TC message is=20 complete. If set ('1'), then TC message is incomplete. bit 1 (TChasInterval): If cleared ('0'), then is = not included in the . If set ('1'), then is included in the . bits 2-7: Are RESERVED and SHOULD each be cleared ('0') on transmission and SHOULD be ignored on reception. The example in OLSRv2 Appendix E would change from: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1| INTERVAL_TIME |0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1| Value | VALIDITY_TIME |0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1| Value | CONT_SEQ_NUM |0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 0| Value (ANSN) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ to: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| TC_HEADER |0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0 1| TC-flags | TC-ANSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TC-Validity | TC-Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLVs size is decreased from 13 to 8 octets (-38%). And there are 5 spare = flag bits. =20 NHDP - Hello message header: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =E2=80=83 is defined by: :=3D ? where: is a 8-bit field, specifying the interpretation of the remainder of the H-header: bit 0 (HhasInterval): If cleared ('0'), then is not included in the . If set ('1'), then is included in the . bits 1-7: Are RESERVED and SHOULD each be cleared ('0') on transmission and SHOULD be ignored on reception. The example in Appendix C would change from: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0| INTERVAL_TIME |0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ to: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0| H_HEADER |0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 1| H-flags | H-Validity | H-Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLVs size is decreased from 8 to 6 octets (-25%). And there are 7 spare = flag bits. =20 From ogier@earthlink.net Wed Apr 22 20: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 C550228C41A for ; Wed, 22 Apr 2009 20:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[AWL=-0.354, 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 FnIE58JdkvC3 for ; Wed, 22 Apr 2009 20:46:36 -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 C05A33A6918 for ; Wed, 22 Apr 2009 20:45:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Kv20Uq6cQg210qXUBygmWqM/FmqEq3NPJuIyRY8bYkVV1LUqWHTJAWFtSr7EaIhE; 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.221.186] by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lwpu1-0007Gf-1F; Wed, 22 Apr 2009 23:47:11 -0400 Message-ID: <49EFE568.20408@earthlink.net> Date: Wed, 22 Apr 2009 20:50:00 -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: <000801c9b6fb$9f003fd0$dd00bf70$@nl> <49E55F69.5090607@earthlink.net> <002001c9bd9d$94c392d0$be4ab870$@nl> <49E61D1D.9060901@earthlink.net> <49E71FA0.5010902@inria.fr> <001401c9bf30$73d0a9c0$5b71fd40$@nl> In-Reply-To: <001401c9bf30$73d0a9c0$5b71fd40$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478eae09f65131c9d1f071e3b17c26f65916c520005410f38f7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.221.186 Cc: 'manet' Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 23 Apr 2009 03:46:37 -0000 This is a reply to Teco's message, but first I will respond to the following to clarify the goal and terminology. Christopher Dearlove wrote: > It is. You select MPRs per interface, but then you use a single > MPR set that combines them all into a single set for use. I have no problem with selecting a set of MPRs for each interface. The objection that some of us have is requiring the set of MPRs for each interface to cover all 2-hop neighbors for that interface, even if some of those 2-hop neighbors can be covered by MPRs for another interface. I refer to this requirement by saying that the draft requires a "complete" set of MPRs per interface. When I say "per-node MPRs", I just mean the MPR set for each interface need not be complete, as long as the union of the MPR sets covers all 2-hop neighbors. One reason given for requiring a complete set of MPRs per interface is the race condition, but it has been noted that the race condition can be fixed by using jitter. Another reason given by Philippe is the possibility of flooding over the slowest interfaces. However, that can be avoided by giving priority to the fastest interfaces when selecting MPRs. Currently, there are NO assumptions on the underlying link layer. As noted, there must at least be some limit on the propagation delay, e.g., it must be less than the flooding jitter. But if flooding jitter is used, this also fixes the race condition for multiple interfaces, so it is not necessary to select a complete set of MPRs per interface. I mostly agree with Teco's suggested changes (see his message below), but here is a modified list of suggested changes based on the above considerations: - Flooding jitter SHOULD be used. - Flooding jitter MUST be used if any link has the property that a packet transmitted simultaneously by two routers B and C can be received in different orders by two common neighbors D and E. - If flooding jitter is NOT used, the router MUST select a complete set of MPRs per interface. - If flooding jitter is used, then the MPR set for each interface need not be complete, as long as all 2-hop neighbors are covered by the union of the MPR sets. I also mentioned a solution that avoids the race condition without jitter and without selecting a complete set of MPRs per interface (by defining an ordering on MANET segments, and using an MPR-CDS), but the above suggestions are similar to Teco's suggestions and do not require much change to the draft. Richard Teco Boot wrote: >Philippe, Thomas, all, > >Philippe wrote: >|In the case presented by Teco, I thought that the "switch" interface was >|providing very heterogeneous performances. But it is not the case, and >|the jitter should solve the race problem as mentioned by Thomas. > >The comments from Thomas were: >.... > > >>But, that's incorrect. The present proposed algorithm in the >>I-D does not require this, but works correctly. >> >> >.... > > >>I disagree. L2s differ, the choice of jitter should too. This is >>documented in 5148. >> >> >.... >I am lost. First, text update is not needed (it works ALWAYS), then jitter >solves the problem (there is NO problem?). > > >My suggestion is rewording in the OLSRv2 text: > - There IS an assumption on the underlying link layer > - Explain what the assumption is (separate section) > - Make jitter a SHOULD, reference to the assumption > - Make "per interface MPR selection" a SHOULD, reference > to the assumption > >Now we have two remedies for the race condition. The update on text would >not slow down progress that much. Acceptable? > > >Teco. > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet > > > From Rogge@fgan.de Wed Apr 22 22:56: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 370DE3A6F92 for ; Wed, 22 Apr 2009 22:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_DE=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 SxPc6KYfnie8 for ; Wed, 22 Apr 2009 22:56:37 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id F26873A68C5 for ; Wed, 22 Apr 2009 22:55:41 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Lwrvb-0005Ki-TI; Thu, 23 Apr 2009 07:56:56 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1Lwrvb-000131-Cm; Thu, 23 Apr 2009 07:56:55 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Apr 2009 07:56:55 +0200 From: Henning Rogge To: manet@ietf.org Date: Thu, 23 Apr 2009 07:56:48 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.26-1-openvz-686; KDE/4.1.4; i686; ; ) References: <00a201c9c360$f639f540$e2addfc0$@nl> <000801c9c384$699399b0$3cbacd10$@nl> In-Reply-To: <000801c9c384$699399b0$3cbacd10$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1390557.jN4YRUxHVS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904230756.54940.rogge@fgan.de> X-OriginalArrivalTime: 23 Apr 2009 05:56:55.0291 (UTC) FILETIME=[4E6D54B0:01C9C3D8] X-Virus-Scanned: yes (ClamAV 0.94.2/9276/Thu Apr 23 00:55:59 2009) by mailguard.fgan.de X-Scan-Signature: 0b497576f449e917e3905a24562e6e3e Cc: 'Thomas Heide Clausen' Subject: Re: [manet] Compressed TC and Hello message headers 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, 23 Apr 2009 05:56:38 -0000 --nextPart1390557.jN4YRUxHVS Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Wednesday 22 April 2009 21:56:22 schrieb Teco Boot: > Hi Henning, Ulrich and Thomas, > > I fully agree: the proposal is a small gain. > Dutch saying: "wie het kleine niet eert, is het grote niet weerd". > This means: "who refuses what's small, doesn't deserve what's big". > By the way, we had discussions on few octets before. And keep in mind the > TC header may appear in a packet many times. And TCs would be small if > topology reduction works fine. > > I strongly disagree with "huge loss in flexibility", because it is > incorrect. But yes, it is time to carefully verify what function is > mandatory and what is not. When the std is published, all additions are > optional. We can use spare flags (to be ignored on reception by nodes that > doesn't support the option) or a new TLVs. Why do you think my suggestion > blocks any of this ?? > > I do not understand Hennings parsing argument. Packet and message header > are parsed exactly as what I suggest for TC and Hello headers. So parsing > logic is already there. And the header fields must be supported, so all > implementations must parse it. Yes, I think we should not add optional > header fields and indicate this with flags. Same comment applies for > RFC5444, so nothing new here. A change of RFC5444 and a change of NHDP/OLSRv2 messages is something=20 completely different. PacketBB messages with additional fields can be EASILY read by old versions of OLSR, because the TLV headers contain the necessary= =20 information to skip unknown fields. Compress them into a bitfield plus a=20 number of binary values and you can only do this if you have knowledge abou= t=20 he length of the fields represented by each bit. There is a reason why=20 packetbb lost a number of header fields and corresponding control bits (the= y=20 will be represented as TLV fields). An example... you define your "compressed" TC header this way: =C2=A0 =C2=A0 :=3D =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ? This is already a problem for packetbb readers because they need knowledge= =20 about the internal structure of the TC header to display the values and par= se=20 the following address block. One of the great things of packetbb is that yo= u=20 can parse a message WITHOUT knowing anything about the semantic of the=20 messages. But let's say we do it your way, and later we decide we need a new field in= =20 the header called , which is two byte in length. The new header would look like :=3D ? ? ? Because the old parser don't know about the additional used bit in the=20 field and don't know about the length (or even existence) of the= =20 new field, they cannot parse this message ! Some of the old pars= ers=20 will even ignore the bit and mix up the field with the beginning= of=20 an address block ! > Comment on Ulrich his statement that IPv6 hellos are "long". There is no > reason for this, as packetBB can compress IPv6 to the same length as IPv4 > IDs. It is a matter of addressing scheme. This area is my day to job (or > struggle..) in real world ad hoc networks. I may need IPv6 for good > reasons. And I definitely need efficient transport of data, also for good > reasons. My split mind: unique addresses by nature (random, EUI-64, etc.) > are great for reducing network management efforts, but at the same time t= he > addresses are hard to compress. This is one of the reasons I am working on > RouterIDs, msgs will be compact as long as the RouterIDs and delegated > prefixes can be compressed. This is doable. Sometimes you want RouterIDs, sometimes you don't want them because you run= an=20 simple autoconfiguration protocol. But 3-5 bytes is still very small compar= ed=20 to the whole OLSR message. > Please think again on the proposal. I know it is a small gain. But still: > it is gain. There is no disadvantage. Not at all !! Yes, there is... Henning ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=C3=BCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart1390557.jN4YRUxHVS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAknwAyEACgkQRIfGfFXsz+BvpgCdF/JE+AlzR7qmELm1ECklbxw1 DogAnipMMzGPyxGYoRJhQXZi21GE3rUt =TQ3n -----END PGP SIGNATURE----- --nextPart1390557.jN4YRUxHVS-- From teco@inf-net.nl Wed Apr 22 23:38:43 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 0DEA73A6B76 for ; Wed, 22 Apr 2009 23:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.134 X-Spam-Level: X-Spam-Status: No, score=-1.134 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 A+7VLNc5BeQv for ; Wed, 22 Apr 2009 23:38:42 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id AAD5E3A67AE for ; Wed, 22 Apr 2009 23:38:40 -0700 (PDT) Received: (qmail 24741 invoked from network); 23 Apr 2009 08:39:55 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 23 Apr 2009 08:39:55 +0200 From: "Teco Boot" To: "'Richard Ogier'" References: <000801c9b6fb$9f003fd0$dd00bf70$@nl> <49E55F69.5090607@earthlink.net> <002001c9bd9d$94c392d0$be4ab870$@nl> <49E61D1D.9060901@earthlink.net> <49E71FA0.5010902@inria.fr> <001401c9bf30$73d0a9c0$5b71fd40$@nl> <49EFE568.20408@earthlink.net> In-Reply-To: <49EFE568.20408@earthlink.net> Date: Thu, 23 Apr 2009 08:39:17 +0200 Message-ID: <002e01c9c3de$4bc41ef0$e34c5cd0$@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: AcnDxlVfvx4bCryoSdGmBUFcrUTG0QAFmOnw Content-Language: nl Cc: 'manet' Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 23 Apr 2009 06:38:43 -0000 Hi Richard, all, Thanks for the clarifications. I still do not agree on >> Currently, there are NO assumptions on the underlying link layer I came up with a scenario where MPR selection per interface and no jitter does not work. I waited over a week for comments (what do I overlook ??). No one did response with a clear answer (Thomas Clausen "believed" is was solved, maybe he thought of jitter). If time permits, I'll build a demonstrator. I would not say MPR is broken, but there are corner cases where it fails. I am fine with better specification where to use jitter (the MUST) and where it is not needed (e.g. no hidden terminal problems, no multi-hop underlying link layer, no out of order message reception) Teco. |-----Oorspronkelijk bericht----- |Van: Richard Ogier [mailto:ogier@earthlink.net] |Verzonden: donderdag 23 april 2009 5:50 |Aan: Teco Boot |CC: 'manet' |Onderwerp: Re: [manet] OLSRv2 and forwarding based on MPR | |This is a reply to Teco's message, but first I will respond |to the following to clarify the goal and terminology. | |Christopher Dearlove wrote: | |> It is. You select MPRs per interface, but then you use a single |> MPR set that combines them all into a single set for use. | | |I have no problem with selecting a set of MPRs for each interface. |The objection that some of us have is requiring the set of MPRs for |each interface to cover all 2-hop neighbors for that interface, even |if some of those 2-hop neighbors can be covered by MPRs for another |interface. I refer to this requirement by saying that the draft |requires a "complete" set of MPRs per interface. |When I say "per-node MPRs", I just mean the MPR set for each |interface need not be complete, as long as the union of the |MPR sets covers all 2-hop neighbors. | |One reason given for requiring a complete set of MPRs per interface |is the race condition, but it has been noted that the race condition |can be fixed by using jitter. |Another reason given by Philippe is the possibility of flooding |over the slowest interfaces. However, that can be avoided by |giving priority to the fastest interfaces when selecting MPRs. | |Currently, there are NO assumptions on the underlying link layer. |As noted, there must at least be some limit on the propagation |delay, e.g., it must be less than the flooding jitter. |But if flooding jitter is used, this also fixes the race |condition for multiple interfaces, so it is not necessary to |select a complete set of MPRs per interface. | |I mostly agree with Teco's suggested changes (see his message below), |but here is a modified list of suggested changes based on the above |considerations: | | - Flooding jitter SHOULD be used. | - Flooding jitter MUST be used if any link has the property | that a packet transmitted simultaneously by two routers B and C | can be received in different orders by two common neighbors | D and E. | - If flooding jitter is NOT used, the router MUST select a | complete set of MPRs per interface. | - If flooding jitter is used, then the MPR set for each | interface need not be complete, as long as all 2-hop | neighbors are covered by the union of the MPR sets. | |I also mentioned a solution that avoids the race condition |without jitter and without selecting a complete set of MPRs |per interface (by defining an ordering on MANET segments, |and using an MPR-CDS), but the above suggestions are similar |to Teco's suggestions and do not require much change to |the draft. | |Richard | | |Teco Boot wrote: | |>Philippe, Thomas, all, |> |>Philippe wrote: |>|In the case presented by Teco, I thought that the "switch" interface |was |>|providing very heterogeneous performances. But it is not the case, and |>|the jitter should solve the race problem as mentioned by Thomas. |> |>The comments from Thomas were: |>.... |> |> |>>But, that's incorrect. The present proposed algorithm in the |>>I-D does not require this, but works correctly. |>> |>> |>.... |> |> |>>I disagree. L2s differ, the choice of jitter should too. This is |>>documented in 5148. |>> |>> |>.... |>I am lost. First, text update is not needed (it works ALWAYS), then |jitter |>solves the problem (there is NO problem?). |> |> |>My suggestion is rewording in the OLSRv2 text: |> - There IS an assumption on the underlying link layer |> - Explain what the assumption is (separate section) |> - Make jitter a SHOULD, reference to the assumption |> - Make "per interface MPR selection" a SHOULD, reference |> to the assumption |> |>Now we have two remedies for the race condition. The update on text |would |>not slow down progress that much. Acceptable? |> |> |>Teco. |> |> |>_______________________________________________ |>manet mailing list |>manet@ietf.org |>https://www.ietf.org/mailman/listinfo/manet |> |> |> From ulrich@herberg.name Wed Apr 22 23:50: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 E32363A71A4 for ; Wed, 22 Apr 2009 23:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 66xp7anfUhfF for ; Wed, 22 Apr 2009 23:50:21 -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 35E2A3A6F29 for ; Wed, 22 Apr 2009 23:50:18 -0700 (PDT) Received: by fxm2 with SMTP id 2so367364fxm.37 for ; Wed, 22 Apr 2009 23:51:36 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.103.250.1 with SMTP id c1mr392020mus.64.1240469495349; Wed, 22 Apr 2009 23:51:35 -0700 (PDT) In-Reply-To: <000801c9c384$699399b0$3cbacd10$@nl> References: <00a201c9c360$f639f540$e2addfc0$@nl> <200904221753.25551.hrogge@googlemail.com> <25c114b90904220904u6b2db42fl66b3fa3366e5dae@mail.gmail.com> <000801c9c384$699399b0$3cbacd10$@nl> Date: Thu, 23 Apr 2009 08:51:35 +0200 X-Google-Sender-Auth: aeb17a8e49944ebe Message-ID: <25c114b90904222351nd04f333l2e2712734c044816@mail.gmail.com> From: Ulrich Herberg To: Teco Boot Content-Type: multipart/alternative; boundary=001636765bcaa001790468334ff7 Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] Compressed TC and Hello message headers 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, 23 Apr 2009 06:50:22 -0000 --001636765bcaa001790468334ff7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I had already written a long reply to that when I saw that Henning covered most of my arguments. :-) So I will not repreat them, just strongly agree with them. On Wed, Apr 22, 2009 at 9:56 PM, Teco Boot wrote: > [...] > > Comment on Ulrich his statement that IPv6 hellos are "long". There is no > reason for this, as packetBB can compress IPv6 to the same length as IPv4 > IDs. It is a matter of addressing scheme. Well, as you say, this depends very much on the addressing scheme. But even if you use IPv6 addresses that can be well compressed, still the fact stays that your proposal saves a (small) *constant* number of bytes. The savings are not growing with the number of addresses in the message. So your percentages from your previous email are not correct. > This area is my day to job (or struggle..) in real world ad hoc networks. I > may need IPv6 for good reasons. And I definitely need efficient transport of > data, also for good reasons. My split mind: unique addresses by nature > (random, EUI-64, etc.) are great for reducing network management efforts, > but at the same time the addresses are hard to compress. This is one of the > reasons I am working on RouterIDs, msgs will be compact as long as the > RouterIDs and delegated prefixes can be compressed. This is doable. > > Please think again on the proposal. I know it is a small gain. But still: > it is gain. There is no disadvantage. Not at all !! As Henning said, small gain, high disadvantage. Ulrich --001636765bcaa001790468334ff7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I had already written a long reply to that when I saw that Henni= ng covered most of my arguments. :-) So I will not repreat them, just stron= gly agree with them.

On Wed, Apr 22, 2009= at 9:56 PM, Teco Boot <teco@inf-net.nl> wrote:
[...]

Comment on Ulrich his statement that IPv6 hellos are "long". Ther= e is no reason for this, as packetBB can compress IPv6 to the same length a= s IPv4 IDs. It is a matter of addressing scheme.

Well, as you say, this depends very much on the addressing scheme. But even= if you use IPv6 addresses that can be well compressed, still the fact stay= s that your proposal saves a (small) *constant* number of bytes. The saving= s are not growing with the number of addresses in the message. So your perc= entages from your previous email are not correct.
=A0
This ar= ea is my day to job (or struggle..) in real world ad hoc networks. I may ne= ed IPv6 for good reasons. And I definitely need efficient transport of data= , also for good reasons. My split mind: unique addresses by nature (random,= EUI-64, etc.) are great for reducing network management efforts, but at th= e same time the addresses are hard to compress. This is one of the reasons = I am working on RouterIDs, msgs will be compact as long as the RouterIDs an= d delegated prefixes can be compressed. This is doable.

Please think again on the proposal. I know it is a small gain. But still: i= t is gain. There is no disadvantage. Not at all !!

As = Henning said, small gain, high disadvantage.

Ulrich

--001636765bcaa001790468334ff7-- From teco@inf-net.nl Thu Apr 23 00:06:40 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 76FCC3A68E0 for ; Thu, 23 Apr 2009 00:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.157 X-Spam-Level: X-Spam-Status: No, score=-1.157 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 qiY5f-nftD3U for ; Thu, 23 Apr 2009 00:06:39 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 3B23628C6A9 for ; Thu, 23 Apr 2009 00:06:04 -0700 (PDT) Received: (qmail 15692 invoked from network); 23 Apr 2009 09:07:19 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 23 Apr 2009 09:07:19 +0200 From: "Teco Boot" To: "'Henning Rogge'" , References: <00a201c9c360$f639f540$e2addfc0$@nl> <000801c9c384$699399b0$3cbacd10$@nl> <200904230756.54940.rogge@fgan.de> In-Reply-To: <200904230756.54940.rogge@fgan.de> Date: Thu, 23 Apr 2009 09:06:41 +0200 Message-ID: <003201c9c3e2$1f954030$5ebfc090$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnD2HRmkv6RseWqRjiG5Z739R3dvgABjACA Content-Language: nl Cc: 'Thomas Heide Clausen' Subject: Re: [manet] Compressed TC and Hello message headers 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, 23 Apr 2009 07:06:40 -0000 Hi Henning, I think you still misunderstand the proposal. Currently, there is no standard for OLSRv2 and thus there is no = compliant implementation. Backwards compatibility is no problem yet. It = will be soon. All compliant NHDP and OLSRv2 implementations MUST be able = to handle the suggested TC and H header. There is no "unknown" = condition. The TC-header and H-header are just TLVs. PacketBB readers do not have = to know the internal structure of a TLV value. Not now and not in my = proposal. "sub-parsing" the headers for packet header, message header = and the suggested TC and H headers is very similar. This is what I = mentioned already, the rules for adding new sub-fields would be "not = allowed". Nothing new here. Out of topic, but on RouterID: selecting a RouterID when using whatever = address configuration mechanism is not a problem. Just pick a unique = address. Prefer an address that can be compressed with address block = TLVs. Prefer a stable address. Some requirements are challenging, like = privacy (change all addresses on the flight, including RouterID). Regards, Teco |-----Oorspronkelijk bericht----- |Van: Henning Rogge [mailto:rogge@fgan.de] |Verzonden: donderdag 23 april 2009 7:57 |Aan: manet@ietf.org |CC: Teco Boot; 'Thomas Heide Clausen'; 'Ulrich Herberg' |Onderwerp: Re: [manet] Compressed TC and Hello message headers | |Am Wednesday 22 April 2009 21:56:22 schrieb Teco Boot: |> Hi Henning, Ulrich and Thomas, |> |> I fully agree: the proposal is a small gain. |> Dutch saying: "wie het kleine niet eert, is het grote niet weerd". |> This means: "who refuses what's small, doesn't deserve what's big". |> By the way, we had discussions on few octets before. And keep in mind |the |> TC header may appear in a packet many times. And TCs would be small = if |> topology reduction works fine. |> |> I strongly disagree with "huge loss in flexibility", because it is |> incorrect. But yes, it is time to carefully verify what function is |> mandatory and what is not. When the std is published, all additions |are |> optional. We can use spare flags (to be ignored on reception by nodes |that |> doesn't support the option) or a new TLVs. Why do you think my |suggestion |> blocks any of this ?? |> |> I do not understand Hennings parsing argument. Packet and message |header |> are parsed exactly as what I suggest for TC and Hello headers. So |parsing |> logic is already there. And the header fields must be supported, so |all |> implementations must parse it. Yes, I think we should not add = optional |> header fields and indicate this with flags. Same comment applies for |> RFC5444, so nothing new here. |A change of RFC5444 and a change of NHDP/OLSRv2 messages is something |completely different. PacketBB messages with additional fields can be |EASILY |read by old versions of OLSR, because the TLV headers contain the |necessary |information to skip unknown fields. Compress them into a bitfield plus = a |number of binary values and you can only do this if you have knowledge |about |he length of the fields represented by each bit. There is a reason why |packetbb lost a number of header fields and corresponding control bits |(they |will be represented as TLV fields). | |An example... | |you define your "compressed" TC header this way: | :=3D | | ? | ? | |This is already a problem for packetbb readers because they need |knowledge |about the internal structure of the TC header to display the values and |parse |the following address block. One of the great things of packetbb is = that |you |can parse a message WITHOUT knowing anything about the semantic of the |messages. | |But let's say we do it your way, and later we decide we need a new = field |in |the header called , which is two byte in length. | |The new header would look like | :=3D | | ? | ? | ? | |Because the old parser don't know about the additional used bit in the | field and don't know about the length (or even existence) of |the |new field, they cannot parse this message ! Some of the old |parsers |will even ignore the bit and mix up the field with the |beginning of |an address block ! | |> Comment on Ulrich his statement that IPv6 hellos are "long". There is |no |> reason for this, as packetBB can compress IPv6 to the same length as |IPv4 |> IDs. It is a matter of addressing scheme. This area is my day to job |(or |> struggle..) in real world ad hoc networks. I may need IPv6 for good |> reasons. And I definitely need efficient transport of data, also for |good |> reasons. My split mind: unique addresses by nature (random, EUI-64, |etc.) |> are great for reducing network management efforts, but at the same |time the |> addresses are hard to compress. This is one of the reasons I am |working on |> RouterIDs, msgs will be compact as long as the RouterIDs and = delegated |> prefixes can be compressed. This is doable. |Sometimes you want RouterIDs, sometimes you don't want them because you |run an |simple autoconfiguration protocol. But 3-5 bytes is still very small |compared |to the whole OLSR message. | |> Please think again on the proposal. I know it is a small gain. But |still: |> it is gain. There is no disadvantage. Not at all !! |Yes, there is... | |Henning | |************************************************* |Diplom Informatiker Henning Rogge |Forschungsgesellschaft f=C3=BCr |Angewandte Naturwissenschaften e. V. (FGAN) |Neuenahrer Str. 20, 53343 Wachtberg, Germany |Tel.: 0049 (0)228 9435-961 |Fax: 0049 (0)228 9435-685 |E-Mail: rogge@fgan.de |Web: www.fgan.de |************************************************ |Sitz der Gesellschaft: Bonn |Registergericht: Amtsgericht Bonn VR 2530 |Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. = Dr.-Ing. |Joachim Ender (Stellv.) From Rogge@fgan.de Thu Apr 23 00:19:51 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 8C2923A6F4D for ; Thu, 23 Apr 2009 00:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.169 X-Spam-Level: X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_DE=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 VKsgzaf3h8uT for ; Thu, 23 Apr 2009 00:19:50 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 624803A6800 for ; Thu, 23 Apr 2009 00:19:50 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1LwtF4-0007c6-2g; Thu, 23 Apr 2009 09:21:06 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1LwtF3-0001Xx-Mz; Thu, 23 Apr 2009 09:21:05 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Apr 2009 09:21:05 +0200 From: Henning Rogge To: "Teco Boot" Date: Thu, 23 Apr 2009 09:20:49 +0200 User-Agent: KMail/1.10.4 (Linux/2.6.26-1-openvz-686; KDE/4.1.4; i686; ; ) References: <00a201c9c360$f639f540$e2addfc0$@nl> <200904230756.54940.rogge@fgan.de> <003201c9c3e2$1f954030$5ebfc090$@nl> In-Reply-To: <003201c9c3e2$1f954030$5ebfc090$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2046620.KVpmxqor12"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904230921.05084.rogge@fgan.de> X-OriginalArrivalTime: 23 Apr 2009 07:21:05.0417 (UTC) FILETIME=[10896790:01C9C3E4] X-Virus-Scanned: yes (ClamAV 0.94.2/9277/Thu Apr 23 08:58:24 2009) by mailguard.fgan.de X-Scan-Signature: 902864caa043fb1a4eecc12540b64fa7 Cc: manet@ietf.org, 'Thomas Heide Clausen' Subject: Re: [manet] Compressed TC and Hello message headers 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, 23 Apr 2009 07:19:51 -0000 --nextPart2046620.KVpmxqor12 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Thursday 23 April 2009 09:06:41 schrieb Teco Boot: > Hi Henning, > > Currently, there is no standard for OLSRv2 and thus there is no compliant > implementation. Backwards compatibility is no problem yet. It will be soo= n. > All compliant NHDP and OLSRv2 implementations MUST be able to handle the > suggested TC and H header. There is no "unknown" condition. I'm talking about backward compatiblity AFTER we introduce the change. Bitfields which control a header length cannot be extended without breaking= =20 backward compatiblity. So your proposal is a "dead end" which cannot be=20 extended later, because extending the bitfield means earlier OLSR=20 implementations will not be able to read the new header at all, so they hav= e=20 to skip the whole message. > The TC-header and H-header are just TLVs. PacketBB readers do not have to > know the internal structure of a TLV value. Not now and not in my proposa= l. > "sub-parsing" the headers for packet header, message header and the > suggested TC and H headers is very similar. This is what I mentioned > already, the rules for adding new sub-fields would be "not allowed". > Nothing new here. A TLV with bitfields in the value to control it's content ? I still don't=20 think this is a good idea. We would also have to think about the Hello part of your proposal, because= =20 NHDP is used for more than OLSR, so it's a good idea to use a common namesp= ace=20 for common fields like a "validity/interval time". Henning ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=C3=BCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart2046620.KVpmxqor12 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAknwFtEACgkQRIfGfFXsz+Dd8wCgrwWnVyyPKzMikR0iTivMtj9T OGMAoK5xPwaJoFwp7hLs1V9MwWGIisja =ZMMZ -----END PGP SIGNATURE----- --nextPart2046620.KVpmxqor12-- From teco@inf-net.nl Thu Apr 23 00:44:34 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 6C98128C6AF for ; Thu, 23 Apr 2009 00:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.178 X-Spam-Level: X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 D43RFMZk4IOO for ; Thu, 23 Apr 2009 00:44:33 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 4278128C6AD for ; Thu, 23 Apr 2009 00:44:32 -0700 (PDT) Received: (qmail 17886 invoked from network); 23 Apr 2009 09:45:46 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 23 Apr 2009 09:45:46 +0200 From: "Teco Boot" To: "'Ulrich Herberg'" References: <00a201c9c360$f639f540$e2addfc0$@nl> <200904221753.25551.hrogge@googlemail.com> <25c114b90904220904u6b2db42fl66b3fa3366e5dae@mail.gmail.com> <000801c9c384$699399b0$3cbacd10$@nl> <25c114b90904222351nd04f333l2e2712734c044816@mail.gmail.com> In-Reply-To: <25c114b90904222351nd04f333l2e2712734c044816@mail.gmail.com> Date: Thu, 23 Apr 2009 09:45:07 +0200 Message-ID: <003701c9c3e7$7e39d1f0$7aad75d0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnD4APDdyB5mI8KSpCzSuaExJ9qLQAAi7RQ Content-Language: nl Cc: manet@ietf.org, 'Thomas Heide Clausen' Subject: Re: [manet] Compressed TC and Hello message headers 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, 23 Apr 2009 07:44:34 -0000 Hi Ulrich, Maybe you miss one point, TCs do repeat in packets. My percentage are correct and applies for the savings of the fields that = are in scope. Yes, it is a *small* gain. Still, *gain*. Please describe a disadvantage that makes sense. I am still waiting. Regards, Teco. =3D=3D=3D=3D Van: ulrich@herberg.name [mailto:ulrich@herberg.name] Namens Ulrich = Herberg Verzonden: donderdag 23 april 2009 8:52 Aan: Teco Boot CC: Thomas Heide Clausen; manet@ietf.org Onderwerp: Re: [manet] Compressed TC and Hello message headers Hi, I had already written a long reply to that when I saw that Henning = covered most of my arguments. :-) So I will not repreat them, just strongly = agree with them. On Wed, Apr 22, 2009 at 9:56 PM, Teco Boot wrote: [...] Comment on Ulrich his statement that IPv6 hellos are "long". There is no reason for this, as packetBB can compress IPv6 to the same length as = IPv4 IDs. It is a matter of addressing scheme. Well, as you say, this depends very much on the addressing scheme. But = even if you use IPv6 addresses that can be well compressed, still the fact = stays that your proposal saves a (small) *constant* number of bytes. The = savings are not growing with the number of addresses in the message. So your percentages from your previous email are not correct. =A0 This area is my day to job (or struggle..) in real world ad hoc = networks. I may need IPv6 for good reasons. And I definitely need efficient = transport of data, also for good reasons. My split mind: unique addresses by nature (random, EUI-64, etc.) are great for reducing network management = efforts, but at the same time the addresses are hard to compress. This is one of = the reasons I am working on RouterIDs, msgs will be compact as long as the RouterIDs and delegated prefixes can be compressed. This is doable. Please think again on the proposal. I know it is a small gain. But = still: it is gain. There is no disadvantage. Not at all !! As Henning said, small gain, high disadvantage. Ulrich=20 From teco@inf-net.nl Thu Apr 23 01:23:30 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 09B1E28C6CD for ; Thu, 23 Apr 2009 01:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 IutRwujAWbpe for ; Thu, 23 Apr 2009 01:23:29 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 8D0213A6A74 for ; Thu, 23 Apr 2009 01:23:28 -0700 (PDT) Received: (qmail 21003 invoked from network); 23 Apr 2009 10:24:34 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 23 Apr 2009 10:24:34 +0200 From: "Teco Boot" To: "'Henning Rogge'" References: <00a201c9c360$f639f540$e2addfc0$@nl> <200904230756.54940.rogge@fgan.de> <003201c9c3e2$1f954030$5ebfc090$@nl> <200904230921.05084.rogge@fgan.de> In-Reply-To: <200904230921.05084.rogge@fgan.de> Date: Thu, 23 Apr 2009 10:23:55 +0200 Message-ID: <003e01c9c3ec$e9a06170$bce12450$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnD5DZvP4z23SMuTBOSYfGXMlg/ogAA32/g Content-Language: nl Cc: manet@ietf.org, 'Thomas Heide Clausen' Subject: Re: [manet] Compressed TC and Hello message headers 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, 23 Apr 2009 08:23:30 -0000 Hi Henning, Inline. |-----Oorspronkelijk bericht----- |Van: Henning Rogge [mailto:rogge@fgan.de] |Verzonden: donderdag 23 april 2009 9:21 |Aan: Teco Boot |CC: manet@ietf.org; 'Thomas Heide Clausen'; 'Ulrich Herberg' |Onderwerp: Re: [manet] Compressed TC and Hello message headers | |Am Thursday 23 April 2009 09:06:41 schrieb Teco Boot: |> Hi Henning, |> |> Currently, there is no standard for OLSRv2 and thus there is no |compliant |> implementation. Backwards compatibility is no problem yet. It will be |soon. |> All compliant NHDP and OLSRv2 implementations MUST be able to handle |the |> suggested TC and H header. There is no "unknown" condition. |I'm talking about backward compatiblity AFTER we introduce the change. |Bitfields which control a header length cannot be extended without |breaking |backward compatiblity. So your proposal is a "dead end" which cannot be |extended later, because extending the bitfield means earlier OLSR |implementations will not be able to read the new header at all, so they |have |to skip the whole message. Yes, that is what I am saying also. But it is not by definition. One may define a TLV with variable value = length, with future expansion of sub-fields. For example, my Autoconf = BRDP proposal makes use of ICMP ND RA options, called Border Router = Information Option (BRIO). The BRIO has sub-options. Who knows one comes = up with sub-sub options. One may suggest this for the TC or H header = TLV. I did not !! |> The TC-header and H-header are just TLVs. PacketBB readers do not = have |to |> know the internal structure of a TLV value. Not now and not in my |proposal. |> "sub-parsing" the headers for packet header, message header and the |> suggested TC and H headers is very similar. This is what I mentioned |> already, the rules for adding new sub-fields would be "not allowed". |> Nothing new here. |A TLV with bitfields in the value to control it's content ? I still |don't |think this is a good idea. It reduces overhead. That is all what I am saying. |We would also have to think about the Hello part of your proposal, |because |NHDP is used for more than OLSR, so it's a good idea to use a common |namespace |for common fields like a "validity/interval time". Not sure what you mean.=20 For sure I agree we do not accept the proposal overnight. I hope you do = not suggest OLSR (or others) maintain neighborhood state by itself, = without NHDP? And even if one build such, what is the problem? I do not = change functionality, it is just syntax. Regards, Teco. |Henning | |************************************************* |Diplom Informatiker Henning Rogge |Forschungsgesellschaft f=C3=BCr |Angewandte Naturwissenschaften e. V. (FGAN) |Neuenahrer Str. 20, 53343 Wachtberg, Germany |Tel.: 0049 (0)228 9435-961 |Fax: 0049 (0)228 9435-685 |E-Mail: rogge@fgan.de |Web: www.fgan.de |************************************************ |Sitz der Gesellschaft: Bonn |Registergericht: Amtsgericht Bonn VR 2530 |Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. = Dr.-Ing. |Joachim Ender (Stellv.) From Chris.Dearlove@baesystems.com Thu Apr 23 01:48:55 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 703CD3A691B for ; Thu, 23 Apr 2009 01:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN6e+JNGBTE9 for ; Thu, 23 Apr 2009 01:48:54 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by core3.amsl.com (Postfix) with ESMTP id 724CE3A67B0 for ; Thu, 23 Apr 2009 01:48:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,235,1238972400"; d="scan'208";a="1337800" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 23 Apr 2009 09:50:11 +0100 Received: from glkms1100.GREENLNK.NET (glkms1100.greenlnk.net [10.15.184.108]) by baemasmds009.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n3N8oA7L004804; Thu, 23 Apr 2009 09:50:11 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 23 Apr 2009 09:50:10 +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: Thu, 23 Apr 2009 09:50:06 +0100 Message-ID: In-Reply-To: <003701c9c3e7$7e39d1f0$7aad75d0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Compressed TC and Hello message headers Thread-Index: AcnD4APDdyB5mI8KSpCzSuaExJ9qLQAAi7RQAAOAd4A= References: <00a201c9c360$f639f540$e2addfc0$@nl> <200904221753.25551.hrogge@googlemail.com> <25c114b90904220904u6b2db42fl66b3fa3366e5dae@mail.gmail.com> <000801c9c384$699399b0$3cbacd10$@nl><25c114b90904222351nd04f333l2e2712734c044816@mail.gmail.com> <003701c9c3e7$7e39d1f0$7aad75d0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ulrich Herberg" X-OriginalArrivalTime: 23 Apr 2009 08:50:10.0603 (UTC) FILETIME=[82840FB0:01C9C3F0] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] Compressed TC and Hello message headers 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, 23 Apr 2009 08:48:55 -0000 > Please describe a disadvantage that makes sense. That's already been done. But here's another - multi-value interval and validity times as defined in RFC 5497. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Thu Apr 23 01:54:24 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 AD2033A6C90 for ; Thu, 23 Apr 2009 01:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSBF9hY41RHr for ; Thu, 23 Apr 2009 01:54:23 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by core3.amsl.com (Postfix) with ESMTP id C64683A6A27 for ; Thu, 23 Apr 2009 01:54:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,235,1238972400"; d="scan'208";a="1340616" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 23 Apr 2009 09:55:40 +0100 Received: from glkms1100.GREENLNK.NET (glkms1100.greenlnk.net [10.15.184.108]) by baemasmds009.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n3N8tdiP009922; Thu, 23 Apr 2009 09:55:40 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 23 Apr 2009 09:55:39 +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: Thu, 23 Apr 2009 09:55:37 +0100 Message-ID: In-Reply-To: <002e01c9c3de$4bc41ef0$e34c5cd0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 and forwarding based on MPR Thread-Index: AcnDxlVfvx4bCryoSdGmBUFcrUTG0QAFmOnwAAUNDKA= References: <000801c9b6fb$9f003fd0$dd00bf70$@nl> <49E55F69.5090607@earthlink.net> <002001c9bd9d$94c392d0$be4ab870$@nl> <49E61D1D.9060901@earthlink.net><49E71FA0.5010902@inria.fr> <001401c9bf30$73d0a9c0$5b71fd40$@nl><49EFE568.20408@earthlink.net> <002e01c9c3de$4bc41ef0$e34c5cd0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Richard Ogier" X-OriginalArrivalTime: 23 Apr 2009 08:55:39.0728 (UTC) FILETIME=[46B08D00:01C9C3F1] Cc: manet Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 23 Apr 2009 08:54:24 -0000 I suggest you read the mathematical literature on the subject. Thomas was not referring to jitter in his answer, but to that per interface selection solves the problem that otherwise multiple interfaces break the timing assumption that is included in those proofs. -- 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 07:39 To: 'Richard Ogier' Cc: 'manet' Subject: Re: [manet] OLSRv2 and forwarding based on MPR *** 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. Hi Richard, all, Thanks for the clarifications. I still do not agree on >> Currently, there are NO assumptions on the underlying link layer I came up with a scenario where MPR selection per interface and no jitter does not work. I waited over a week for comments (what do I overlook ??). No one did response with a clear answer (Thomas Clausen "believed" is was solved, maybe he thought of jitter). If time permits, I'll build a demonstrator. I would not say MPR is broken, but there are corner cases where it fails. I am fine with better specification where to use jitter (the MUST) and where it is not needed (e.g. no hidden terminal problems, no multi-hop underlying link layer, no out of order message reception) Teco. |-----Oorspronkelijk bericht----- |Van: Richard Ogier [mailto:ogier@earthlink.net] |Verzonden: donderdag 23 april 2009 5:50 |Aan: Teco Boot |CC: 'manet' |Onderwerp: Re: [manet] OLSRv2 and forwarding based on MPR | |This is a reply to Teco's message, but first I will respond |to the following to clarify the goal and terminology. | |Christopher Dearlove wrote: | |> It is. You select MPRs per interface, but then you use a single |> MPR set that combines them all into a single set for use. | | |I have no problem with selecting a set of MPRs for each interface. |The objection that some of us have is requiring the set of MPRs for |each interface to cover all 2-hop neighbors for that interface, even |if some of those 2-hop neighbors can be covered by MPRs for another |interface. I refer to this requirement by saying that the draft |requires a "complete" set of MPRs per interface. |When I say "per-node MPRs", I just mean the MPR set for each |interface need not be complete, as long as the union of the |MPR sets covers all 2-hop neighbors. | |One reason given for requiring a complete set of MPRs per interface |is the race condition, but it has been noted that the race condition |can be fixed by using jitter. |Another reason given by Philippe is the possibility of flooding |over the slowest interfaces. However, that can be avoided by |giving priority to the fastest interfaces when selecting MPRs. | |Currently, there are NO assumptions on the underlying link layer. |As noted, there must at least be some limit on the propagation |delay, e.g., it must be less than the flooding jitter. |But if flooding jitter is used, this also fixes the race |condition for multiple interfaces, so it is not necessary to |select a complete set of MPRs per interface. | |I mostly agree with Teco's suggested changes (see his message below), |but here is a modified list of suggested changes based on the above |considerations: | | - Flooding jitter SHOULD be used. | - Flooding jitter MUST be used if any link has the property | that a packet transmitted simultaneously by two routers B and C | can be received in different orders by two common neighbors | D and E. | - If flooding jitter is NOT used, the router MUST select a | complete set of MPRs per interface. | - If flooding jitter is used, then the MPR set for each | interface need not be complete, as long as all 2-hop | neighbors are covered by the union of the MPR sets. | |I also mentioned a solution that avoids the race condition |without jitter and without selecting a complete set of MPRs |per interface (by defining an ordering on MANET segments, |and using an MPR-CDS), but the above suggestions are similar |to Teco's suggestions and do not require much change to |the draft. | |Richard | | |Teco Boot wrote: | |>Philippe, Thomas, all, |> |>Philippe wrote: |>|In the case presented by Teco, I thought that the "switch" interface |was |>|providing very heterogeneous performances. But it is not the case, and |>|the jitter should solve the race problem as mentioned by Thomas. |> |>The comments from Thomas were: |>.... |> |> |>>But, that's incorrect. The present proposed algorithm in the |>>I-D does not require this, but works correctly. |>> |>> |>.... |> |> |>>I disagree. L2s differ, the choice of jitter should too. This is |>>documented in 5148. |>> |>> |>.... |>I am lost. First, text update is not needed (it works ALWAYS), then |jitter |>solves the problem (there is NO problem?). |> |> |>My suggestion is rewording in the OLSRv2 text: |> - There IS an assumption on the underlying link layer |> - Explain what the assumption is (separate section) |> - Make jitter a SHOULD, reference to the assumption |> - Make "per interface MPR selection" a SHOULD, reference |> to the assumption |> |>Now we have two remedies for the race condition. The update on text |would |>not slow down progress that much. Acceptable? |> |> |>Teco. |> |> |>_______________________________________________ |>manet mailing list |>manet@ietf.org |>https://www.ietf.org/mailman/listinfo/manet |> |> |> _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Thu Apr 23 01:57:32 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 D69FA3A71DD for ; Thu, 23 Apr 2009 01:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 bTTsNDe7LIAc for ; Thu, 23 Apr 2009 01:57:32 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by core3.amsl.com (Postfix) with ESMTP id E0FDB3A6C28 for ; Thu, 23 Apr 2009 01:57:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,235,1238972400"; d="scan'208";a="1341660" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 23 Apr 2009 09:58:49 +0100 Received: from glkms1101.GREENLNK.NET (glkms1101.greenlnk.net [10.15.184.109]) by baemasmds009.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n3N8wm4w013080; Thu, 23 Apr 2009 09:58:49 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 23 Apr 2009 09:58:48 +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: Thu, 23 Apr 2009 09:58:47 +0100 Message-ID: In-Reply-To: <003e01c9c3ec$e9a06170$bce12450$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Compressed TC and Hello message headers Thread-Index: AcnD5DZvP4z23SMuTBOSYfGXMlg/ogAA32/gAAJrEIA= References: <00a201c9c360$f639f540$e2addfc0$@nl><200904230756.54940.rogge@fgan.de><003201c9c3e2$1f954030$5ebfc090$@nl><200904230921.05084.rogge@fgan.de> <003e01c9c3ec$e9a06170$bce12450$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Henning Rogge" X-OriginalArrivalTime: 23 Apr 2009 08:58:48.0876 (UTC) FILETIME=[B76E3EC0:01C9C3F1] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] Compressed TC and Hello message headers 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, 23 Apr 2009 08:57:32 -0000 > One may define a TLV with variable value length, > with future expansion of sub-fields. But then an "old" implementation that doesn't know about the future expansion can't handle a "new" message. While with the TLVs as defined, a new TLV can be added and the "old" implementation can parse it and ignore it. This is precisely the flexibility that we built in to these specifications. ******************************************************************** 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 Thu Apr 23 03:01:53 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 2D9173A6F4D for ; Thu, 23 Apr 2009 03:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.212 X-Spam-Level: X-Spam-Status: No, score=-1.212 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 evizwmeSYsJE for ; Thu, 23 Apr 2009 03:01:52 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 780863A720C for ; Thu, 23 Apr 2009 03:01:34 -0700 (PDT) Received: (qmail 9740 invoked from network); 23 Apr 2009 12:02:49 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 23 Apr 2009 12:02:49 +0200 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Ulrich Herberg'" References: <00a201c9c360$f639f540$e2addfc0$@nl> <200904221753.25551.hrogge@googlemail.com> <25c114b90904220904u6b2db42fl66b3fa3366e5dae@mail.gmail.com> <000801c9c384$699399b0$3cbacd10$@nl><25c114b90904222351nd04f333l2e2712734c044816@mail.gmail.com> <003701c9c3e7$7e39d1f0$7aad75d0$@nl> In-Reply-To: Date: Thu, 23 Apr 2009 12:02:10 +0200 Message-ID: <004b01c9c3fa$a3ad1740$eb0745c0$@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: AcnD4APDdyB5mI8KSpCzSuaExJ9qLQAAi7RQAAOAd4AAAkxhMA== Content-Language: nl Cc: manet@ietf.org, 'Thomas Heide Clausen' Subject: Re: [manet] Compressed TC and Hello message headers 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, 23 Apr 2009 10:01:53 -0000 Thanks. My suggestion does not support multi-value time values. This is a disadvantage. For hellos, it doesn't make sense to use multi-value times. For TCs, it does. In general, the concept using TLVs with value-blocks can be discussed. If there are reasons using separate TLVs for each value element, that is OK. If there are no reasons, I prefer efficiency. Teco. From Chris.Dearlove@baesystems.com Thu Apr 23 03:07:55 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 F374C3A6AC5 for ; Thu, 23 Apr 2009 03:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjpNeiShpVc7 for ; Thu, 23 Apr 2009 03:07:54 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by core3.amsl.com (Postfix) with ESMTP id DA7633A69B1 for ; Thu, 23 Apr 2009 03:07:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,235,1238972400"; d="scan'208";a="1372240" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 23 Apr 2009 11:09:11 +0100 Received: from glkms1100.GREENLNK.NET (glkms1100.greenlnk.net [10.15.184.108]) by baemasmds009.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n3NA9AIr016584; Thu, 23 Apr 2009 11:09:11 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 23 Apr 2009 11:09:10 +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: Thu, 23 Apr 2009 11:09:10 +0100 Message-ID: In-Reply-To: <004b01c9c3fa$a3ad1740$eb0745c0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Compressed TC and Hello message headers Thread-Index: AcnD4APDdyB5mI8KSpCzSuaExJ9qLQAAi7RQAAOAd4AAAkxhMAAAXTMQ References: <00a201c9c360$f639f540$e2addfc0$@nl> <200904221753.25551.hrogge@googlemail.com> <25c114b90904220904u6b2db42fl66b3fa3366e5dae@mail.gmail.com> <000801c9c384$699399b0$3cbacd10$@nl><25c114b90904222351nd04f333l2e2712734c044816@mail.gmail.com><003701c9c3e7$7e39d1f0$7aad75d0$@nl> <004b01c9c3fa$a3ad1740$eb0745c0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ulrich Herberg" X-OriginalArrivalTime: 23 Apr 2009 10:09:10.0728 (UTC) FILETIME=[8BD9BC80:01C9C3FB] Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] Compressed TC and Hello message headers 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, 23 Apr 2009 10:07:55 -0000 The over-riding reason for using TLVs, for motivating the entire 5444 structure is flexibility againat the unknown, creation of extensions and backward compatibility in the way in which old implementations can know about new ones. 5444 is already a tradeoff of these various factors against each other (as it discusses). We've been down the fixed format route before, it's called OLSRv1. And OLSRv1 showed itself as having problems in this area. -- 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:02 To: Dearlove, Christopher (UK); 'Ulrich Herberg' Cc: manet@ietf.org; 'Thomas Heide Clausen' Subject: Re: [manet] Compressed TC and Hello message headers *** 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. Thanks. My suggestion does not support multi-value time values. This is a disadvantage. For hellos, it doesn't make sense to use multi-value times. For TCs, it does. In general, the concept using TLVs with value-blocks can be discussed. If there are reasons using separate TLVs for each value element, that is OK. If there are no reasons, I prefer efficiency. 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. ******************************************************************** From teco@inf-net.nl Thu Apr 23 03:09:00 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 7E73728C6BF for ; Thu, 23 Apr 2009 03:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.482 X-Spam-Level: X-Spam-Status: No, score=-0.482 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_05=-1.11, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 fw9DWYd9zy-Y for ; Thu, 23 Apr 2009 03:08:59 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 5405D28C6B8 for ; Thu, 23 Apr 2009 03:08:59 -0700 (PDT) Received: (qmail 17024 invoked from network); 23 Apr 2009 12:10:14 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 23 Apr 2009 12:10:14 +0200 From: "Teco Boot" To: Date: Thu, 23 Apr 2009 12:09:35 +0200 Message-ID: <004c01c9c3fb$ac973c90$05c5b5b0$@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: AcnD+5perUM3/c8TS+uPAFN2s080Fw== Content-Language: nl Subject: [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, 23 Apr 2009 10:09:00 -0000 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. From Chris.Dearlove@baesystems.com Thu Apr 23 03:17:40 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 0AF653A721D for ; Thu, 23 Apr 2009 03:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 46KPW8v0zgV8 for ; Thu, 23 Apr 2009 03:17:39 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by core3.amsl.com (Postfix) with ESMTP id DB9BC3A7202 for ; Thu, 23 Apr 2009 03:17:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,235,1238972400"; d="scan'208";a="1377540" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 23 Apr 2009 11:18:56 +0100 Received: from glkms1100.GREENLNK.NET (glkms1100.greenlnk.net [10.15.184.108]) by baemasmds009.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n3NAIrRX026002; Thu, 23 Apr 2009 11:18:56 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 23 Apr 2009 11:18:55 +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: Thu, 23 Apr 2009 11:18:56 +0100 Message-ID: In-Reply-To: <004c01c9c3fb$ac973c90$05c5b5b0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] OLSRv2 - suggestions for enhancing message forwarding Thread-Index: AcnD+5perUM3/c8TS+uPAFN2s080FwAAE5tQ References: <004c01c9c3fb$ac973c90$05c5b5b0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , X-OriginalArrivalTime: 23 Apr 2009 10:18:55.0541 (UTC) FILETIME=[E86D1E50:01C9C3FC] 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, 23 Apr 2009 10:17:40 -0000 The missed 1-hop TC has an inherent contradiction, that combination of characteristics should not occur. Taking special action to relay such a message is not appropriate. 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. ******************************************************************** From mlittleflower@yahoo.co.in Thu Apr 23 21:22: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 410933A67A8 for ; Thu, 23 Apr 2009 21:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.764 X-Spam-Level: * X-Spam-Status: No, score=1.764 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762] 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 EmS9RQc4NB7V for ; Thu, 23 Apr 2009 21:22:11 -0700 (PDT) Received: from web7603.mail.in.yahoo.com (web7603.mail.in.yahoo.com [202.86.4.22]) by core3.amsl.com (Postfix) with SMTP id 8EF5B3A6B00 for ; Thu, 23 Apr 2009 21:21:24 -0700 (PDT) Received: (qmail 64395 invoked by uid 60001); 24 Apr 2009 04:22:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1240546961; bh=RjrxIoJeha8IOgunEXAFmKUskKXrI+bpU8fhErcmdxs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:To:MIME-Version:Content-Type; b=vBSVKh9HkDLl5fQlAP9I92T3k5gF8V6SGmgDQqrlmzgsP0DsvT29aZEmeUIlN0ltREj8dZ+3xKbUhArpSXxOekYAtV1zkrT76Jlc3d0FIuokfqqNarBGEi2o/di7I9hsvyis06r7HKxeiUqb1qNpCSGPEdc2/NWI/IDXNb97xH0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:To:MIME-Version:Content-Type; b=H9HZhf6W3B3GW41Pr5cdB0GXDlQw8uq4Zr/qrQRdhM4xuYuc7Mo2E+WUxaluffMsyd6+alPikgKmcFtEW+iNVv66wHb/hyF/DQqfE02U7G6XtpMYurwUjVOffdv2AdK0aJIWxxOU5z63ICTAS9z8pEDW3tuqZ3/ZIjPEZyYp63Q=; Message-ID: <390951.63640.qm@web7603.mail.in.yahoo.com> X-YMail-OSG: lv6hDkwVM1mBfTa0eHU26xXIkJSephSag0Nn8uwXejZskQMeVQCSHkrrmsPqFng65we4eZEvrHqsNYsvboNRKiKoTAkCbewzI56rWOqb35kaAp9gMIG6KJGoTo45oTC7nqpJ7_wkayQTxZTTduCbSJEPyanniH.GPPekW4vhUhugqLZf5tYZihwv7jL14LfAQAW8JmXAB64wx87zEoA2oI7tya_ExM86VigPyqNXcr6Ro3ROC5RceayJeytTiA-- Received: from [220.225.140.98] by web7603.mail.in.yahoo.com via HTTP; Fri, 24 Apr 2009 09:52:41 IST X-Mailer: YahooMailClassic/5.2.19 YahooMailWebService/0.7.289.10 Date: Fri, 24 Apr 2009 09:52:41 +0530 (IST) From: mlittle flower To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1352165246-1240546961=:63640" Subject: [manet] (no subject) 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, 24 Apr 2009 04:22:12 -0000 --0-1352165246-1240546961=:63640 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0A=0A Now surf faster and smarter ! Check out the new Firefox 3 - = Yahoo! Edition http://downloads.yahoo.com/in/firefox/ --0-1352165246-1240546961=:63640 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

=0A=0A=0A =
Bollywood news, movie reviews, film trailers and more! <= a href=3D"http://in.rd.yahoo.com/tagline_movies_1/*http://in.movies.yahoo.c= om/?wm=3Dn/"> Click here. --0-1352165246-1240546961=:63640-- From ogier@earthlink.net Sun Apr 26 22:25: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 7104A3A6E7C for ; Sun, 26 Apr 2009 22:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_50=0.001] 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 9p5oFVi+JnrM for ; Sun, 26 Apr 2009 22:25:06 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 8D7923A6EC1 for ; Sun, 26 Apr 2009 22:25:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=OWUTCMdZbSuuJaNc0qFxQ/ODxP1v+yiyN0dkWzMphFMbUfQxBG+m1ztqmrB5/3Gl; 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.223.42] by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LyJMF-0005gQ-MW; Mon, 27 Apr 2009 01:26:25 -0400 Message-ID: <49F542B7.4000503@earthlink.net> Date: Sun, 26 Apr 2009 22:29:27 -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: <000801c9b6fb$9f003fd0$dd00bf70$@nl> <49E55F69.5090607@earthlink.net> <002001c9bd9d$94c392d0$be4ab870$@nl> <49E61D1D.9060901@earthlink.net> <49E71FA0.5010902@inria.fr> <001401c9bf30$73d0a9c0$5b71fd40$@nl> <49EFE568.20408@earthlink.net> <002e01c9c3de$4bc41ef0$e34c5cd0$@nl> In-Reply-To: <002e01c9c3de$4bc41ef0$e34c5cd0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478eae09f65131c9d1fb9a23b3674146be0b9a5a6db07081916350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.223.42 Cc: 'manet' Subject: Re: [manet] OLSRv2 and forwarding based on MPR 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, 27 Apr 2009 05:25:10 -0000 Teco Boot wrote: >Hi Richard, all, > >Thanks for the clarifications. > >I still do not agree on > > >>>Currently, there are NO assumptions on the underlying link layer >>> >>> I was just referring to the statement "OLSRv2 makes no assumptions about the underlying link layer" on page 5 of the draft. You and I are in agreement that some assumptions on the underlying link layer ARE NEEDED. It is ludicrous how the authors are avoiding admitting this! In my last post on 4/22, I tried hard to clarify where jitter is needed, for both the single-interface and multiple-interface cases. Christopher's short response on 4/23 (to both of us) does not address the valid points we are making. We all understand how selecting a complete set of MPRs per interface solves the race condition problem when there is no jitter. But as you point out, jitter is needed anyway even for the single-interface case. Similarly, jitter can solve the problem with multiple interfaces. (If the authors disagree with this, then they should say so and we can discuss it.) Therefore, WHY SHOULD WE REQUIRE A COMPLETE SET OF MPRS PER INTERFACE IF THIS CAN BE AVOIDED USING JITTER? By removing this requirement, we allow a more flexible and more efficient selection of MPRs. > >I came up with a scenario where MPR selection per interface and no jitter >does not work. I waited over a week for comments (what do I overlook ??). No >one did response with a clear answer (Thomas Clausen "believed" is was >solved, maybe he thought of jitter). If time permits, I'll build a >demonstrator. I would not say MPR is broken, but there are corner cases >where it fails. > > Yes, your scenario (with a single interface and multihop link layer) clearly shows that MPR selection per interface and no jitter can fail even for a single interface. (Christopher did not address this in his recent message.) I'm not sure what Thomas meant, but Philippe stated the following on 4/16: "In the case presented by Teco, I thought that the "switch" interface was providing very heterogeneous performances. But it is not the case, and the jitter should solve the race problem as mentioned by Thomas." >I am fine with better specification where to use jitter (the MUST) and where >it is not needed (e.g. no hidden terminal problems, no multi-hop underlying >link layer, no out of order message reception) > > I agree. At a minimum, the authors need to specify assumptions for the link layer. It would be great if they also specified jitter conditions under which the complete-MPR-set-per-interface requirement can be relaxed, but I doubt that will happen. If we focus on the link layer assumptions, I think we will convince either the authors or the WG. The key is to not give up and not let them get away with vague arguments. The truth shall prevail! Richard >Teco. > >|-----Oorspronkelijk bericht----- >|Van: Richard Ogier [mailto:ogier@earthlink.net] >|Verzonden: donderdag 23 april 2009 5:50 >|Aan: Teco Boot >|CC: 'manet' >|Onderwerp: Re: [manet] OLSRv2 and forwarding based on MPR >| >|This is a reply to Teco's message, but first I will respond >|to the following to clarify the goal and terminology. >| >|Christopher Dearlove wrote: >| >|> It is. You select MPRs per interface, but then you use a single >|> MPR set that combines them all into a single set for use. >| >| >|I have no problem with selecting a set of MPRs for each interface. >|The objection that some of us have is requiring the set of MPRs for >|each interface to cover all 2-hop neighbors for that interface, even >|if some of those 2-hop neighbors can be covered by MPRs for another >|interface. I refer to this requirement by saying that the draft >|requires a "complete" set of MPRs per interface. >|When I say "per-node MPRs", I just mean the MPR set for each >|interface need not be complete, as long as the union of the >|MPR sets covers all 2-hop neighbors. >| >|One reason given for requiring a complete set of MPRs per interface >|is the race condition, but it has been noted that the race condition >|can be fixed by using jitter. >|Another reason given by Philippe is the possibility of flooding >|over the slowest interfaces. However, that can be avoided by >|giving priority to the fastest interfaces when selecting MPRs. >| >|Currently, there are NO assumptions on the underlying link layer. >|As noted, there must at least be some limit on the propagation >|delay, e.g., it must be less than the flooding jitter. >|But if flooding jitter is used, this also fixes the race >|condition for multiple interfaces, so it is not necessary to >|select a complete set of MPRs per interface. >| >|I mostly agree with Teco's suggested changes (see his message below), >|but here is a modified list of suggested changes based on the above >|considerations: >| >| - Flooding jitter SHOULD be used. >| - Flooding jitter MUST be used if any link has the property >| that a packet transmitted simultaneously by two routers B and C >| can be received in different orders by two common neighbors >| D and E. >| - If flooding jitter is NOT used, the router MUST select a >| complete set of MPRs per interface. >| - If flooding jitter is used, then the MPR set for each >| interface need not be complete, as long as all 2-hop >| neighbors are covered by the union of the MPR sets. >| >|I also mentioned a solution that avoids the race condition >|without jitter and without selecting a complete set of MPRs >|per interface (by defining an ordering on MANET segments, >|and using an MPR-CDS), but the above suggestions are similar >|to Teco's suggestions and do not require much change to >|the draft. >| >|Richard >| >| >|Teco Boot wrote: >| >|>Philippe, Thomas, all, >|> >|>Philippe wrote: >|>|In the case presented by Teco, I thought that the "switch" interface >|was >|>|providing very heterogeneous performances. But it is not the case, and >|>|the jitter should solve the race problem as mentioned by Thomas. >|> >|>The comments from Thomas were: >|>.... >|> >|> >|>>But, that's incorrect. The present proposed algorithm in the >|>>I-D does not require this, but works correctly. >|>> >|>> >|>.... >|> >|> >|>>I disagree. L2s differ, the choice of jitter should too. This is >|>>documented in 5148. >|>> >|>> >|>.... >|>I am lost. First, text update is not needed (it works ALWAYS), then >|jitter >|>solves the problem (there is NO problem?). >|> >|> >|>My suggestion is rewording in the OLSRv2 text: >|> - There IS an assumption on the underlying link layer >|> - Explain what the assumption is (separate section) >|> - Make jitter a SHOULD, reference to the assumption >|> - Make "per interface MPR selection" a SHOULD, reference >|> to the assumption >|> >|>Now we have two remedies for the race condition. The update on text >|would >|>not slow down progress that much. Acceptable? >|> >|> >|>Teco. >|> >|> >|>_______________________________________________ >|>manet mailing list >|>manet@ietf.org >|>https://www.ietf.org/mailman/listinfo/manet >|> >|> >|> > > > > From adarsh.kumar@jiit.ac.in Mon Apr 27 20:03:13 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 39B7F3A6AE2 for ; Mon, 27 Apr 2009 20:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=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 3V4Ux6HfbcXl for ; Mon, 27 Apr 2009 20:03:12 -0700 (PDT) Received: from domino.jiit.ac.in (domino.jiit.ac.in [210.212.127.13]) by core3.amsl.com (Postfix) with ESMTP id 2098C3A6867 for ; Mon, 27 Apr 2009 20:03:10 -0700 (PDT) To: manet@ietf.org X-Mailer: Lotus Notes Release 5.0.6 December 14, 2000 Message-ID: From: adarsh.kumar@jiit.ac.in Date: Tue, 28 Apr 2009 08:59:09 +0530 X-MIMETrack: Serialize by Router on domino/jiit(Release 5.0.9a |January 7, 2002) at 04/28/2009 08:59:14 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Cyberoam-Version: 9.5.8.52 X-Cyberoam-smtpxy-version: 1.0.5.3 X-Cyberoam-AV-Status: Clean X-Cyberoam-Proto: SMTP X-Cyberoam-AV-Policy: None X-CTCH-PVer: 0000001 X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-Flags: 0 X-CTCH-RefID: str=0001.0A150203.49F67241.0135,ss=1,fgs=0 X-Cyberoam-AS-Policy: Default Spam Policy Subject: [manet] problem with 802_16 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, 28 Apr 2009 03:03:13 -0000 while executing Mac/802_16 i am facing following problem. kindly sugges= t some solution - [root@nl-29 ns-2.31]# ns /home/test/Desktop/WiMAX_module/tcl/ex/5.tcl= e.tcl invalid command name "Mac/802_16" =A0=A0=A0 while executingagent! "Mac/802_16 set modulation_ 0"/test/Desktop/WiMAX_module/tcl/ex/example= .tcl =A0=A0=A0 (file "/home/test/Desktop/WiMAX_module/tcl/ex/5.tcl" line 29)= [root@nl-29 ns-2.31]# adarsh kumar= From robert.cole@jhuapl.edu Tue Apr 28 09:06: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 86B8F3A6D94 for ; Tue, 28 Apr 2009 09:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.432, 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 If5lgFINiIfL for ; Tue, 28 Apr 2009 09:06:43 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id 3435D3A6BEA for ; Tue, 28 Apr 2009 09:06:13 -0700 (PDT) Received: from ([128.244.198.91]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.1876618; Tue, 28 Apr 2009 12:07:30 -0400 Received: from aplesstar.dom1.jhuapl.edu ([128.244.198.212]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Tue, 28 Apr 2009 12:07:30 -0400 From: "Cole, Robert G." To: "manet@ietf.org" Date: Tue, 28 Apr 2009 12:07:30 -0400 Thread-Topic: New Version Notification for draft-cole-manet-report-mib-00 Thread-Index: AcnIGigNLTldXcOIQ2iAMkRaPaQ3dQAABv3U Message-ID: <0A8F66C42F49E448A40E99946404EE5B7063B3287F@aplesstar.dom1.jhuapl.edu> References: <20090428155655.EE99D3A693F@core3.amsl.com> In-Reply-To: <20090428155655.EE99D3A693F@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "macker@itd.nrl.navy.mil" , "amorton@att.com" Subject: Re: [manet] New Version Notification for draft-cole-manet-report-mib-00 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, 28 Apr 2009 16:06:44 -0000 To all: We had discussed this MIB at the last meeting in San Francisco. This essen= tially acts as a front-end which generates local performance reports based = upon specified performance counters from other co-located MIBs. In a sense= , this provides an 'RMON-lite' offline reporting capability which may be us= eful for devices which are somewhat autonomous in operation or connected to= a network which has bandwidth constraints where polling for performance st= atistics is neither desirable or practical. This eliminates the need to add these capabilities to other MANET MIBs, e.g= ., SMF-MIB, DYMO-MIB, etc. Hence, I'll be pulling the ReportsGroup from th= e SMF-MIB and not adding the ReportsGroup to the other MIBs. Thanks, Bob ________________________________________ From: IETF I-D Submission Tool [idsubmission@ietf.org] Sent: Tuesday, April 28, 2009 11:56 AM To: Cole, Robert G. Cc: macker@itd.nrl.navy.mil; amorton@att.com Subject: New Version Notification for draft-cole-manet-report-mib-00 A new version of I-D, draft-cole-manet-report-mib-00.txt has been successfu= ly submitted by Robert Cole and posted to the IETF repository. Filename: draft-cole-manet-report-mib Revision: 00 Title: Definition of Managed Objects for Reporting Performance Co= unters' Statistics Creation_date: 2009-04-28 WG ID: Independent Submission Number_of_pages: 42 Abstract: 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 autonomous report generation on any device that supports MIBs containing counter objects for performance monitoring. This allows a management station to instruct a device to build off-line reports to be collected asynchronously by the management station. The IETF Secretariat. From teco@inf-net.nl Wed Apr 29 00:09:51 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 18F183A682B for ; Wed, 29 Apr 2009 00:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.353, 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 iz7sGwNpg07o for ; Wed, 29 Apr 2009 00:09:50 -0700 (PDT) Received: from CPSMTPM-EML104.kpnxchange.com (cpsmtpm-eml104.kpnxchange.com [195.121.3.8]) by core3.amsl.com (Postfix) with ESMTP id 7CDCD3A6CD9 for ; Wed, 29 Apr 2009 00:09:48 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 29 Apr 2009 09:11:06 +0200 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , References: <004c01c9c3fb$ac973c90$05c5b5b0$@nl> In-Reply-To: Date: Wed, 29 Apr 2009 09:10:58 +0200 Message-ID: <000b01c9c899$a52e0d60$ef8a2820$@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: AcnD+5perUM3/c8TS+uPAFN2s080FwAAE5tQASYDePA= Content-Language: nl X-OriginalArrivalTime: 29 Apr 2009 07:11:06.0377 (UTC) FILETIME=[A9F5A790:01C9C899] 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, 29 Apr 2009 07:09:51 -0000 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. 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. |******************************************************************** From ogier@earthlink.net Wed Apr 29 22:11:46 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 036EB3A6941 for ; Wed, 29 Apr 2009 22:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.781 X-Spam-Level: X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[AWL=0.818, 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 A4u7cjUFMu3P for ; Wed, 29 Apr 2009 22:11:44 -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 011A53A6AE3 for ; Wed, 29 Apr 2009 22:11:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=MSCnVzLlxXw/ir7FPCJf4opUyXuXRsp7CFZ9DnU3z3nkWi7RczbSgDwNxQzbyy8w; 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.221.109] by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LzOZo-00033E-Us; Thu, 30 Apr 2009 01:12:54 -0400 Message-ID: <49F93416.9010604@earthlink.net> Date: Wed, 29 Apr 2009 22:16: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> In-Reply-To: <004c01c9c3fb$ac973c90$05c5b5b0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478594a5b3a834a310ea0f8f06c6b982376d94f55005f3f58d7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.221.109 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, 30 Apr 2009 05:11:46 -0000 Teco, I am glad you are looking at more efficient strategies for MPR flooding. It is probably too late for OLSRv2, but as Charlie said, it is useful to discuss this for a future version of OLSR (or another protocol). Your example with 10 nodes shows that MPR flooding can be very inefficient. In particular, if every MANET node has both a MANET interface and another interface with a stub link, then every node must select all MANET neighbors as MPRs! Simply using per-node MPRs does not help in this case, which is why you are proposing different MPR types for: (1) forwarding on the same interface, (2) forwarding on all other interfaces, and (3) forwarding on all interfaces. I agree this is more efficient than the current specification. But if there are more than 2 interfaces, and thus more than 1 "other" interfaces, I think it can still be inefficient. 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. Instead of having different MPR types, I would suggest a simpler scheme in which MPRs are still selected per interface, but all MPRs are of type "this_interface", so that they only forward on the same interface. The decision to forward on other interfaces would be made by the router doing the forwarding, based on 2-hop neighbor information. In this sense, one can say that MPRs of type "other_interface" are self-selecting MPRs. It is easy to come up with an algorithm for making this decision in an efficient way. Another advantage of this strategy is that Hello messages only need to list neighbors on the same interface that the Hello is sent on (like OSPF), in contrast to NDHP, which requires that each Hello list all neighbors on all interfaces! Teco's example is why I took a similar approach with OSPF-MDR (draft-ietf-ospf-manet-mdr). In OSPF-MDR, CDS nodes (MDRs) are selected per interface and are used to forward only on the same interface. Richard Teco Boot wrote: >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 > > > From ogier@earthlink.net Thu Apr 30 07:41:57 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 21C993A7142 for ; Thu, 30 Apr 2009 07:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.727, 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 lG8wcoyWl87Y for ; Thu, 30 Apr 2009 07:41:56 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 4A0E03A6ECA for ; Thu, 30 Apr 2009 07:41:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=tuNx87TO4TGV4CWFXmcpz1rzX75BS7Rg0JpGnVnmBx9HwkisgD8BFvXM0YTqbqG7; 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.221.245] by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LzXTq-00061G-4K; Thu, 30 Apr 2009 10:43:18 -0400 Message-ID: <49F9B9C6.6090305@earthlink.net> Date: Thu, 30 Apr 2009 07:46:30 -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: a073897a9455599e74bf435c0eb9d478594a5b3a834a310e47cdccaddbec87b176d0d5411082e1fc350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.221.245 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, 30 Apr 2009 14:41:57 -0000 Although the scheme I suggested in my last post would be a major change to OLSRv2, I would like to add that Teco's suggestion (below) is a minor change that can easily be included in OLSRv2. As Teco showed, this change can greatly improve flooding efficiency, and the use of the new MPR types (this_interface and other_interfaces) is optional, so routers can ignore it. I assume this can be incorporated in a backward compatible manner. Richard Teco Boot wrote: >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. > > >