Energy-aware broadcasting and multicasting

-- Laboratoire de Geophysique Interne et Tectonophysique (UMR CNRS C5559), Universite Joseph Fourier adresse: BP 53X F38041 Grenoble Cedex, France Tel: +33 (0)4 76828029 Fax: +33 (0)4 76828101

How to design Ad Hoc routing protocols ?
How to = manage=20 dynamically changing topology?
Which applications are targeted ? =
Are=20 these networks scalable ?
Mobile Ad Hoc Networks '02, = to take place=20 in Paris, France, from March 5 to=20 8, 2002, will bring answers and enlightenment to all these = questions=20 through the presentations of leading-edge researchers in the domain.=20

http://www.uppersid= e.fr/adhoc/adhocintro.htm

------=_NextPart_000_01D5_01C1A32E.A5A8A2C0-- From owner-manet@itd.nrl.navy.mil Tue Jan 22 13:35:57 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04004 for ; Tue, 22 Jan 2002 13:35:57 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA17033 for manet-outgoing; Tue, 22 Jan 2002 10:51:52 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA17021; Tue, 22 Jan 2002 10:51:45 -0500 (EST) Message-Id: <5.0.1.4.2.20020122104909.019d2820@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 22 Jan 2002 10:58:51 -0500 To: ogier@erg.sri.com, manet@itd.nrl.navy.mil From: Joe Macker Subject: Re: Manet flooding / broadcasting.... In-Reply-To: <200201212029.MAA24553@den.erg.sri.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id KAA17026 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit At 12:29 PM 1/21/2002 -0800, ogier@erg.sri.com wrote: >Please see my comments below. > >> Richard Ogier wrote: >> >> > Yes, I agree that this encapsulation should be optional, and >> > is done *above* the MANET network layer. It would be done by >> > an application that chooses to treat the MANET like an Ethernet. >> > (Some applications may not want to treat the MANET like an Ethernet.) >> > The MANET network layer should treat the limited broadcast address >> > 255.255.255.255 exactly as in RFC1812 (i.e., a packet with this address >> > should not be forwarded). For example, the MANET might *include* an >> > actual Ethernet as one subnet, and 255.255.255.255 can be used by >> > a MANET router to reach all other routers connected to that Ethernet, >> > or more generally to reach all neighboring routers. > >Thomas Clausen wrote: > >> We're basically digging up an old question here, however I hope it is >> possible for the the WG to reach a concensus. The question is simply one >> of how RFC1812 applies to a MANET. >> >> Strictly speaking, according to RFC1812, the expectation of a limited >> broadcast is for that to never be forwarded. I.e. in a MANET, a limited >> broadcast should reach only the originating nodes neighbors. >> >> However, speaking in terms of applications requirements, it seems to me >> that the analogy of a manet on equal terms as an "Ethernet" may be more >> appropriate, and hence a limited broadcast should reach all nodes in the >> manet (but none beyond the manet). Think dhcp as a possible application in >> this context: perhaps one node in the manet acts as dhcp-server, yet this >> is not present in all nodes neighborhood. > >I think we should adhere to RFC1812 if at all possible, and it is possible >simply by letting the encapsulation be optional. Agreed with the desire to adhere to RFC1812.. As an aside, I think we should apply a well-known local multicast address space (224.0.0.x) for the purposes of flooding routing control data e.g, (ALL_MANET_NEIGHBORS or ALL_PROTOCOLNAME_NEIGHBORS..more specific to particular protocol). The routing protocol floods its control data internally using these defined locally scoped multicast addresses. This is consistent with present practice (e.g., OSPF,etc). Whether we define or use a generic mechanism for data flooding is another issue and I feel another address space? >Saying that an application MUST treat a MANET like an Ethernet is like saying >that an application MUST treat an ATM network like an IP subnet (using IP >over ATM). A MANET network does not need to be treated like an Ethernet by >everyone, just like an ATM network need not be treated like an IP subnet. > >Since Fred Baker is the editor of RFC1812, I would like to hear his opinion. > >Regards, >Richard > >> >> Either way, I think this is basically a matter of which symbols to >> associate with which semantics and mechanisms: it should definitely be >> decided, but it should not influence the construction of a broadcast / >> flooding protocol. >> >> -- >> >> ------------------------------------------- >> Thomas Heide Clausen >> Civilingeniør i Datateknik (cand.polyt) >> M.Sc in Computer Engineering >> >> E-Mail: T.Clausen@computer.org >> WWW: http://www.cs.auc.dk/~voop >> ------------------------------------------- >> >> >> From owner-manet@itd.nrl.navy.mil Tue Jan 22 15:00:23 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08299 for ; Tue, 22 Jan 2002 15:00:23 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA21803 for manet-outgoing; Tue, 22 Jan 2002 12:21:33 -0500 (EST) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA21795 for ; Tue, 22 Jan 2002 12:21:30 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id JAA21772; Tue, 22 Jan 2002 09:20:27 -0800 (PST) Message-Id: <200201221720.JAA21772@pit.erg.sri.com> To: Fred Baker cc: manet@itd.nrl.navy.mil Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: Manet flooding / broadcasting.... In-reply-to: Your message of "Mon, 21 Jan 2002 14:27:01 PST." <4.3.2.7.2.20020121141325.02fe6728@mira-sjcm-2.cisco.com> Date: Tue, 22 Jan 2002 09:20:27 -0800 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Fred, Thanks for your input. It looks like we are close to reaching a consensus on this issue. > and you should specify exactly what you want the routers to do with the > packets - repeat on all interfaces (AODV), all interfaces except the > arrival interface (OLSR), or on an RPF tree away from the source (TBRPF). I just want to clarify that TBRPF flooding is not tree-based. It can be considered to be a variation of RPF (as I mentioned before), but to reduce message overhead it does not maintain full broadcast trees. Thus, the number of transmissions required to flood a packet to all nodes is somewhere between that of classical flooding and tree-based RPF. (The same is true for OLSR flooding.) Regards, Richard From owner-manet@itd.nrl.navy.mil Tue Jan 22 17:14:47 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12991 for ; Tue, 22 Jan 2002 17:14:47 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA27475 for manet-outgoing; Tue, 22 Jan 2002 14:26:18 -0500 (EST) Received: from sfo.erg.sri.com (sfo.erg.sri.com [128.18.4.100] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA27467 for ; Tue, 22 Jan 2002 14:26:14 -0500 (EST) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id LAA08122; Tue, 22 Jan 2002 11:21:45 -0800 (PST) Message-ID: <3C4DBC9B.C867B719@erg.sri.com> Date: Tue, 22 Jan 2002 11:25:15 -0800 From: "Fred L. Templin" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: T.Clausen@computer.org CC: manet@itd.nrl.navy.mil, templin@erg.sri.com Subject: Re: Manet flooding / broadcasting.... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Thomas, > Another proposal is to use previous-hop information and for a node to only > forward a packet if it is received from a node (previous hop) which is on > the shortest path to the originator of the packet. We have been experimenting with this method for some time, but in a way that coexists with multicast protocols for broadcast media and MANET protocols that require duplicate checks. Consider that multicast forward cache entries in reference implementations such as the Linux kernel check received packets based on tuples of the form: (source, group, interface) This check is sufficient to reject duplicates on broadcast media (e.g. Ethernet) since multicast routing protocols enforce a single active parent for (source, group) on a paticular broadcast interface. But, the check is insufficient for multi-hop media (e.g. MANETs). We propose a simple extension to the API and a new element to multicast forward cache entries to provide tuples of the following form: (source, group, interface, parent) and specify the following behavior based on 'parent': - when parent = 0.0.0.0, behavior is exactly as in current reference implementations - when parent = 255.255.255.255, duplicate detection is performed (i.e., received packets are checked against a duplicate cache) - any other value for parent is interpreted as the IPv4 address of the previous hop from which the packet MUST originate Thus, this simple extension to the API and multicast forwarding cache entry supports legacy behavior for broadcast media, duplicate table checks for protocols that require such, and duplicate check avoidance for protocols that choose to use that function. (All three functions are supported simultaneously within the same multicast forwarding cache.) > I have concerns about the second proposal for two reasons. Firstly, it is > very "proactively oriented": it assumes that a given node has sufficient > information to be able to derive the shortest path to the source. This > approach would, therefore, be hard to apply in a broadcast protocol for > DSR and AODV and as such, it would be hard to arrive at one common MANET > flooding protocol. I believe this concern is alleviated by the above specification. > Secondly, getting the "previous hop" information is not > trivial. While it might be possible to realize (depending on the link > layer and os used) through looking at the hw-address and perform > arp-lookups, I would consider that it is preferable if a flooding protocol > does not depend on such 'hacks'. Getting the previous hop requires a simple lookup in the neighbor cache. In Linux, this can be done using the same mechanisms employed for sending redirects, so there is existing precedent, i.e. it is not a hack. Duplicate check avoidance can provide benefits for performance and reducing the amount of multicast forwarding cache state required. The fact that it can coexist seamlessly with other approaches seems to argue in favor of further consideration. (Note that we are not committing to adopt the duplicate check avoidance approach at this time, but are conducting further investigation.) Fred templin@erg.sri.com From owner-manet@itd.nrl.navy.mil Wed Jan 23 06:10:28 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05475 for ; Wed, 23 Jan 2002 06:10:27 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id DAA13849 for manet-outgoing; Wed, 23 Jan 2002 03:44:26 -0500 (EST) Received: from aspen.cs.ucla.edu (Aspen.CS.UCLA.EDU [131.179.120.35]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id DAA13844 for ; Wed, 23 Jan 2002 03:44:23 -0500 (EST) Received: from cs.ucla.edu (ts14-30.dialup.bol.ucla.edu [164.67.24.39]) by aspen.cs.ucla.edu (8.11.2/UCLACS-5.0) with ESMTP id g0N8b6u25928; Wed, 23 Jan 2002 00:37:06 -0800 (PST) Message-ID: <3C4E792E.46C98BFA@cs.ucla.edu> Date: Wed, 23 Jan 2002 00:49:50 -0800 From: Mineo Takai X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Li-Ping Tung CC: MANET mailing list Subject: Re: about ns-2 References: <5.0.1.4.2.20020116104109.030735e8@pop.itd.nrl.navy.mil> <3C45F07F.18F5C62D@cs.ucla.edu> <000c01c1a31a$95a43b50$764f728c@toy> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi Li-Ping, If you use ns-2 and set 11 Mbps as the data rate, I would recommend the following changes to the ns-2 802.11 PHY source: (1) Change the transmission duration of PHY preamble and header to 96us (or 192us). (2) Set PHY parameters (carrier frequency, tx power, cs sensitivity etc.) based on the IEEE 802.11 standard and one of its implementations. (3) Implement a model that calculates BER based on instantaneous SNR and CCK (complementary code keying) modem performance, and use it instead of the capture threshold to determine successful frame reception. These changes should make the ns-2 802.11 PHY model much better. Please note that doing (3) requires rather extensive effort, so you might want to ask for volunteers on the ns-2 user mailing list. (Sorry, I am not an active ns-2 user!) Other simulators such as GloMoSim, QualNet and OPNET already have a frame reception model similar to (3). Mineo Li-Ping Tung wrote: > > Hello, Mineo : > > So if I want to use ns-2 simulator with 11 Mbps, should I change any ns-2 > source source, or that I just set the parameter to let the transmission rate > to become 11 Mbps ? > > Li-Ping > > > Hello, > > > > I have a list of comments from my modeling & simulation experience: > > > > - Parameters in the ns-2 802.11 model set by default are based on a several > > year ago WaveLAN card, which was made before the IEEE 802.11 standard. > > Therefore, the channel frequency in ns-2 is set differently from the standard > > (ns-2 802.11: 914 MHz, IEEE 802.11 DSSS PHY: 2.4 GHz) along with other PHY > > parameters. > > > > - The IEEE 802.11 DSSS PHY sets the PHY preamble and header size in > > microseconds (192us; 802.11b has a short preamble option of 96us) while the > > ns-2 802.11 does it in bits (192 bits). Compared to the MAC header size, the > > PHY preamble is much longer and has significant impacts on the overall network > > performance. When the data rate is set to 11Mbps in ns-2, the PHY preamble > > size needs to be multiplied by 11 (or 5.5 assuming the short preamble option, > > which seems common in real 802.11b implementations). > > > > - The ns-2 802.11 model holds a power value of previously received packet, and > > uses it as the baseline to determine successful reception of incoming packets. > > This results in very optimistic simulation results as there is no > > consideration of noise or accumulated interference from multiple neighbors, > > particularly when there are several ongoing transmissions in the network. I > > believe other simulators like QualNet, GloMoSim and OPNET consider noise and > > accumulated interference for successful packet reception by calculating Signal > > to Noise Ratio, or SNR. > > > > - When the data rate of 11Mbps (with CCK modulation) is used, the required SNR > > to achieve the same BER (Bit Error Rate) increases. This may result in smaller > > communication range as Joe Macker says in presence of interference, but it may > > not be true if the channel is in good condition. As ns-2 802.11 PHY model does > > not simulate interference properly, it will be hard to observe real effects of > > high data rate communication in ns-2. Just setting the data rate to 11Mbps > > will give you even more optimistic simulation results! > > > > Our recent publication (ftp://pcl.cs.ucla.edu/pub/papers/mobihoc.ps) includes > > some simulation results from the comparison of ns-2 and GloMoSim, which may > > help understand what I wrote here. > > > > Mineo > > -- Mineo Takai, Ph.D. Principal Development Engineer UCLA Computer Science Department From owner-manet@itd.nrl.navy.mil Wed Jan 23 07:34:54 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06316 for ; Wed, 23 Jan 2002 07:34:54 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA15122 for manet-outgoing; Wed, 23 Jan 2002 05:31:02 -0500 (EST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id FAA15117 for ; Wed, 23 Jan 2002 05:30:51 -0500 (EST) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 11:30:36 +0100 Message-ID: <0489A7888F080B4BA73B53F7E145F29A022C94@LANMHS20.rd.francetelecom.fr> From: MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN To: "'ogier@erg.sri.com'" , Fred Baker Cc: manet@itd.nrl.navy.mil Subject: Address Allocation Date: Wed, 23 Jan 2002 11:30:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-f3c477a7-0f6f-11d6-b1e4-00508b69ab48" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-f3c477a7-0f6f-11d6-b1e4-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A3F9.05043C3E" ------_=_NextPart_001_01C1A3F9.05043C3E Content-Type: text/plain hi every body is anyone know the manner used by an Ad Hoc host to get an IP address ? is there a differences betwwen a local area and a large nnetwork for the allocation ? best regards ------_=_NextPart_001_01C1A3F9.05043C3E Content-Type: text/html Content-Transfer-Encoding: quoted-printable Address Allocation

hi every body

is anyone know the manner used by an Ad Hoc host to = get an IP address ? is there a differences betwwen a local area and a = large nnetwork for the allocation ?

best regards

------_=_NextPart_001_01C1A3F9.05043C3E-- ------=_NextPartTM-000-f3c477a7-0f6f-11d6-b1e4-00508b69ab48-- From owner-manet@itd.nrl.navy.mil Wed Jan 23 11:43:50 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15748 for ; Wed, 23 Jan 2002 11:43:50 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA20865 for manet-outgoing; Wed, 23 Jan 2002 09:32:30 -0500 (EST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA20858 for ; Wed, 23 Jan 2002 09:32:27 -0500 (EST) Received: from prisse (prisse.inria.fr [128.93.9.64]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g0NEWOT25294; Wed, 23 Jan 2002 15:32:24 +0100 (MET) Message-ID: <000701c1a41c$81182f90$40095d80@inria.fr> From: "Philippe Jacquet" To: "Fred L. Templin" , References: <3C4DBC9B.C867B719@erg.sri.com> Subject: Re: Manet flooding / broadcasting.... Date: Wed, 23 Jan 2002 15:44:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Fred L. Templin" To: Cc: ; Sent: Tuesday, January 22, 2002 8:25 PM Subject: Re: Manet flooding / broadcasting.... > Thomas, > > Getting the previous hop requires a simple lookup in the neighbor cache. > In Linux, this can be done using the same mechanisms employed for sending > redirects, so there is existing precedent, i.e. it is not a hack. Duplicate > check avoidance can provide benefits for performance and reducing the amount > of multicast forwarding cache state required. The fact that it can coexist > seamlessly with other approaches seems to argue in favor of further > consideration. (Note that we are not committing to adopt the duplicate check > avoidance approach at this time, but are conducting further investigation.) > Is neighbor cache not built only from ARP packets? Broadcast (multicast) packets are not caught. How can you get the last hop IP addresses of a broadcast packet this way? Philippe From owner-manet@itd.nrl.navy.mil Wed Jan 23 11:44:50 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15783 for ; Wed, 23 Jan 2002 11:44:50 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA20507 for manet-outgoing; Wed, 23 Jan 2002 09:24:25 -0500 (EST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id JAA20499 for ; Wed, 23 Jan 2002 09:24:19 -0500 (EST) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 15:24:01 +0100 Message-ID: <0489A7888F080B4BA73B53F7E145F29A022C9D@LANMHS20.rd.francetelecom.fr> From: MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN To: "'ogier@erg.sri.com'" , Fred Baker Cc: manet@itd.nrl.navy.mil Subject: performance comparaison between Ad Hoc routing protocols Date: Wed, 23 Jan 2002 15:24:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-f3c47f91-0f6f-11d6-b1e4-00508b69ab48" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-f3c47f91-0f6f-11d6-b1e4-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A419.A2991266" ------_=_NextPart_001_01C1A419.A2991266 Content-Type: text/plain hi all body is there any new studies wich made a comparaison between all routing protocols (espicially AODV and OLSR) . thank you best regards ------_=_NextPart_001_01C1A419.A2991266 Content-Type: text/html Address Allocation

hi all body

is there any new studies wich made a comparaison between all routing protocols (espicially AODV and OLSR) .

thank you

best regards

------_=_NextPart_001_01C1A419.A2991266-- ------=_NextPartTM-000-f3c47f91-0f6f-11d6-b1e4-00508b69ab48-- From owner-manet@itd.nrl.navy.mil Wed Jan 23 11:44:54 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15796 for ; Wed, 23 Jan 2002 11:44:53 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA20692 for manet-outgoing; Wed, 23 Jan 2002 09:28:11 -0500 (EST) Received: from smtp.ufl.edu (sp47en1.nerdc.ufl.edu [128.227.74.47]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA20685 for ; Wed, 23 Jan 2002 09:28:08 -0500 (EST) From: wjlou@ufl.edu Received: from spnode41 (sp41en1.nerdc.ufl.edu [128.227.74.41]) by smtp.ufl.edu (8.12.1/8.12.1/2.3.5) with ESMTP id g0NES6QZ063804 for ; Wed, 23 Jan 2002 09:28:06 -0500 Date: Wed, 23 Jan 2002 09:28:06 -0500 Message-ID: <-77589063.1011796086271.JavaMail.httpd@spnode41> To: MANET mailing list Subject: Energy Consumption Calculation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: jwma X-Scanned-By: NERDC Open Systems Group (http://open-systems.ufl.edu/services/virus-scan/) Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Can someone refer me models for energy consumption calculation in ad hoc networks? I wonder what is a good assumption to evaluate the total energy consumption. Thanks. Wenjing ------------------- From owner-manet@itd.nrl.navy.mil Wed Jan 23 14:15:39 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21219 for ; Wed, 23 Jan 2002 14:15:38 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA26503 for manet-outgoing; Wed, 23 Jan 2002 11:32:01 -0500 (EST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA26494 for ; Wed, 23 Jan 2002 11:31:57 -0500 (EST) Received: from prisse (prisse.inria.fr [128.93.9.64]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g0NGVtT00636; Wed, 23 Jan 2002 17:31:55 +0100 (MET) Message-ID: <001801c1a42d$33b26f20$40095d80@inria.fr> From: "Philippe Jacquet" To: , "Fred Baker" References: <4.3.2.7.2.20020121141325.02fe6728@mira-sjcm-2.cisco.com> Subject: Re: Manet flooding / broadcasting.... Date: Wed, 23 Jan 2002 17:44:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Fred Baker" To: Sent: Monday, January 21, 2002 11:27 PM Subject: Re: Manet flooding / broadcasting.... > I agree. It seems, as I read through the protocols, like there is use for > something which reaches the immediate neighbors only (such as in "hello" > functionality) and for something which will proceed some number of hops > away, usually limited by TTL. It seems to me most consistent if one defines > local broadcast as reaching exactly those systems whose radios (or > whatever) can "hear" the original transmission, and no other. If you want > to provide a particular multicast address which uses some form of RPF > forwarding up to some distance, you should define that address separately, > and you should specify exactly what you want the routers to do with the > packets - repeat on all interfaces (AODV), all interfaces except the > arrival interface (OLSR), or on an RPF tree away from the source (TBRPF). > To my mind, those are three different algorithms, and should be specified > separately. > Yes, each protocol has its own way for flooding control traffic. It is clear that the data can be flooded the same way, but in this case the flooding would be routing protocol dependent. I know that in DSR broadcast data are encapsulated in Route Request message. In OLSR the generic broadcast control traffic format can be used as well. The question is: is it possible to do with broadcast data the same way as we did with unicast data, namely to let the IP-stack to do the forwarding alone and to restrict the routing application to generate routing tables? If the answer is yes, it is probably worthy to define a common framework for this forwarding extension. If the answer is no, I agree, the broadcast forwarding could be just an extension of the unicast routing protocol. Philippe From owner-manet@itd.nrl.navy.mil Wed Jan 23 15:49:43 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24855 for ; Wed, 23 Jan 2002 15:49:43 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA01919 for manet-outgoing; Wed, 23 Jan 2002 13:25:53 -0500 (EST) Received: from sfo.erg.sri.com (sfo.erg.sri.com [128.18.4.100] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA01914 for ; Wed, 23 Jan 2002 13:25:49 -0500 (EST) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id KAA21944; Wed, 23 Jan 2002 10:21:27 -0800 (PST) Message-ID: <3C4EFFFE.A7B289FB@erg.sri.com> Date: Wed, 23 Jan 2002 10:25:02 -0800 From: "Fred L. Templin" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Philippe Jacquet CC: manet@itd.nrl.navy.mil, templin@erg.sri.com Subject: Re: Manet flooding / broadcasting.... References: <3C4DBC9B.C867B719@erg.sri.com> <000701c1a41c$81182f90$40095d80@inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Phillipe, > Is neighbor cache not built only from ARP packets? Broadcast (multicast) > packets are not caught. How can you get the last hop IP addresses of a > broadcast packet this way? There will NEVER be a case of consulting the neighbor cache for a broadcast/multicast address. The following clarifications to my previous message should aid in understanding: > and specify the following behavior based on 'parent': > > - when parent = 0.0.0.0, behavior is exactly as in current > reference implementations > > - when parent = 255.255.255.255, duplicate detection is performed > (i.e., received packets are checked against a duplicate cache) When parent = 0.0.0.0 (respectively, 255.255.255.255), previous-hop verification is NOT performed; instead, these values for parent indicate to the kernel multicast forwarding cache that no checks (respectively, duplicate packet checks) are used for received packets for this particular cache entry. > - any other value for parent is interpreted as the IPv4 address > of the previous hop from which the packet MUST originate Only IPv4 *unicast* addresses are accepted for 'parent' by the API that creates multicast forwarding cache entries. The following note should be added to the above: (Note: implementations MUST verify that 'parent' encodes an IPv4 unicast address when the multicast forwarding cache entry is created) Finally, the algorithm for previous-hop verification when 'parent' encodes an IPv4 unicast address is as follows: - Compare the MAC (layer-2) source address of the received packet with the MAC address resolution for 'parent'. If the two addresses match, ACCEPT the packet; else, REJECT Fred templin@erg.sri.com From owner-manet@itd.nrl.navy.mil Wed Jan 23 18:49:33 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29644 for ; Wed, 23 Jan 2002 18:49:33 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA10275 for manet-outgoing; Wed, 23 Jan 2002 15:55:00 -0500 (EST) Received: from sfo.erg.sri.com (sfo.erg.sri.com [128.18.4.100] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA10267 for ; Wed, 23 Jan 2002 15:54:51 -0500 (EST) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id MAA23888; Wed, 23 Jan 2002 12:50:07 -0800 (PST) Message-ID: <3C4F22D8.734C2741@erg.sri.com> Date: Wed, 23 Jan 2002 12:53:44 -0800 From: "Fred L. Templin" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Philippe Jacquet CC: manet@itd.nrl.navy.mil, templin@erg.sri.com Subject: Re: Manet flooding / broadcasting.... References: <3C4DBC9B.C867B719@erg.sri.com> <000701c1a41c$81182f90$40095d80@inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Phillipe, > Is neighbor cache not built only from ARP packets? Broadcast (multicast) > packets are not caught. How can you get the last hop IP addresses of a > broadcast packet this way? It's possible I may have mis-interpreted your concern; are you asking about the case when a node receives only broadcast/multicast (and not unicast) packets from a particular previous hop? In that case, you are right that there may be no pre-existing neighbor cache entry for the previous hop. The receiving node corrects this by issuing an on-demand neighbor resolution for the previous hop's IPv4 address (in this case, by sendig an 'ARPOP_REQUEST'). Muticast packets received while the resolution is in-progress are temporarily cached by the node in the same manner as when a multicast forwarding cache entry for (source, group, interface) does not yet exist in the current model. Note that, if the node is performing explicit neighbor cache management based on received neighbor discovery messages, the neighbor cache entry may be maintained proactively, rather than on-demand based on unicast packet arrivals; thus avoiding the above scenario. We believe proactive neighbor cache mangement (when possible) can provide the important benefit of increasing packet delivery ratio; the above scenario is just one example where this is true. Fred templin@erg.sri.com From owner-manet@itd.nrl.navy.mil Wed Jan 23 23:11:58 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05044 for ; Wed, 23 Jan 2002 23:11:58 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA17196 for manet-outgoing; Wed, 23 Jan 2002 20:59:37 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id UAA17191 for ; Wed, 23 Jan 2002 20:59:34 -0500 (EST) Received: from FRED-W2K6.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0O1xVd19474; Wed, 23 Jan 2002 17:59:32 -0800 (PST) Message-Id: <4.3.2.7.2.20020123093540.0452af08@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 17:53:42 -0800 To: "Philippe Jacquet" From: Fred Baker Subject: Re: Manet flooding / broadcasting.... Cc: In-Reply-To: <001801c1a42d$33b26f20$40095d80@inria.fr> References: <4.3.2.7.2.20020121141325.02fe6728@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 08:44 AM 1/23/2002, Philippe Jacquet wrote: >The question is: is it possible to do with broadcast data the same way as we >did with unicast data, namely to let the IP-stack to do the forwarding alone >and to restrict the routing application to generate routing tables? the problem I come up with is this. Most, perhaps all, of these broadcast approaches do not simply say "I received a message on {S,G}, send it to this set of interfaces". They say "if my router id or address is not in this list..." or "if the message is not in my cache of recently retransmitted broadcasts..." or something else. The IP code wants to be fairly generic; if you have a manet interface and a wired interface, there is no reason for the wired interface to have a different IP forwarder than yours. If you assume it is designed with a set of "adjacencies" which might constitute individual IP routing or ARP neighbors, and one of which is "myself" (the "send" routine delivers the message upstairs rather than sending it somewhere else), and any given route therefore results in a list of zero or more adjacencies to which or among which the message is to be forwarded, it wants to look something like this (yes I left out the MTU test and all option processing): ip_forwarding (message *datagram, ip_hdr *ip_header) { if (!verify_checksum (ip_header)) fail (); route = route_lookup (ip_header->ip_destination); if (!route) fail (); if (ip_header->destination is not a class D address) { adjacency = one_of_the_adjacencies (route->adjacencies); interface = adjacency->interface; if (interface->ttl_check) { /* we don't decrement TTL when delivering upstairs */ if (ip_header->ttl <= 1) fail (); ip_header->ipttl--; ip->checksum = update_ip_checksum (ip->checksum, 0x0100); } interface->forward_message (datagram, interface, adjacency->linkheader); } else { for (adjacency = route->adjacencies; adjacency; adjacency = adjacency->next) { interface = adjacency->interface; if (interface->ttl_check) { /* we don't decrement TTL when delivering upstairs */ if (ip_header->ttl <= 1) fail (); ip_header->ipttl--; ip->checksum = update_ip_checksum (ip->checksum, 0x0100); } if (adjacency->next) { make a copy of the message for forwarding purposes; } interface->forward_message (copy of datagram, interface, adjacency->mcastlinkheader); } } } What you're asking for is some form if "if it's going to go out on this interface, can we first ask if we think that it should?", and I think you're asking for something fairly specific to the address proposed. That could be achieved with an API pointer in the interface table that is used only in the multicast case: if (interface->forwarding_test) { if (*(interface->forwarding_test(ip_header, interface))) continue; } placed just before the TTL game in the multicast case. The problem you will get into is making it generic to the wired world, which has no such problem, and defining one forwarding test for any kind of interface. Personally, I'd be just as happy to let the routing application handle this rather than add to the IP code path. From owner-manet@itd.nrl.navy.mil Thu Jan 24 05:15:02 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18930 for ; Thu, 24 Jan 2002 05:15:02 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA21574 for manet-outgoing; Thu, 24 Jan 2002 02:57:38 -0500 (EST) Received: from mail.icu.ac.kr (ns.icu.ac.kr [210.107.128.31]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id CAA21569 for ; Thu, 24 Jan 2002 02:57:33 -0500 (EST) Received: from ek (netarch.icu.ac.kr [210.107.131.65]) by mail.icu.ac.kr (8.11.0/8.11.0) with SMTP id g0O7ooX27657; Thu, 24 Jan 2002 16:50:50 +0900 (KST) Message-ID: <001401c1a4ac$a1f1e7c0$41836bd2@ek> From: "Ekyu Lee" To: , "MANET mailing list" References: <-77589063.1011796086271.JavaMail.httpd@spnode41> Subject: Re: Energy Consumption Calculation Date: Thu, 24 Jan 2002 16:56:29 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by itd.nrl.navy.mil id CAA21570 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Hi, Wenjing If you want to caclulate energy consumption in IP layer, you can refer to this site http://vega.icu.ac.kr/~ppl/pub.html Refer to 'Non-Blocking, Localized Routing Algorithm for Balanced Energy Consumption in Mobile Ad Hoc Networks' in conference papers. Ekyu ----- Original Message ----- From: To: "MANET mailing list" Sent: Wednesday, January 23, 2002 11:28 PM Subject: Energy Consumption Calculation > Hi, > > Can someone refer me models for energy consumption calculation in ad hoc > networks? I wonder what is a good assumption to evaluate the total energy > consumption. Thanks. > > Wenjing > ------------------- > > > > > From owner-manet@itd.nrl.navy.mil Thu Jan 24 13:07:37 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29882 for ; Thu, 24 Jan 2002 13:07:37 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA29730 for manet-outgoing; Thu, 24 Jan 2002 10:23:24 -0500 (EST) Received: from ns0.utdallas.edu (ns0.utdallas.edu [129.110.10.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA29710 for ; Thu, 24 Jan 2002 10:23:18 -0500 (EST) Received: from sol2.utdallas.edu (sol2.utdallas.edu [129.110.34.2]) by ns0.utdallas.edu (Postfix) with ESMTP id 264DE1A0F7E; Thu, 24 Jan 2002 09:23:18 -0600 (CST) Received: by sol2.utdallas.edu (Postfix, from userid 30546) id 6742A39B48; Thu, 24 Jan 2002 09:23:09 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by sol2.utdallas.edu (Postfix) with ESMTP id 4EC932A856; Thu, 24 Jan 2002 09:23:09 -0600 (CST) Date: Thu, 24 Jan 2002 09:23:09 -0600 (CST) From: Rajesh Bhairampally To: wjlou@ufl.edu Cc: MANET mailing list Subject: Re: Energy Consumption Calculation In-Reply-To: <-77589063.1011796086271.JavaMail.httpd@spnode41> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, You can refer to my work i just on energy complexity. you can find my paper at my website http://www.utdallas.edu/~rajesh/resume/ In this paper, I presented an analytical way to compute minimum energy consumption of an ad hoc network protocol. Rajesh =============================================================================== Rajesh Bhairampally Graduate Research Assistant Scalable Network Engineering Techniques Lab (NET Lab) University of Texas at Dallas Richardson, TX 75080 Rajesh@utdallas.edu http://www.utdallas.edu/~rajesh =============================================================================== On Wed, 23 Jan 2002 wjlou@ufl.edu wrote: > Hi, > > Can someone refer me models for energy consumption calculation in ad hoc > networks? I wonder what is a good assumption to evaluate the total energy > consumption. Thanks. > > Wenjing > ------------------- > From owner-manet@itd.nrl.navy.mil Thu Jan 24 16:03:04 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05807 for ; Thu, 24 Jan 2002 16:03:03 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA07231 for manet-outgoing; Thu, 24 Jan 2002 13:20:26 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA07226 for ; Thu, 24 Jan 2002 13:20:22 -0500 (EST) Received: from FRED-W2K6.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0OIJud05023; Thu, 24 Jan 2002 10:19:56 -0800 (PST) Message-Id: <4.3.2.7.2.20020124100306.01baefb8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Jan 2002 10:14:17 -0800 To: "Philippe Jacquet" From: Fred Baker Subject: Re: Manet flooding / broadcasting.... Cc: In-Reply-To: <4.3.2.7.2.20020123093540.0452af08@mira-sjcm-2.cisco.com> References: <001801c1a42d$33b26f20$40095d80@inria.fr> <4.3.2.7.2.20020121141325.02fe6728@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk More in response to your note from yesterday. As a way of analyzing the issues, I'm thinking about the behavior of OSPF in the same case, to ask myself what particularly would be different. Guess what; there are quite a few differences, and the various manet protocols are obviously optimized in various ways to reduce the chitchat from what OSPF would go through. However, OSPF resolves this re-broadcasting issue quite simply. It floods an LSA that it receives if and only if the LSA was not already in its link state database, and otherwise ignores it. It seems that moving the function to the application simplifies it based on the application databases, while trying to put it into IP itself makes it fairly complex. BTW, putting it into the application makes the IP TTL unavailable. That argues towards an application level TTL for "widening ring" searches. From owner-manet@itd.nrl.navy.mil Thu Jan 24 17:31:52 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08406 for ; Thu, 24 Jan 2002 17:31:52 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA11515 for manet-outgoing; Thu, 24 Jan 2002 14:56:13 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA11507 for ; Thu, 24 Jan 2002 14:56:09 -0500 (EST) Received: from FRED-W2K6.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0OJu6d21467; Thu, 24 Jan 2002 11:56:06 -0800 (PST) Message-Id: <4.3.2.7.2.20020123085236.05251808@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Jan 2002 11:55:44 -0800 To: MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN From: Fred Baker Subject: Re: Address Allocation Cc: manet@itd.nrl.navy.mil In-Reply-To: <0489A7888F080B4BA73B53F7E145F29A022C94@LANMHS20.rd.francet elecom.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 02:30 AM 1/23/2002, MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN wrote: >is anyone know the manner used by an Ad Hoc host to get an IP address ? is >there a differences betwwen a local area and a large nnetwork for the >allocation ? I don't see any draft that specifically addresses that. It seems to me that there are three possible ways: - static configuration - DHCP or something like it - autoconfiguration frankly, in an IPv6 world, I would hope that some form of autoconfiguration would be useful. There are some issues; if one picks a random number and asks one's immediate neighbors whether it's a good choice, they may not know what would be a good choice after the device moves. However, basing it on a serial number printed in a ROM (as is done with Ethernet addresses) has a good chance of avoiding ambiguities in the procedure. In IPv4 or IPv6, static configuration can be used in networks of moderate scale. DHCP etc has issues, though, at least as it stands. What we do today is configure address proxies which can forward DHCP messages to more central DHCP servers, or configure DHCP servers in the routers themselves. In a manet, this seems problematic - some systems in the network might have difficulty obtaining addresses during times of instability. From owner-manet@itd.nrl.navy.mil Thu Jan 24 21:20:14 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12136 for ; Thu, 24 Jan 2002 21:20:14 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA19168 for manet-outgoing; Thu, 24 Jan 2002 19:05:21 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id TAA19155; Thu, 24 Jan 2002 19:05:13 -0500 (EST) Message-Id: <5.0.1.4.2.20020124184728.030077d8@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 24 Jan 2002 19:13:57 -0500 To: Fred Baker , MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN From: Joe Macker Subject: Re: Address Allocation Cc: manet@itd.nrl.navy.mil In-Reply-To: <4.3.2.7.2.20020123085236.05251808@mira-sjcm-2.cisco.com> References: <0489A7888F080B4BA73B53F7E145F29A022C94@LANMHS20.rd.francet elecom.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 11:55 AM 1/24/2002 -0800, Fred Baker wrote: >At 02:30 AM 1/23/2002, MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN wrote: >>is anyone know the manner used by an Ad Hoc host to get an IP address ? is there a differences betwwen a local area and a large nnetwork for the allocation ? > >I don't see any draft that specifically addresses that. > >It seems to me that there are three possible ways: > - static configuration > - DHCP or something like it > - autoconfiguration > >frankly, in an IPv6 world, I would hope that some form of autoconfiguration would be useful. There are some issues; if one picks a random number and asks one's immediate neighbors whether it's a good choice, they may not know what would be a good choice after the device moves. However, basing it on a serial number printed in a ROM (as is done with Ethernet addresses) has a good chance of avoiding ambiguities in the procedure. I think v6 version implementations hold some promise for easing autoconfiguration here as Fred indicates (by using addresses partially based on MAC addresses,etc). >In IPv4 or IPv6, static configuration can be used in networks of moderate scale. Yes, has been done so in practice within a manet domain of 20-30 nodes with little pain. Would quickly become more painful as things grew and dispersed? Used dhcp at edges for handling wired hosts carried along with manet routers (advertised mask so no brainer there). >DHCP etc has issues, though, at least as it stands. What we do today is configure address proxies which can forward DHCP messages to more central DHCP servers, or configure DHCP servers in the routers themselves. In a manet, this seems problematic - some systems in the network might have difficulty obtaining addresses during times of instability. Some of you may have missed the zeroconf relationship discussions we had in London. Interesting discussions and along the lines of outlining some problem spaces...at least the discussion should have been covered in the minutes. I believe there is future interesting work to be done here. There have been early draft IDs and ideas being kicked around in this space. The distributed, multi-hop nature and potential dynamics are obvious issues. From owner-manet@itd.nrl.navy.mil Thu Jan 24 22:20:52 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13907 for ; Thu, 24 Jan 2002 22:20:51 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA20573 for manet-outgoing; Thu, 24 Jan 2002 20:29:57 -0500 (EST) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id UAA20563; Thu, 24 Jan 2002 20:29:53 -0500 (EST) Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.10.2+Sun/8.9.3) with ESMTP id g0P1TfQ22779; Thu, 24 Jan 2002 17:29:41 -0800 (PST) Date: Thu, 24 Jan 2002 17:29:41 -0800 (PST) From: "Elizabeth M. Belding-Royer" X-Sender: eroyer@saguaro To: djamaleddine.meddour@rd.francetelecom.com cc: fred@cisco.com, macker@itd.nrl.navy.mil, manet@itd.nrl.navy.mil, "Elizabeth M. Belding-Royer" Subject: Re: Address Allocation In-Reply-To: <4.3.2.7.2.20020123085236.05251808@mira-sjcm-2.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > At 02:30 AM 1/23/2002, MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN wrote: > >is anyone know the manner used by an Ad Hoc host to get an IP address ? is > >there a differences betwwen a local area and a large nnetwork for the > >allocation ? > > I don't see any draft that specifically addresses that. > Our revised Internet Draft on address autoconfiguration (revised for the last IETF) addresses this issue for both IPv4 and IPv6 networks. The basic mechanism is that a mobile node selects an address from some address space, and then it must perform duplicate address detection to ensure that address is not already claimed within the network. The draft name is draft-perkins-manet-autoconf-01.txt. Its in the Internet Draft repository. Elizabeth From owner-manet@itd.nrl.navy.mil Fri Jan 25 05:22:36 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28234 for ; Fri, 25 Jan 2002 05:22:36 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA26055 for manet-outgoing; Fri, 25 Jan 2002 02:54:11 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id CAA26043; Fri, 25 Jan 2002 02:54:05 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0P7rmj08643; Fri, 25 Jan 2002 09:53:48 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 25 Jan 2002 09:54:04 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id C0W2X5NN; Fri, 25 Jan 2002 09:54:04 +0200 Received: from nokia.com (tarom@tarom.research.nokia.com [172.21.60.45]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id JAA12970; Fri, 25 Jan 2002 09:54:04 +0200 (EET) X-Authentication-Warning: mgw.research.nokia.com: Host tarom@tarom.research.nokia.com [172.21.60.45] claimed to be nokia.com Message-ID: <3C510EBC.74A690FD@nokia.com> Date: Fri, 25 Jan 2002 09:52:28 +0200 From: Manel Guerrero Zapata X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ext Elizabeth M. Belding-Royer" CC: djamaleddine.meddour@rd.francetelecom.com, fred@cisco.com, macker@itd.nrl.navy.mil, manet@itd.nrl.navy.mil Subject: Re: Address Allocation References: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit If we have a network that is splited in two parts that have no network connectivity between them (the two groups might be far away from each other) and then they get merged (because nodes actually move, and the two groups might get closer), it is possible that two nodes (one on each part) have the same address because when they used this 'duplicate address detection' they didn't detect each other and they thought that nobody else was using the same address than themselves. So, if nodes move, your solution just doesn't work. BR/Manel Guerrero "ext Elizabeth M. Belding-Royer" wrote: > > > At 02:30 AM 1/23/2002, MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN wrote: > > >is anyone know the manner used by an Ad Hoc host to get an IP address ? is > > >there a differences betwwen a local area and a large nnetwork for the > > >allocation ? > > > > I don't see any draft that specifically addresses that. > > > > Our revised Internet Draft on address autoconfiguration > (revised for the last IETF) addresses this issue for both > IPv4 and IPv6 networks. The basic mechanism is that > a mobile node selects an address from some address space, > and then it must perform duplicate address detection to > ensure that address is not already claimed within the network. > > The draft name is draft-perkins-manet-autoconf-01.txt. > Its in the Internet Draft repository. > > Elizabeth From owner-manet@itd.nrl.navy.mil Fri Jan 25 08:54:16 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02714 for ; Fri, 25 Jan 2002 08:54:16 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA28871 for manet-outgoing; Fri, 25 Jan 2002 06:52:46 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id GAA28866 for ; Fri, 25 Jan 2002 06:52:43 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29377; Fri, 25 Jan 2002 06:52:43 -0500 (EST) Message-Id: <200201251152.GAA29377@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: manet@itd.nrl.navy.mil From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-manet-aodv-10.txt Date: Fri, 25 Jan 2002 06:52:42 -0500 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Ad Hoc On Demand Distance Vector (AODV) Routing Author(s) : C. Perkins, E. Royer, S. Das Filename : draft-ietf-manet-aodv-10.txt Pages : 30 Date : 24-Jan-02 The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as 'counting to infinity') associated with classical distance vector protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-aodv-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-aodv-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-aodv-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020124133530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-aodv-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-aodv-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020124133530.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-manet@itd.nrl.navy.mil Fri Jan 25 10:12:22 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04695 for ; Fri, 25 Jan 2002 10:12:22 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA01005 for manet-outgoing; Fri, 25 Jan 2002 08:16:18 -0500 (EST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA01000 for ; Fri, 25 Jan 2002 08:16:15 -0500 (EST) Received: from prisse (prisse.inria.fr [128.93.9.64]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g0PDGBf19640; Fri, 25 Jan 2002 14:16:11 +0100 (MET) Message-ID: <000c01c1a5a4$0e3cf4e0$40095d80@inria.fr> From: "Philippe Jacquet" To: "Fred Baker" Cc: References: <001801c1a42d$33b26f20$40095d80@inria.fr> <4.3.2.7.2.20020121141325.02fe6728@mira-sjcm-2.cisco.com> <4.3.2.7.2.20020124100306.01baefb8@mira-sjcm-2.cisco.com> Subject: Re: Manet flooding / broadcasting.... Date: Fri, 25 Jan 2002 14:27:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Fred Baker" To: "Philippe Jacquet" Cc: Sent: Thursday, January 24, 2002 7:14 PM Subject: Re: Manet flooding / broadcasting.... > However, OSPF resolves this re-broadcasting issue quite simply. It floods > an LSA that it receives if and only if the LSA was not already in its link > state database, and otherwise ignores it. > I agree. OSPF uses the LSA sequence number for this. By the way the flooding of OSPF is fairly heavy since it requires ack from neighbors. > > BTW, putting it into the application makes the IP TTL unavailable. That > argues towards an application level TTL for "widening ring" searches. > Do you mean that the routing application should decrement TTL and this would be against the use of some kind of encapsulation/tunneling by routing? Philippe From owner-manet@itd.nrl.navy.mil Fri Jan 25 13:32:26 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10273 for ; Fri, 25 Jan 2002 13:32:25 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA07924 for manet-outgoing; Fri, 25 Jan 2002 11:18:49 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA07916 for ; Fri, 25 Jan 2002 11:18:46 -0500 (EST) Received: from FRED-W2K6.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0PGIhd09391; Fri, 25 Jan 2002 08:18:43 -0800 (PST) Message-Id: <4.3.2.7.2.20020125080734.01de5398@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 Jan 2002 08:15:41 -0800 To: "Philippe Jacquet" From: Fred Baker Subject: Re: Manet flooding / broadcasting.... Cc: In-Reply-To: <000c01c1a5a4$0e3cf4e0$40095d80@inria.fr> References: <001801c1a42d$33b26f20$40095d80@inria.fr> <4.3.2.7.2.20020121141325.02fe6728@mira-sjcm-2.cisco.com> <4.3.2.7.2.20020124100306.01baefb8@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 05:27 AM 1/25/2002, Philippe Jacquet wrote: >I agree. OSPF uses the LSA sequence number for this. By the way the >flooding of OSPF is fairly heavy since it requires ack from neighbors. true, but I will argue that this is only half the story. OSPF will only use broadcast on an interface that supports a designated router. Hence, it not only acknowledges on a point to point basis, it forwards the information (in a manet, where a designated router election is problematic) on a point to point basis. I bring up OSPF because it is a protocol that is known to work, and has a fair bit of mechanism. Anything that is the same is the same, and anything that is different is up for review. The review is likely to be favorable; the important point is the underlying reason for the difference. > > BTW, putting it into the application makes the IP TTL unavailable. That > > argues towards an application level TTL for "widening ring" searches. > >Do you mean that the routing application should decrement TTL and this would >be against the use of some kind of encapsulation/tunneling by routing? I mean that if the application wants a TTL (such as in an AODV hello-equivalent-RREP or a widening RREQ search, which are both limited by TTL), it should put the TTL in the application layer information. The IP TTL is not necessarily available to it, and requires changes to IP to make use of. I'm pointing out a layer or API violation in some protocols. The IP header is available to upper layers across some interfaces (kernel interfaces, usually) but not across socket interfaces. Let's say, for example, that you wanted to put such a protocol into my router; the IP header would not necessarily be available to the routing protocol, because the routing protocol is an application that rides on the IP layer. From owner-manet@itd.nrl.navy.mil Fri Jan 25 13:32:30 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10287 for ; Fri, 25 Jan 2002 13:32:30 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA07520 for manet-outgoing; Fri, 25 Jan 2002 11:08:01 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA07455; Fri, 25 Jan 2002 11:06:46 -0500 (EST) Message-Id: <5.0.1.4.2.20020125103739.02fff618@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 25 Jan 2002 11:15:27 -0500 To: Manel Guerrero Zapata , "ext Elizabeth M. Belding-Royer" From: Joe Macker Subject: Re: Address Allocation Cc: djamaleddine.meddour@rd.francetelecom.com, fred@cisco.com, manet@itd.nrl.navy.mil In-Reply-To: <3C510EBC.74A690FD@nokia.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Manel: These same issues were raised by many during the London meeting and in years past. Along these lines, I remember looking through related work in distributed multicast address allocation (at the application layer to setup dynamic unique endpoint identifiers) attempting to address issues of "collision detection and resolution" as dynamics and topology fragmentation occur. Not an easy problem, especially at the routing protocol layer. So I don't think we have a good robust solution at the present time for surviving and recovering robustly from duplicate address collision for dynamic, multi-hop networks with fragmentation,etc occurring. As another (less distributed option) a fixed arbitration authority (manet stubs may often connect to a fixed infrastructure),etc can perhaps solve this in an easier fashion that handles the fragmentation case. Multicast or anycast services might be useful regardless of how its solved. -Joe At 09:52 AM 1/25/2002 +0200, Manel Guerrero Zapata wrote: >If we have a network that is splited in two parts that have no network >connectivity between them (the two groups might be far away from each >other) and then they get merged (because nodes actually move, and the >two groups might get closer), it is possible that two nodes (one on >each part) have the same address because when they used this >'duplicate address detection' they didn't detect each other and they >thought that nobody else was using the same address than themselves. > >So, if nodes move, your solution just doesn't work. > >BR/Manel Guerrero > > >"ext Elizabeth M. Belding-Royer" wrote: >> >> > At 02:30 AM 1/23/2002, MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN wrote: >> > >is anyone know the manner used by an Ad Hoc host to get an IP address ? is >> > >there a differences betwwen a local area and a large nnetwork for the >> > >allocation ? >> > >> > I don't see any draft that specifically addresses that. >> > >> >> Our revised Internet Draft on address autoconfiguration >> (revised for the last IETF) addresses this issue for both >> IPv4 and IPv6 networks. The basic mechanism is that >> a mobile node selects an address from some address space, >> and then it must perform duplicate address detection to >> ensure that address is not already claimed within the network. >> >> The draft name is draft-perkins-manet-autoconf-01.txt. >> Its in the Internet Draft repository. >> >> Elizabeth From owner-manet@itd.nrl.navy.mil Fri Jan 25 14:23:09 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11718 for ; Fri, 25 Jan 2002 14:23:08 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA10498 for manet-outgoing; Fri, 25 Jan 2002 12:23:20 -0500 (EST) Received: from ns0.utdallas.edu (ns0.utdallas.edu [129.110.10.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA10482; Fri, 25 Jan 2002 12:23:08 -0500 (EST) Received: from inca.utdallas.edu (inca.utdallas.edu [129.110.16.10]) by ns0.utdallas.edu (Postfix) with ESMTP id DC9EB1A065F; Fri, 25 Jan 2002 11:23:08 -0600 (CST) Received: by inca.utdallas.edu (Postfix, from userid 19293) id C601F9909B; Fri, 25 Jan 2002 11:23:05 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by inca.utdallas.edu (Postfix) with ESMTP id 8783186E6A; Fri, 25 Jan 2002 11:23:05 -0600 (CST) Date: Fri, 25 Jan 2002 11:23:05 -0600 (CST) From: Sanket Nesargi To: Manel Guerrero Zapata Cc: "ext Elizabeth M. Belding-Royer" , djamaleddine.meddour@rd.francetelecom.com, fred@cisco.com, macker@itd.nrl.navy.mil, Mobile Ad-hoc Networks , Ravi Prakash Subject: Re: Address Allocation In-Reply-To: <3C510EBC.74A690FD@nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk On the topic of address allocation, we have a paper titled - "MANETconf: Configuration of Hosts in a Mobile Ad Hoc Network", due to appear in the proceedings of Infocom 2002. We have presented a comparison of the exitsing approaches to address allocation, and developed a distributed alogirithm to dynamically allocate addresses. Issues related to partitioning and the merger of partitions (leading to address conflicts) have been addressed as well. This paper can be accessed at: www.utdallas.edu/~ravip/papers/infocom2002.pdf We hope that our paper addresses some of the more pertinent issues in address allocation. Any feedback is very welcome. Thanks, - Sanket --------------------------------------------------------------------- Standing on a hill in my mountain of dreams, telling myself its not as hard as it seems - Led Zeppelin Sanket S. Nesargi Distributed Systems Lab University of Texas at Dallas, http://www.utdallas.edu/~sanket Richardson TX 75082 --------------------------------------------------------------------- On Fri, 25 Jan 2002, Manel Guerrero Zapata wrote: > If we have a network that is splited in two parts that have no network > connectivity between them (the two groups might be far away from each > other) and then they get merged (because nodes actually move, and the > two groups might get closer), it is possible that two nodes (one on > each part) have the same address because when they used this > 'duplicate address detection' they didn't detect each other and they > thought that nobody else was using the same address than themselves. > > So, if nodes move, your solution just doesn't work. > > BR/Manel Guerrero > > > "ext Elizabeth M. Belding-Royer" wrote: > > > > > At 02:30 AM 1/23/2002, MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN wrote: > > > >is anyone know the manner used by an Ad Hoc host to get an IP address ? is > > > >there a differences betwwen a local area and a large nnetwork for the > > > >allocation ? > > > > > > I don't see any draft that specifically addresses that. > > > > > > > Our revised Internet Draft on address autoconfiguration > > (revised for the last IETF) addresses this issue for both > > IPv4 and IPv6 networks. The basic mechanism is that > > a mobile node selects an address from some address space, > > and then it must perform duplicate address detection to > > ensure that address is not already claimed within the network. > > > > The draft name is draft-perkins-manet-autoconf-01.txt. > > Its in the Internet Draft repository. > > > > Elizabeth > From owner-manet@itd.nrl.navy.mil Fri Jan 25 16:33:33 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14875 for ; Fri, 25 Jan 2002 16:33:31 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA15847 for manet-outgoing; Fri, 25 Jan 2002 14:24:36 -0500 (EST) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA15830 for ; Fri, 25 Jan 2002 14:24:32 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id LAA03021; Fri, 25 Jan 2002 11:23:30 -0800 (PST) Message-Id: <200201251923.LAA03021@pit.erg.sri.com> To: Fred Baker cc: manet@itd.nrl.navy.mil, ogier@erg.sri.com Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: Manet flooding / broadcasting.... In-reply-to: Your message of "Fri, 25 Jan 2002 08:15:41 PST." <4.3.2.7.2.20020125080734.01de5398@mira-sjcm-2.cisco.com> Date: Fri, 25 Jan 2002 11:23:30 -0800 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > At 05:27 AM 1/25/2002, Philippe Jacquet wrote: > >I agree. OSPF uses the LSA sequence number for this. By the way the > >flooding of OSPF is fairly heavy since it requires ack from neighbors. > > true, but I will argue that this is only half the story. OSPF will only use > broadcast on an interface that supports a designated router. Hence, it not > only acknowledges on a point to point basis, it forwards the information > (in a manet, where a designated router election is problematic) on a point > to point basis. I would say this is much less than half the story, since there are other factors that make TBRPF and OLSR more efficient than OSPF in MANETs: - OSPF uses classical flooding to disseminate LSA's, (except on interfaces that support designated routers), whereas TBRPF and OLSR use more efficient mechanisms (based on parents and MPRs) for propagating topology information. (Actually, one could say that these efficient mechanisms are analogous to designated routers, which as you say are problematic for MANETs.) - OSPF is a full-topology protocol, i.e., every node within a given area is provided with the entire topology of the area, whereas TBRPF and OLSR provide each node with only a small part of the topology, sufficient to compute shortest paths. - In OSPF, each HELLO contains the ID of every neighbor, whereas TBRPF uses much smaller differential HELLOs, which report only *changes* in neighbor states. There are other differences (such as the fact that TBRPF does not require sequence numbers for topology updates), but I think but these are the main advantages over OSPF. Regards, Richard From owner-manet@itd.nrl.navy.mil Fri Jan 25 16:33:36 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14887 for ; Fri, 25 Jan 2002 16:33:35 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA14191 for manet-outgoing; Fri, 25 Jan 2002 13:52:23 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA14166; Fri, 25 Jan 2002 13:52:02 -0500 (EST) Message-Id: <5.0.1.4.2.20020125135002.07877fe8@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 25 Jan 2002 14:00:44 -0500 To: Saad Biaz From: Joe Macker Subject: Re: Is a network layer address meaningful in adhoc networks? Cc: Manel Guerrero Zapata , "ext Elizabeth M. Belding-Royer" , djamaleddine.meddour@rd.francetelecom.com, fred@cisco.com, manet@itd.nrl.navy.mil In-Reply-To: References: <5.0.1.4.2.20020125103739.02fff618@pop.itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 11:22 AM 1/25/2002 -0600, Saad Biaz wrote: >I am following this thread of address allocation and wonder about the >necessity or the meaning of an address at the network layer. > >Let us consider an IP address. This IP address is useful at the network >layer ONLY to bring a packet to the right subnet. When a packet reaches the >subnet, it is the MAC address that is used to find out the node. > >Now, consider the adhoc networks. There are no subnets. Nodes moving from >place to place, sometimes in the range of some set of nodes, later in te >range of another set. If the network layer does not refer to some >"grouping", then why need one. It is useless. > >Therefore, why not just use the MAC address that is normally unique? You may have missed in the thread we talked about this option. Using a potentially unique ROM-burned number as a segment of the address space was covered in the discussion and its a good option. We are however dealing with IP routing, since this is an IETF WG, and heterogeneity,etc is important. There may indeed be large sets of fixed subnets attached to mobile manet routers in some cases or we may route across multiple wireless media. We have discussed this before. -Joe From owner-manet@itd.nrl.navy.mil Fri Jan 25 16:54:06 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15387 for ; Fri, 25 Jan 2002 16:54:06 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA17180 for manet-outgoing; Fri, 25 Jan 2002 14:53:02 -0500 (EST) Received: from hamberg.it.uu.se (hamberg.it.uu.se [130.238.9.198]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA17175 for ; Fri, 25 Jan 2002 14:52:58 -0500 (EST) Received: from localhost (henrikl@localhost) by hamberg.it.uu.se (8.8.5/8.8.5) with ESMTP id UAA05109 for ; Fri, 25 Jan 2002 20:52:57 +0100 (MET) X-Authentication-Warning: hamberg.it.uu.se: henrikl owned process doing -bs Date: Fri, 25 Jan 2002 20:52:57 +0100 (MET) From: Henrik Lundgren X-Sender: henrikl@hamberg.it.uu.se To: manet@itd.nrl.navy.mil Subject: New Ad-hoc test-bed software released! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by itd.nrl.navy.mil id OAA17176 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit APE test-bed v0.3 released today! --------------------------------- As there is an increasing need for more real-world experiments and evaluations of ad hoc routing protocols we are happy to officially announce the release our Ad hoc Protocol Evaluation test-bed (APE). Binary distribution and source code (GPL) can be downloaded from: http://apetestbed.sourceforge.net/ APE aims at making the process of real-world ad hoc routing experiments as simple as possible. It focuses on smooth deployment, customization and ability to easily repeat experiments with different protocols for comparison (including tools to assess the similarity between repeated testruns). Scenarios can be scripted and test-participants only need to follow on-screen movement instructions. APE includes several tools for performing post-test analysis of collected testrun data. APE consists of an encapsulated, pre-configured Linux execution environment (only 8M!). It can be easily installed on nodes running Linux or Windows (with DOS support): download, install and reboot into the testbed execution environment. This simple procedure is crucial when performing large tests and makes it easy to invite people to participate in testruns. APE can potentially be used for evaluation of any ad hoc protocol implemented under Linux. Currently, APE is prepared to support the following: - AODV-UU (Uppsala University - source included in APE) - MAD-HOC (KTH - source included in APE) - DSR (University of Queensland) - OLSR (Inria) - TORA (UMD) - LUNAR (Uppsala University - source included in APE) Other misc. useful things in APE includes: - A MAC-filter tool (mackill) to fake connectivity in scenarios. - TTCP for performance testing. - A simple MP3 streamer (mp3stream) for audible demos. - A graphical tool (APE-view) that can re-play a testrun's topological configurations over time (based on signal quality). A technical report about APE is available at http://www.it.uu.se/research/reports/2001-029/ (a version of this paper was accepted for publication at WCNC'02) Don't hesistate to send any comments, suggestions or possible problems you encounter to: apetestbed-support@lists.sourceforge.net Henrik Lundgren & Erik Nordström Department of Computer Systems, Uppsala University From owner-manet@itd.nrl.navy.mil Fri Jan 25 18:41:07 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18121 for ; Fri, 25 Jan 2002 18:41:07 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA21003 for manet-outgoing; Fri, 25 Jan 2002 16:32:29 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA20998 for ; Fri, 25 Jan 2002 16:32:25 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16UDxN-00023N-00 for ; Fri, 25 Jan 2002 22:32:21 +0100 Received: from i72pc238.tm.uni-karlsruhe.de ([141.3.70.72]) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16UDxJ-0002E9-00 for ; Fri, 25 Jan 2002 22:32:17 +0100 Received: from localhost (weniger@localhost) by i72pc238.tm.uni-karlsruhe.de (8.11.6/8.11.2) with ESMTP id g0PLWHA06629 for ; Fri, 25 Jan 2002 22:32:17 +0100 X-Authentication-Warning: i72pc238.tm.uni-karlsruhe.de: weniger owned process doing -bs Date: Fri, 25 Jan 2002 22:32:17 +0100 (CET) From: Kilian Weniger X-X-Sender: To: Subject: Re: Address Allocation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk We have a paper about IPv6 Stateless Address Autoconfiguration in large mobile ad hoc networks. In our approach, an hierarchical address space is build up and the flooding during the Duplicate Address Detection is limited. Therefore, we claim to achieve an improved scalability. Furthermore, unique addresses are also guaranteed in the case that two independently configured networks merge. You can download the paper at our IPonAir-project homepage: http://www.iponair.de/publications_en.shtml Kilian Weniger On Thu, 24 Jan 2002, Elizabeth M. Belding-Royer wrote: > > > > At 02:30 AM 1/23/2002, MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN wrote: > > >is anyone know the manner used by an Ad Hoc host to get an IP address ? is > > >there a differences betwwen a local area and a large nnetwork for the > > >allocation ? > > > > I don't see any draft that specifically addresses that. > > > > Our revised Internet Draft on address autoconfiguration > (revised for the last IETF) addresses this issue for both > IPv4 and IPv6 networks. The basic mechanism is that > a mobile node selects an address from some address space, > and then it must perform duplicate address detection to > ensure that address is not already claimed within the network. > > The draft name is draft-perkins-manet-autoconf-01.txt. > Its in the Internet Draft repository. > > Elizabeth > -- ---------------------------------------------------------------------------------------- Dipl.-Ing. Kilian Weniger phone: (+49)(0)721-608 6415 Institute of Telematics fax: (+49)(0)721-388097 Department of Computer Science email: weniger@tm.uni-karlsruhe.de University of Karlsruhe homepage: http://www.tm.uka.de/~weniger/ D-76128 Karlsruhe From owner-manet@itd.nrl.navy.mil Fri Jan 25 19:06:14 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18638 for ; Fri, 25 Jan 2002 19:06:13 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA22001 for manet-outgoing; Fri, 25 Jan 2002 17:07:27 -0500 (EST) Received: from ponyexpress.ee.columbia.edu (ponyexpress.ee.columbia.edu [128.59.64.61]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA21994 for ; Fri, 25 Jan 2002 17:07:24 -0500 (EST) Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.65.202]) by ponyexpress.ee.columbia.edu (8.11.3/8.11.3) with SMTP id g0PM7Nf31771; Fri, 25 Jan 2002 17:07:24 -0500 From: "Andrew T. Campbell" To: "Manet $E-mail$" Cc: "Andrew Campbell $E-mail$" Subject: FW: DIREN'02 Date: Fri, 25 Jan 2002 17:04:46 -0500 Message-ID: <00d401c1a5ec$4d7b36b0$ca413b80@SWEETPEA> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Aurel A. Lazar [mailto:aurel@ee.columbia.edu] > Sent: Friday, January 25, 2002 5:20 PM > To: mnl@comet.columbia.edu > Cc: Aurel A. Lazar (E-mail) > Subject: DIREN'02 > > > Call for Participation > > The First IEEE Workshop on Disaster Recovery Networks > invites your participation in this international > forum on innovative network technologies, architectures, and > services that can be effectively deployed during disaster > recovery. DIREN is sponsored (pending) by the IEEE Communications > Society and will be co-located and organized in conjunction with > INFOCOM. > > Please submit by March 15, 2002, a short statement about the > topics that you would like to discuss or would like to hear being > discussed to aurel@ee.columbia.edu or nick@ee.columbia.edu. > > The program of the workshop will be posted at > http://comet.columbia.edu/diren no later than April 15, 2002. > > Organizing and Program Committee > Victor S. Frost, University of Kansas > Aurel A. Lazar, Columbia University > Mary Maeda, DARPA > Nicholas F. Maxemchuk, Columbia University > > From owner-manet@itd.nrl.navy.mil Fri Jan 25 20:19:36 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19357 for ; Fri, 25 Jan 2002 20:19:36 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA24014 for manet-outgoing; Fri, 25 Jan 2002 18:29:03 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id SAA24009 for ; Fri, 25 Jan 2002 18:29:01 -0500 (EST) Message-Id: <5.0.1.4.2.20020125182737.076da8b8@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 25 Jan 2002 18:37:41 -0500 To: manet@itd.nrl.navy.mil From: Joe Macker Subject: AODV WG Last Call for Comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk ALL: This message is to announce a 2 week "WG Last-Call for comments" schedule on the recent updated AODV ID submittal. As discussed at the last meeting, the intent is to consider submitting this document for EXPERIMENTAL RFC. Because of some content changes since the last go around we felt an additional WG Last Call was warranted. The document is, more specifically, draft-ietf-manet-aodv-10.txt that was recently announced. Please note, this is not a general IESG Last-Call on these documents, which MAY occur at a later date if this document progresses for EXPERIMENTAL status consideration. Please read RFC2026 if you desire more clarification on EXPERIMENTAL RFC purpose and procedure. Regards, Joe and Scott From owner-manet@itd.nrl.navy.mil Fri Jan 25 20:31:40 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19510 for ; Fri, 25 Jan 2002 20:31:40 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA23849 for manet-outgoing; Fri, 25 Jan 2002 18:20:11 -0500 (EST) Received: from ece.ufl.edu (dot.ece.ufl.edu [128.227.220.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id SAA23844 for ; Fri, 25 Jan 2002 18:20:08 -0500 (EST) Received: (qmail 11457 invoked from network); 25 Jan 2002 23:18:10 -0000 Received: from fang.ece.ufl.edu (128.227.80.157) by dot.ece.ufl.edu with SMTP; 25 Jan 2002 23:18:10 -0000 Received: (from fang@localhost) by fang.ece.ufl.edu (8.9.3/8.9.3) id SAA05206; Fri, 25 Jan 2002 18:17:59 -0500 (EST) X-Authentication-Warning: fang.ece.ufl.edu: Processed from queue /home/faculty/fang/mqueue X-Authentication-Warning: fang.ece.ufl.edu: Processed by fang with -C /home/faculty/fang/bin/sendmail.cf Date: Fri, 25 Jan 2002 18:17:58 -0500 From: Yuguang Fang To: Yuguang Fang Subject: SCS SPECTS'2002 held in San Diego Message-ID: <20020125181758.A5187@ece.ufl.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 1.0pre4i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id SAA23845 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Dear Colleagues We apologize if you receive multiple copies. The deadline is approaching fast, which is next Thursday. You may want to spend the weekend to prepare your draft. Have a fun weekend :-) ---Michael %%%%%%%%%%%%%% Call For Papers 2002 International Symposium on Performance Evaluation of Computer and Telecommunication Systems SPECTS 2002 July 14-19, 2002 U. S. Grant Hotel San Diego, California, USA http://www.scs.org/confernc/spects02/ This annual international conference is a forum for professionals involved in performance evaluation of computer and telecommunication systems. Evaluation of computer systems and networks is needed at every stage in the life cycle of the product including design, manufacturing, sales/purchase, use, upgrade, tuning, etc. The discipline of performance evaluation has progressed rapidly in the past decade, and it has now begun to approach maturity. Significant progress has been made in analytic modeling, simulation, and measurement approaches for performance evaluation of computer and telecommunication systems. Topics of interest include, but are not limited to: Networking and Telecommunication Systems - Internet Technology - Quality of Service (QoS) - DiffServ/IntServ - TCP - Unicast and Multicast Routing - High-Speed Networking - ATM - Optical Networks - Switching Techniques - Teletraffic - Satellite Systems and Networks - Wireless Systems - UMTS/IMT-2000 - Mobile Networks/Computing - Multimedia Systems - Multimedia Communications - Adaptive Communications - Network Protocols - Network Management and Control - Network Capacity Planning - Network Architecture Evaluation - Service and QoS Pricing - Security and Authentication - World Wide Web (WWW) Technology - Electronic Commerce Computer Systems - Client/Server - Microprocessors/Microcomputers - Memory Systems - Interconnection Networks - Software Performance - Software Evaluation and Testing - Hardware and Software Monitors - High-Performance Computing - Workload and Traffic Characterization - Scientific Computing Algorithms - High Performance I/O - Reconfigurable Computing -Real-time Systems - Parallel and Distributed Computing - Distributed Systems and Agents - Massively Parallel Systems - Cluster Computing - Parallel Algorithms and Languages - Scheduling Schemes Tools, Methodologies and Applications - Parallel and Distributed Simulation - Verification and Validation - Performance Tools and Methodologies - Neural Networks and Fuzzy Logic Applications to High Performance Computing/Networking - Performance Optimization - Queueing Systems and Networks - Scalability Studies - Integrated Modeling and Measurement - On-Line Performance Adaptation and Tuning - Process Algebra-Based Models - Performance Bounds - Integrated Design and Performance - New Performance Models - Mathematical Aspects of Performance - New Performability Schemes and Models - Case Studies General Chair Mohammad S. Obaidat Dept. of Computer Science, Monmouth University W. Long Branch, NJ 07764, USA Tel +1-732-571-4482 Fax +1-732-263-5202 E-mail: obaidat@monmouth.edu Senior Program Chair Franco Davoli DIST-University of Genoa Via Opera Pia 13, I-16145 Genoa, Italy Tel +39-010-353-2732 Fax +39-010-353-2154 E-Mail: franco@dist.unige.it Program Co-Chairs Ibrahim Onyuksel Dept. of Computer Sciences, N. Illinois Univ., USA E-mail: onyuksel@cs.niu.edu Raffaele Bolla DIST-University of Genoa Via Opera Pia 13, I-16145 Genoa, Italy E-mail: lelus@dist.unige.it Vice Program Chair Erina Ferro CNUCE, Institute of National Research Council (C.N.R.) C.N.R. Pisa Research Area, Building B, Room 73 Via G. Moruzzi, 1 56124 Pisa, Italy E-mail: erina.ferro@cnuce.cnr.it Industrial Track Chair J. Fox, Motorola Inc., UK E-mail: fox.ijcs@btinternet.com Publicity Chair Yuguang (Michael) Fang, University of Florida, USA, E-mail: fang@ece.ufl.edu Web Master: Daniel Lee, University of Southern California, E-mail: dclee@rcf-fs.usc.edu Technical Program Committee Jagan P. Agrawal, University of Missouri - Kansas City, USA Ian Akyildiz, Georgia Tech., USA M. Atiquzzaman, University of Oklahoma, USA Harmen R. van As, Vienna University of Technology, Austria Louis G. Birta, University of Ottawa, Canada Noureddine Boudriga, University of Tunis, Tunisia Hasan Cam, Arizona State University, USA Andrew Campbell, Columbia University, USA Fabio M. Chiussi, Bell Laboratories, Lucent Technologies, USA Hassan B. Diab, American University of Beirut, Lebanon Gabor Fodor, Ericsson Radio Systems, Sweden John Fox, Motorola, UK Luigi Fratta, Politecnico di Milano, Italy Aura Ganz, University of Massachusetts, USA Erol Gelenbe, University of Central Florida, USA Mario Gerla, UCLA, USA Omar Hammami, ENSTA, France Jarmo Harju, Tampere University of Technology, Finland Herman Hughes, Michigan State University, USA Andrzej Jajszczyk, University of Mining and Metallurgy, Poland Ingemar Kaj, Uppsala University, Sweden Helen Karatza, Aristotle University of Thessalonica, Greece Demetrios Kazakos, University of Louisiana, USA Ulrich Killat, Tech Univ. of Hamburg, Germany Tag Gon Kim, KAIST, Korea Belka Kraimeche, Stevens Institute of Technology, USA Paul J. Kuehn, University of Stuttgart, Germany Kevin Kwiat, Air Force Research Laboratory, USA Veronica Lagrange M. Reis, Compaq Computers Corp., USA Axel Lehmann, Universität der Bundeswehr München, Germany Daniel C. Lee, USC, USA Mike T. Liu, Ohio State University, USA Imad Mahgoub, Florida Atlantic University, USA Sam Makki, Queensland University of Technology, Australia Krzysztof Malinowski, Warsaw Technical University, Poland Jose L. Marzo, Universitat de Girona, Spain Xiannong Meng, Bucknell University, USA Hussein Mouftah, Queen's University, Canada M. Ould-Khaoua, University of Glasgow, UK Sergio Palazzo, Università di Catania, Italy Georgios I. Papadimitriou, Aristotle University, Greece Achille Pattavina, Politecnico di Milano, Italy Krzysztof Pawlikowski, University of Canterbury, New Zealand Steven Pink, University of Arizona, USA George Polyzos, AUEB, Greece Ramon Puigjaner, Universitat de les Illes Balears, Spain Kaliappa Ravindran, CUNY, USA Gian Paolo Rossi, Università di Milano, Italy Izhak Rubin, UCLA, USA Donald Schilling, CUNY, USA Jens B. Schmitt, TU Darmstadt, Germany C. Tim Spracklen, Aberdeen University, UK Tatsuya Suda, UCI, USA Iwao Toda, Fujutsu Laboratories Ltd., Japan Phuoc Tran-Gia, University of Wuerzburg, Germany Kenneth S. Vastola, Rensselaer Polytechnic Institute, USA Manuel Villen-Altamirano, Telefonica, Spain Bernd E. Wolfinger, Hamburg University, Germany Michele Zorzi, Università di Ferrara, Italy International Liaisons B. Sadoun, Al-Balqa' Applied University, Jordan Bsadoun@go.com.jo M. Sawan, Montreal Poly, Canada Sawan@vlsi.polymtl.ca N. Tchamov, Tampere Univ. of Technology, Finland Nikolay@cs.tut.fi Publicity Committee: Hiedeki Tode, Osaka Univ., Japan, E-mail: Tode@ise.eng.osaka-u.ac.jp Nusseirat, Al-Isra University, Jordan, E-mail: anuseirat@firstnet.com.jo Paper Submission Submit your complete papers electronically to: http://scs.proceedingscentral.com/ All required instructions will be posted on this web site. Submissions should not exceed 25 double-spaced, 8.5x11 inch pages (including figures, tables, and references) in 10-12 point font. Include five to ten keywords, complete postal and e-mail addresses, and fax and phone numbers of corresponding author. If you have difficulty in electronic submission, contact the Web Master, Program Chairs or the Conference Coordinator, Mr. Steve Branch, The Society for Modeling and Simulation International, 4838 Ronson Court, Suite L, San Diego, CA 92111, USA, Tel 858-277-3888, Fax 858-277-3930, E-mail sbranch@scs.org sbranch@scs.org. Extended versions of accepted papers in SPECTS 2002 will be considered for possible publication in scholarly journals. Proposals for tutorials, special and panel sessions should be sent to the Conference Senior Program Chair. Proposals for industrial sessions should be submitted to the Industrial Track Chair. For more information regarding presentations or exhibitions at SPECTS 2002 contact: Mr. Steve Branch at the address shown above. Deadlines Submission of Papers: January 31, 2002 Notification of Acceptance - April 22, 2002 Final Camera-Ready Submission - May 22, 2002 Sponsored by The Society for Modeling and Simulation International. -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Yuguang "Michael" Fang, Ph.D Assistant Professor Department of Electrical and Computer Engineering University of Florida 435 Engineering Building, P.O.Box 116130 Gainesville, FL 32611 Tel: (352) 846-3043, Fax: (352) 392-0044 Email: fang@ece.ufl.edu, http://www.fang.ece.ufl.edu %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From owner-manet@itd.nrl.navy.mil Sat Jan 26 23:39:44 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16844 for ; Sat, 26 Jan 2002 23:39:44 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA06435 for manet-outgoing; Sat, 26 Jan 2002 20:54:09 -0500 (EST) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id UAA06430 for ; Sat, 26 Jan 2002 20:54:00 -0500 (EST) Received: from d1o848.telia.com (d1o848.telia.com [213.66.32.241]) by maile.telia.com (8.11.6/8.11.6) with ESMTP id g0R1s0s13799 for ; Sun, 27 Jan 2002 02:54:00 +0100 (CET) Received: from h127n2fls31o848.telia.com (h127n2fls31o848.telia.com [213.67.152.127]) by d1o848.telia.com (8.10.2/8.10.1) with ESMTP id g0R1rxA06229 for ; Sun, 27 Jan 2002 02:53:59 +0100 (CET) Subject: AODV and HELLO messages... From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: "manet@itd.nrl.navy.mil" Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0.1 Date: 27 Jan 2002 02:53:59 +0100 Message-Id: <1012096440.2620.70.camel@Replicator> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id UAA06431 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Hello I am trying to get a clear picture of how AODV should operate when using HELLO messages. Section 6.9 (Hello messages) says: "The route to the neighbor, if it exists, MUST subsequently contain the latest Destination Sequence Number from the Hello message." Does this mean that I always set the sequence number in the routing table entry for the neighbor equal to the one in the HELLO/RREP message? Even if the sequence number in the HELLO message is smaller than the one in the routing table? Also, if an entry already exists for the neighbor when receiving one of its hello messages, and that entry is a multi-hop route, should the route be updated/optimized to reflect that the neighbor now is directly reachable (hop count = 1)? Or is the HELLO message treated in the same manner as a RREP (since it is a RREP), and the routing table entry only updated if the HELLO message fulfill the same requirements as for a RREP? In any case, updating or "optimizing" the route upon reception of HELLO messages will make sure that a route is always the shortest possible. But I also see the following problems: * In the borderlines of where direct communication can be withheld, HELLO messages may go through sporadically. Then the route may go from 1 to 2 hops back and forth, so that communication with the destination can not be withheld. This could be counteracted by introducing a condition saying, for example, that 3 consecutive HELLOs should be received before the destination is considered being a neighbor. * If a long route is "optimized" at intermediate nodes, the end-points of the route may get invalid hop-counts (which do not reflect the true hop count). I guess this might also happen when doing local repairs... If the multi-hop routing table entry is _not_ updated upon reception of a HELLO message, AODV may suffer from non-optimal routes in the network. Also, any multi-hop routes to a destination which suddenly becomes a neighbor will not expire (or become a 1 hop route) when data is no longer sent on the route, as long as HELLO messages (or other AODV messages) are received. This is due to the fact that the draft says that a routing table entry's lifetime should always be updated upon receiving an AODV control message. Another issue: the last sentence in section 6.9 says... "Routes that are newly created from the reception of Hello messages might have empty precursor lists, and in that case would not trigger RERR messages when the neighbor moves away and the neighbor route expires." But what if there exists routes which use the expired route as next hop? Then a RERR should be sent in case those routes have non-empty precursor lists, even though the route created from the reception of Hello messages had an empty precursor list. Comments? /Erik Nordström, Uppsala University Sweden From owner-manet@itd.nrl.navy.mil Sun Jan 27 15:51:02 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03243 for ; Sun, 27 Jan 2002 15:51:02 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA12291 for manet-outgoing; Sun, 27 Jan 2002 13:46:54 -0500 (EST) Received: from secure.webhotel.net (secure.webhotel.net [195.41.202.80]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id NAA12286 for ; Sun, 27 Jan 2002 13:46:50 -0500 (EST) Message-Id: <200201271846.NAA12286@itd.nrl.navy.mil> Received: (qmail 28561669 invoked from network); 27 Jan 2002 18:50:22 -0000 Received: from unknown (HELO there) (80.62.94.58) by mail.webhotel.net with SMTP; 27 Jan 2002 18:50:22 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Per Olesen Organization: Nordija A/S To: MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN Subject: Re: performance comparaison between Ad Hoc routing protocols Date: Sun, 27 Jan 2002 19:46:46 +0000 X-Mailer: KMail [version 1.3.1] References: <0489A7888F080B4BA73B53F7E145F29A022C9D@LANMHS20.rd.francetelecom.fr> In-Reply-To: <0489A7888F080B4BA73B53F7E145F29A022C9D@LANMHS20.rd.francetelecom.fr> Cc: manet@itd.nrl.navy.mil MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Hi, > is there any new studies wich made a comparaison between all routing > protocols (espicially AODV and OLSR) . I know of one such study, performed by some students at Aalborg University, Denmark. Have a look at: http://www.cs.auc.dk/library/files/rapbibfiles1/995622889.ps Regards, Per Olesen From owner-manet@itd.nrl.navy.mil Mon Jan 28 11:10:21 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00926 for ; Mon, 28 Jan 2002 11:10:21 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA22349 for manet-outgoing; Mon, 28 Jan 2002 08:49:05 -0500 (EST) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA22343; Mon, 28 Jan 2002 08:49:02 -0500 (EST) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DP47K0T7; Mon, 28 Jan 2002 08:48:30 -0500 Message-ID: <007e01c1a802$781a3930$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , "Joe Macker" References: <5.0.1.4.2.20020125182737.076da8b8@pop.itd.nrl.navy.mil> Subject: Re: AODV WG Last Call for Comments Date: Mon, 28 Jan 2002 08:48:30 -0500 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I quote from RFC 2026 as to what "experimental" RFC are supposed to be in the IETF. 4.2 Specifications that are not on the standards track are labeled with one of three "off-track" maturity levels: "Experimental", "Informational", or "Historic". The documents bearing these labels are not Internet Standards in any sense. 4.2.1 Experimental The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see below). An Experimental specification may be the output of an organized Internet research effort (e.g., a Research Group of the IRTF), an IETF Working Group, or it may be an individual contribution. From section 3.3 (d) Limited Use: The TS is considered to be appropriate for use only in limited or unique circumstances. For example, the usage of a protocol with the "Experimental" designation should generally be limited to those actively involved with the experiment. Has someone defined the "experiment"? When will the "experiment" be completed? When will be AODV be reconsidered for "standards track"? Thanks, Phil Neumiller From owner-manet@itd.nrl.navy.mil Tue Jan 29 00:54:21 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18262 for ; Tue, 29 Jan 2002 00:54:21 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id WAA20028 for manet-outgoing; Mon, 28 Jan 2002 22:42:45 -0500 (EST) Received: from mail.ececs.uc.edu (mail.ececs.uc.edu [129.137.4.130]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id WAA20023 for ; Mon, 28 Jan 2002 22:42:42 -0500 (EST) Received: from capricorn.rhod.uc.edu (capricorn.rhod.uc.edu [10.63.7.84]) by mail.ececs.uc.edu (8.12.1/8.12.1) with ESMTP id g0T3gVRJ010685 for ; Mon, 28 Jan 2002 22:42:31 -0500 (EST) Received: from localhost (luyy@localhost) by capricorn.rhod.uc.edu (8.9.3/8.9.1) with ESMTP id WAA01379 for ; Mon, 28 Jan 2002 22:42:31 -0500 X-Authentication-Warning: capricorn.rhod.uc.edu: luyy owned process doing -bs Date: Mon, 28 Jan 2002 22:42:26 -0500 (EST) From: Yi Lv X-Sender: luyy@capricorn.rhod.uc.edu To: manet@itd.nrl.navy.mil Subject: Shadowing in network simulator Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Dear All: I am wondering if there's some network simulator that includes the shadowing in the propagation model. As i know, GloMoSim, ns-2 and OPNET all do not inlcude shadowing, while they have added or are going to add multipath fading. Is that because shadowing is not an main factor in ad-hoc network environment? Or is it hard to simulate? Thanks a lot! BR/Yi Lu From owner-manet@itd.nrl.navy.mil Tue Jan 29 08:05:01 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01989 for ; Tue, 29 Jan 2002 08:05:01 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA24718 for manet-outgoing; Tue, 29 Jan 2002 05:49:55 -0500 (EST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id FAA24709 for ; Tue, 29 Jan 2002 05:49:51 -0500 (EST) Received: from impression.inria.fr (impression.inria.fr [128.93.17.98]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g0TAnkn03947; Tue, 29 Jan 2002 11:49:46 +0100 (MET) Received: by impression.inria.fr (sSMTP sendmail emulation); Tue, 29 Jan 2002 11:49:46 +0100 From: Laurent Viennot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.32330.245417.347999@impression.inria.fr> Date: Tue, 29 Jan 2002 11:49:46 +0100 To: ogier@erg.sri.com Cc: Fred Baker , manet@itd.nrl.navy.mil Subject: Re: Manet flooding / broadcasting.... In-Reply-To: <200201251923.LAA03021@pit.erg.sri.com> References: <4.3.2.7.2.20020125080734.01de5398@mira-sjcm-2.cisco.com> <200201251923.LAA03021@pit.erg.sri.com> X-Mailer: VM 6.92 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-To: Laurent.Viennot@inria.fr Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Dear Richard, I agree that OLSR is an optimized adaptation of OSPF. But I don't follow your claim about reporting neighbors in TBRPF: > - In OSPF, each HELLO contains the ID of every neighbor, whereas > TBRPF uses much smaller differential HELLOs, which report only > *changes* in neighbor states. As I understand your draft, all neighbors are advertised regularly in every periodic topology update message (every PER_UPDATE_INTERVAL). Indeed I had a hard time for figuring that out from your pseudo-code. No matter whether you advertise the full list of neighbors in HELLOs or in TOPOLOGY UPDATES, the overhead is there. What is the right period for advertising this list is a tuning issue. laurent ogier@erg.sri.com writes: > > At 05:27 AM 1/25/2002, Philippe Jacquet wrote: > > >I agree. OSPF uses the LSA sequence number for this. By the way the > > >flooding of OSPF is fairly heavy since it requires ack from neighbors. > > > > true, but I will argue that this is only half the story. OSPF will only use > > broadcast on an interface that supports a designated router. Hence, it not > > only acknowledges on a point to point basis, it forwards the information > > (in a manet, where a designated router election is problematic) on a point > > to point basis. > > I would say this is much less than half the story, since there > are other factors that make TBRPF and OLSR more efficient than OSPF > in MANETs: > > - OSPF uses classical flooding to disseminate LSA's, > (except on interfaces that support designated routers), > whereas TBRPF and OLSR use more efficient mechanisms (based on > parents and MPRs) for propagating topology information. > (Actually, one could say that these efficient mechanisms are > analogous to designated routers, which as you say are problematic > for MANETs.) > > - OSPF is a full-topology protocol, i.e., every node within a given > area is provided with the entire topology of the area, whereas > TBRPF and OLSR provide each node with only a small part > of the topology, sufficient to compute shortest paths. > > - In OSPF, each HELLO contains the ID of every neighbor, whereas > TBRPF uses much smaller differential HELLOs, which report only > *changes* in neighbor states. > > There are other differences (such as the fact that TBRPF does not require > sequence numbers for topology updates), but I think but these are the main > advantages over OSPF. > > Regards, > Richard > From owner-manet@itd.nrl.navy.mil Tue Jan 29 12:14:50 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09807 for ; Tue, 29 Jan 2002 12:14:49 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA00705 for manet-outgoing; Tue, 29 Jan 2002 09:43:43 -0500 (EST) Received: from mail.ececs.uc.edu (mail.ececs.uc.edu [129.137.4.130]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA00692 for ; Tue, 29 Jan 2002 09:43:35 -0500 (EST) Received: from capricorn.rhod.uc.edu (capricorn.rhod.uc.edu [10.63.7.84]) by mail.ececs.uc.edu (8.12.1/8.12.1) with ESMTP id g0TEhNRJ003934; Tue, 29 Jan 2002 09:43:23 -0500 (EST) Received: from localhost (luyy@localhost) by capricorn.rhod.uc.edu (8.9.3/8.9.1) with ESMTP id JAA01967; Tue, 29 Jan 2002 09:43:23 -0500 X-Authentication-Warning: capricorn.rhod.uc.edu: luyy owned process doing -bs Date: Tue, 29 Jan 2002 09:43:23 -0500 (EST) From: Yi Lv X-Sender: luyy@capricorn.rhod.uc.edu To: rayw@stanford.edu cc: manet@itd.nrl.navy.mil Subject: Re: Shadowing in network simulator In-Reply-To: <20020129071636.48100.qmail@web13609.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk On Mon, 28 Jan 2002, Raymond Wang wrote: Hi, Ray: Thanks for your reply! Actually, i didn't really get into the simulators GloMoSim and OPNET, but i did see through the code of ns-2 and didn't find anything regarding lognormal shadowing. The version i read was ns 2.1b4a and cmu extension 1.1.2, could you please designate the version that added the shadowing, if any? Thanks a lot! Yi Lu > Hi Yi, > > Not sure where you got that info, but as far as I > know, GloMoSim/Qualnet, ns-2, and OPNET all support > lognormal shadowing, aka "large-scale" fading which is > usually on the order of distances of ~100 m. For most > of the foreseeable applications of ad hoc networks, > lognormal shadowing will be much less of a factor than > path loss and multipath, or "small-scale", fading > since these applications will generally be on a small > scale (i.e. <= 100 m) or, in many military apps, in an > environment where there is little to no shadowing. > > Ray > > --- Yi Lv wrote: > > Dear All: > > > > I am wondering if there's some network simulator > > that includes the > > shadowing in the propagation model. As i know, > > GloMoSim, ns-2 and OPNET > > all do not inlcude shadowing, while they have added > > or are going to add > > multipath fading. Is that because shadowing is not > > an main factor in > > ad-hoc network environment? Or is it hard to > > simulate? > > > > Thanks a lot! > > BR/Yi Lu > > > > > > > __________________________________________________ > Do You Yahoo!? > Great stuff seeking new owners in Yahoo! Auctions! > http://auctions.yahoo.com > From owner-manet@itd.nrl.navy.mil Tue Jan 29 12:14:51 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09806 for ; Tue, 29 Jan 2002 12:14:49 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA00980 for manet-outgoing; Tue, 29 Jan 2002 09:49:43 -0500 (EST) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA00969 for ; Tue, 29 Jan 2002 09:49:40 -0500 (EST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g0TEne800076; Tue, 29 Jan 2002 09:49:40 -0500 (EST) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g0TEnck02882; Tue, 29 Jan 2002 09:49:38 -0500 (EST) Received: from mitre.org (b-144-28.mitre.org [129.83.144.28]) by linus.mitre.org (8.9.3/8.9.3) with ESMTP id JAA26069; Tue, 29 Jan 2002 09:49:38 -0500 (EST) Message-ID: <3C56B62D.9000700@mitre.org> Date: Tue, 29 Jan 2002 09:48:13 -0500 From: "David R. Gervais" Organization: MITRE Corporation User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: Yi Lv CC: manet@itd.nrl.navy.mil Subject: Re: Shadowing in network simulator References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Yi, QualNet does...at least they say they do. Apparently, they are releasing an update in February. http://www.qualnet.com/products/QualNet/mobilitymodels.html -Dave Yi Lv wrote: > Dear All: > > I am wondering if there's some network simulator that includes the > shadowing in the propagation model. As i know, GloMoSim, ns-2 and OPNET > all do not inlcude shadowing, while they have added or are going to add > multipath fading. Is that because shadowing is not an main factor in > ad-hoc network environment? Or is it hard to simulate? > > Thanks a lot! > BR/Yi Lu > > > > -- +++--- David Gervais Communications Engineer MITRE Corporation Email: dgervais@mitre.org Phone: (781) 271-2807 From owner-manet@itd.nrl.navy.mil Tue Jan 29 13:35:21 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12948 for ; Tue, 29 Jan 2002 13:35:20 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA04540 for manet-outgoing; Tue, 29 Jan 2002 11:05:48 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA04528; Tue, 29 Jan 2002 11:05:43 -0500 (EST) Message-Id: <5.0.1.4.2.20020129103524.01b13fd0@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 29 Jan 2002 11:14:38 -0500 To: Yi Lv , manet@itd.nrl.navy.mil From: Joe Macker Subject: Re: Shadowing in network simulator In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 10:42 PM 1/28/2002 -0500, Yi Lv wrote: >Dear All: > >I am wondering if there's some network simulator that includes the >shadowing in the propagation model. As i know, GloMoSim, ns-2 and OPNET >all do not inlcude shadowing, while they have added or are going to add >multipath fading. Is that because shadowing is not an main factor in >ad-hoc network environment? Or is it hard to simulate? Yi: I just doublechecked and a shadowing model exists in recent ns2 release, in addition to the add-on multipath models. Shadowing is an important factor, how important it is would depend on the scenario (e.g., intrabuilding) and transmission parameters being modeled (its physics dependent). >Thanks a lot! >BR/Yi Lu From owner-manet@itd.nrl.navy.mil Tue Jan 29 14:49:34 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19047 for ; Tue, 29 Jan 2002 14:49:33 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA09191 for manet-outgoing; Tue, 29 Jan 2002 12:41:51 -0500 (EST) Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.64.14.23]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA09180 for ; Tue, 29 Jan 2002 12:41:44 -0500 (EST) Received: from raw.stanford.edu (raw.Stanford.EDU [128.12.174.44]) by smtp1.Stanford.EDU (8.11.6/8.11.6) with ESMTP id g0THff812928; Tue, 29 Jan 2002 09:41:42 -0800 (PST) Message-Id: <5.1.0.14.0.20020129093644.03663248@pop.mail.yahoo.com> X-Sender: rayw_94305@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Jan 2002 09:41:58 -0800 To: Yi Lv , manet@itd.nrl.navy.mil From: Raymond Wang Subject: Re: Shadowing in network simulator In-Reply-To: References: <20020129071636.48100.qmail@web13609.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Yi, I am using ns-2.1b8a which comes with shadowing support. To answer your question below whether it is hard to simulate, it's pretty simple to simulate large-scale fading for any packet-level simulator. The real challenge is trying to simulate bit-level effects like small-scale fading. Ray At 09:43 AM 1/29/2002 -0500, you wrote: >On Mon, 28 Jan 2002, Raymond Wang wrote: >Hi, Ray: > >Thanks for your reply! >Actually, i didn't really get into the simulators GloMoSim and OPNET, but >i did see through the code of ns-2 and didn't find anything regarding >lognormal shadowing. The version i read was ns 2.1b4a and cmu extension >1.1.2, could you please designate the version that added the shadowing, if >any? > >Thanks a lot! >Yi Lu > > > > Hi Yi, > > > > Not sure where you got that info, but as far as I > > know, GloMoSim/Qualnet, ns-2, and OPNET all support > > lognormal shadowing, aka "large-scale" fading which is > > usually on the order of distances of ~100 m. For most > > of the foreseeable applications of ad hoc networks, > > lognormal shadowing will be much less of a factor than > > path loss and multipath, or "small-scale", fading > > since these applications will generally be on a small > > scale (i.e. <= 100 m) or, in many military apps, in an > > environment where there is little to no shadowing. > > > > Ray > > > > --- Yi Lv wrote: > > > Dear All: > > > > > > I am wondering if there's some network simulator > > > that includes the > > > shadowing in the propagation model. As i know, > > > GloMoSim, ns-2 and OPNET > > > all do not inlcude shadowing, while they have added > > > or are going to add > > > multipath fading. Is that because shadowing is not > > > an main factor in > > > ad-hoc network environment? Or is it hard to > > > simulate? > > > > > > Thanks a lot! > > > BR/Yi Lu > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Great stuff seeking new owners in Yahoo! Auctions! > > http://auctions.yahoo.com > > From owner-manet@itd.nrl.navy.mil Tue Jan 29 16:42:40 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21744 for ; Tue, 29 Jan 2002 16:42:39 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA14082 for manet-outgoing; Tue, 29 Jan 2002 14:33:19 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA14077; Tue, 29 Jan 2002 14:32:55 -0500 (EST) Message-Id: <5.0.1.4.2.20020129144004.02d8c9d8@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 29 Jan 2002 14:41:51 -0500 To: Yi Lv From: Joe Macker Subject: Re: Shadowing in network simulator Cc: manet@itd.nrl.navy.mil In-Reply-To: References: <20020129071636.48100.qmail@web13609.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk I found it in 2.1b7a so more recent releases should also have it. At 09:43 AM 1/29/2002 -0500, you wrote: >On Mon, 28 Jan 2002, Raymond Wang wrote: >Hi, Ray: > >Thanks for your reply! >Actually, i didn't really get into the simulators GloMoSim and OPNET, but >i did see through the code of ns-2 and didn't find anything regarding >lognormal shadowing. The version i read was ns 2.1b4a and cmu extension >1.1.2, could you please designate the version that added the shadowing, if >any? > >Thanks a lot! >Yi Lu From owner-manet@itd.nrl.navy.mil Tue Jan 29 16:50:27 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21905 for ; Tue, 29 Jan 2002 16:50:27 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA15086 for manet-outgoing; Tue, 29 Jan 2002 14:59:28 -0500 (EST) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA15081 for ; Tue, 29 Jan 2002 14:59:25 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id LAA13094; Tue, 29 Jan 2002 11:58:29 -0800 (PST) Message-Id: <200201291958.LAA13094@pit.erg.sri.com> To: manet@itd.nrl.navy.mil cc: ogier@erg.sri.com Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: Manet flooding / broadcasting.... In-reply-to: Your message of "Tue, 29 Jan 2002 11:49:46 +0100." <15446.32330.245417.347999@impression.inria.fr> Date: Tue, 29 Jan 2002 11:58:29 -0800 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Laurent, > Dear Richard, > > I agree that OLSR is an optimized adaptation of OSPF. But I don't follow > your claim about reporting neighbors in TBRPF: > > > - In OSPF, each HELLO contains the ID of every neighbor, whereas > > TBRPF uses much smaller differential HELLOs, which report only > > *changes* in neighbor states. > > As I understand your draft, all neighbors are advertised regularly in > every periodic topology update message (every > PER_UPDATE_INTERVAL). Indeed I had a hard time for figuring that out > from your pseudo-code. > > No matter whether you advertise the full list of neighbors in HELLOs > or in TOPOLOGY UPDATES, the overhead is there. What is the right > period for advertising this list is a tuning issue. > > laurent The main tuning issue regarding HELLOs (whether you are talking about TBRPF, OLSR, or OSPF) is that if HELLOs are sent more frequently, then the detection of link failures/breakages can be done more quickly. Thus it would be good to send HELLOs more frequently (e.g., every 0.5 sec) if nodes are moving fast. Since HELLOs are differential in TBRPF, this can be done with a relatively small increase in overhead. However, in OSPF and OLSR, since each HELLO contains all neighbor IDs, this would increase overhead a lot if each node has a large number of neighbors. In TBRPF, each node reports links to all neighbors in periodic topology updates, which are sent less frequently than HELLOs, just as periodic TC messages are sent less frequently than HELLOs in OLSR. For example, in a network with very fast moving nodes, HELLOs might be sent every 0.5 second while periodic topology updates are sent every 5 seconds. Therefore, TBRPF saves a lot of overhead by reporting links to neighbors less frequently. (In OLSR, each node needs to advertise its neighbor set more frequently because this information is needed to select MPRs.) Another advantage of reporting links to neighbors in topology updates instead of HELLOs is that (unlike OLSR) neighbor sensing performs ONLY neighbor sensing. Thus, in TBRPF, neighbor sensing is completely modular and separate from topology discovery. In OLSR, each node reports its links to all neighbors (and also its MPRs) in HELLOs. Note that OSPF also uses HELLOs only for neighbor sensing (even though the HELLOs are not differential). I really think this is a better approach. A related issue is that TBRPF also uses differential topology updates (unlike OLSR) so that a link failure (e.g., detected through link-layer notification) can be quickly reported with minimal overhead to all nodes that are affected by the failure. I noticed that OLSR allows triggered TC messages to be sent in response to link-layer notification. Since these are full (not differential) TC messages, I would expect that this will create a lot of additional control traffic if link-layer notification is used in highly mobile networks with a large number of streams. However, the simulation study posted a few days (comparing OLSR to AODV) does not use link-layer notification (resulting in a packet delivery fraction that is often less than 50%), and the ns-2 code for OLSR available from the INRIA site does not provide link-layer notification (as does the available AODV code and the available TBRPF code at www.erg.sri.com/projects/tbrpf). I think it is important to conduct simulations that use link-layer notification for the following reasons: 1. It is the only way to achieve a packet delivery fraction close to 100% without end-to-end retransmission (which is not acceptable for real-time traffic such as voice). 2. Link-layer notification is usually available on commercially available 802.11 cards (e.g., Cisco Aironet). Regards, Richard From owner-manet@itd.nrl.navy.mil Tue Jan 29 18:44:58 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24657 for ; Tue, 29 Jan 2002 18:44:57 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA19259 for manet-outgoing; Tue, 29 Jan 2002 16:48:20 -0500 (EST) Received: from ece.rice.edu (ece.rice.edu [128.42.4.34]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA19254 for ; Tue, 29 Jan 2002 16:48:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ece.rice.edu (Postfix) with ESMTP id E4FC468A6B for ; Tue, 29 Jan 2002 15:48:12 -0600 (CST) Received: from egress.ece.rice.edu (egress.ece.rice.edu [128.42.12.74]) by ece.rice.edu (Postfix) with ESMTP id 8D31C68A5C for ; Tue, 29 Jan 2002 15:48:11 -0600 (CST) Received: from localhost (kanodia@localhost) by egress.ece.rice.edu (8.9.3/8.9.3) with ESMTP id PAA15150 for ; Tue, 29 Jan 2002 15:48:11 -0600 X-Authentication-Warning: egress.ece.rice.edu: kanodia owned process doing -bs Date: Tue, 29 Jan 2002 15:48:11 -0600 (CST) From: Vikram Kanodia X-Sender: kanodia@egress.ece.rice.edu To: manet@itd.nrl.navy.mil Subject: Multirate and 802.11 In-Reply-To: <4.3.2.7.2.20020125080734.01de5398@mira-sjcm-2.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS snapshot-20010714 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, I had a couple of questions about multirate support of IEEE 802.11. I will be gratefuil if someone can provide pointers etc... (*) I know that the PHY preamble and headers are all sent at a basic rate (1Mbps?). Is the RTS/CTS exchange also done at the basic rate ? (*)....if not then how do other overhearing nodes latch onto the RTS/CTS.. ? Thanks, -Vikram -- Department of ECE, Rice University | 713 348 3786 (O)| 713 664 5650(H) WWW: http://www.ece.rice.edu/~kanodia From owner-manet@itd.nrl.navy.mil Tue Jan 29 18:52:35 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24777 for ; Tue, 29 Jan 2002 18:52:34 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA19312 for manet-outgoing; Tue, 29 Jan 2002 16:50:41 -0500 (EST) Received: from ece.rice.edu (ece.rice.edu [128.42.4.34]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA19307 for ; Tue, 29 Jan 2002 16:50:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ece.rice.edu (Postfix) with ESMTP id 7C41268A68 for ; Tue, 29 Jan 2002 15:50:38 -0600 (CST) Received: from egress.ece.rice.edu (egress.ece.rice.edu [128.42.12.74]) by ece.rice.edu (Postfix) with ESMTP id CE13C68A5C for ; Tue, 29 Jan 2002 15:50:37 -0600 (CST) Received: from localhost (kanodia@localhost) by egress.ece.rice.edu (8.9.3/8.9.3) with ESMTP id PAA15736 for ; Tue, 29 Jan 2002 15:50:37 -0600 X-Authentication-Warning: egress.ece.rice.edu: kanodia owned process doing -bs Date: Tue, 29 Jan 2002 15:50:37 -0600 (CST) From: Vikram Kanodia X-Sender: kanodia@egress.ece.rice.edu Cc: manet@itd.nrl.navy.mil Subject: Re: Shadowing in network simulator In-Reply-To: <5.0.1.4.2.20020129103524.01b13fd0@pop.itd.nrl.navy.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS snapshot-20010714 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk On a similar note....does anyone know (or has!!) how to implement multirate support for IEEE 802.11 in ns....??? -Vikram > At 10:42 PM 1/28/2002 -0500, Yi Lv wrote: > >Dear All: > > > >I am wondering if there's some network simulator that includes the > >shadowing in the propagation model. As i know, GloMoSim, ns-2 and OPNET > >all do not inlcude shadowing, while they have added or are going to add > >multipath fading. Is that because shadowing is not an main factor in > >ad-hoc network environment? Or is it hard to simulate? > Yi: > > I just doublechecked and a shadowing model exists in recent ns2 release, in addition to the add-on multipath models. Shadowing is an important factor, how important it is would depend on the scenario (e.g., intrabuilding) and transmission parameters being modeled (its physics dependent). > > > > >Thanks a lot! > >BR/Yi Lu > > > -- Department of ECE, Rice University | 713 348 3786 (O)| 713 664 5650(H) WWW: http://www.ece.rice.edu/~kanodia From owner-manet@itd.nrl.navy.mil Tue Jan 29 18:53:33 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24806 for ; Tue, 29 Jan 2002 18:53:33 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA19896 for manet-outgoing; Tue, 29 Jan 2002 17:08:32 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA19882 for ; Tue, 29 Jan 2002 17:08:29 -0500 (EST) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 17:08:26 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE46993F38@ftmail> From: Scott Corson To: "'T.Clausen@computer.org'" , manet@itd.nrl.navy.mil Subject: RE: Manet flooding / broadcasting.... Date: Tue, 29 Jan 2002 17:08:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > > However, speaking in terms of applications requirements, it > seems to me > that the analogy of a manet on equal terms as an "Ethernet" > may be more > appropriate, I think it really depends on the applications and the context. For small stub networks this may be a reasonable view. But generally I think the analogy of viewing a manet as an Ethernet is flawed. I think that by default a limited broadcast should not extend beyond reach of nodes receiving the broadcast, and routers should not rebroadcast, generally in keeping with RFC1812. An application wishing to create an Ethernet-like behaviour out of a manet may utilize the manet flooding service we've been discussing. It could encapsulate data for flooding, and at each step in the flooding process the receiving routers could receive and optionally process/drop the decapsulated packets in addition to continuing with the flooding behavior. So...if the WG is content to observe 1812 in this fashion, and implement the flooding behavior over top in a variety of fashions (up to protocol designers), I think we are heading towards agreement on the basics of a service definition. -Scott From owner-manet@itd.nrl.navy.mil Tue Jan 29 22:19:18 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28677 for ; Tue, 29 Jan 2002 22:19:16 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA24239 for manet-outgoing; Tue, 29 Jan 2002 20:07:01 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id UAA24234 for ; Tue, 29 Jan 2002 20:06:58 -0500 (EST) Message-Id: <5.0.1.4.2.20020129185253.031d1c10@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 29 Jan 2002 20:15:19 -0500 To: manet@itd.nrl.navy.mil From: Joe Macker Subject: Some follow-up OLSR/AODV results In-Reply-To: <200201291958.LAA13094@pit.erg.sri.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Richard/All: I ran some example OLSR performance curves vs. AODV to check against findings recently presented at the Salt Lake IETF. I used the same scenarios and cmu tools and was most interested initially in the static topology results since my early OLSR results were very different from those presented. I posted one OLSR /AODV example output at http://protean.itd.nrl.navy.mil/manet/olsrstatic.pdf I also used fixed scales to plot since I believe autoscaling plots can overexaggerate the difference s in performance between protocols In the 100 node case, Ogier's results have OLSR never obtaining more than 65% packet delivery or so. My results show it achieving close to 100% packet delivery for the lower loading case and retaining reasonable performance as loading increases (it even beat the AODV model with link layer notification in this static example)...yes mobility is more interesting and OLSR degrades, but I am here trying to independently reproduce snapshots of the experiments you presented. Richard, I feel some of protocol points being raised are valid but I did want to present some results I obtained from running some trials that don't seem to match up with IETF presented results. I will try and produce some additional mobility curves and post them as well, my initial mobility results for OLSR (Aalborg) also look much better than you presented at the last meeting...(I know I mentioned alot about potential porting problems with jitter, event handlers,etc in the linux based source code you were working with)...not sure any of the differences could be caused by configuration or implementation issues but there must be some differences. In addition, we have almost completed some other work that is independently developing an OLSR ns2 implementation with optional link layer notification and faster localized MPR state repairing. This work was being done prior to recent discussions, but I thought I'd mention it since people are discussing it. -joe At 11:58 AM 1/29/2002 -0800, ogier@erg.sri.com wrote: >I noticed that OLSR allows triggered TC messages to be sent in response >to link-layer notification. Since these are full (not differential) >TC messages, I would expect that this will create a lot of additional >control traffic if link-layer notification is used in highly mobile >networks with a large number of streams. However, the simulation >study posted a few days (comparing OLSR to AODV) does not use link-layer >notification (resulting in a packet delivery fraction that is often >less than 50%), and the ns-2 code for OLSR available from the INRIA >site does not provide link-layer notification (as does the available >AODV code and the available TBRPF code at www.erg.sri.com/projects/tbrpf). > >I think it is important to conduct simulations that use link-layer >notification for the following reasons: > > 1. It is the only way to achieve a packet delivery fraction close > to 100% without end-to-end retransmission (which is not acceptable > for real-time traffic such as voice). > > 2. Link-layer notification is usually available on commercially > available 802.11 cards (e.g., Cisco Aironet). > >Regards, >Richard From owner-manet@itd.nrl.navy.mil Tue Jan 29 23:13:34 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00596 for ; Tue, 29 Jan 2002 23:13:33 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id VAA25558 for manet-outgoing; Tue, 29 Jan 2002 21:13:40 -0500 (EST) Received: from mail.ececs.uc.edu (mail.ececs.uc.edu [129.137.4.130]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id VAA25553 for ; Tue, 29 Jan 2002 21:13:37 -0500 (EST) Received: from capricorn.rhod.uc.edu (capricorn.rhod.uc.edu [10.63.7.84]) by mail.ececs.uc.edu (8.12.1/8.12.1) with ESMTP id g0U2BfRJ017484; Tue, 29 Jan 2002 21:11:41 -0500 (EST) Received: from localhost (luyy@localhost) by capricorn.rhod.uc.edu (8.9.3/8.9.1) with ESMTP id VAA02261; Tue, 29 Jan 2002 21:11:40 -0500 X-Authentication-Warning: capricorn.rhod.uc.edu: luyy owned process doing -bs Date: Tue, 29 Jan 2002 21:11:40 -0500 (EST) From: Yi Lv X-Sender: luyy@capricorn.rhod.uc.edu To: Raymond Wang cc: manet@itd.nrl.navy.mil Subject: Re: Shadowing in network simulator In-Reply-To: <5.1.0.14.0.20020129093644.03663248@pop.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk On Tue, 29 Jan 2002, Raymond Wang wrote: Hi, Ray: I just checked the ns-2.1b8a. Thanks! Here are some more questions. 1. Shadowing was modulated in the free space path loss, rather than a combination of free space path loss or two-ray ground path loss, with a breaking-point distance d0, which was implemented in class TwoRayGround without shadowing. Why changing the path loss model in the case of shadowing? 2. As we know, shadowing is caused by large obstructions such as buildings and hills. Is that reasonable only adding a random variable with log-normal distribution, while not taking the terrain infomation into account? In other words, seems that there's no such information in the scenario, right? 3. Still not see any multipath fading model in this version, does anybody have idea about how important it is for the performance of upper layer protocol? 4. I am a new comer in the simulation, and i am wondering if there's some report that indicated how the result of simulation fits the real case, if there's some real product that has been taken field test, so that i could get more confidence doing that, since there are so many issues which might seem not realistic. Thanks a lot! BR/yi lu > Yi, > > I am using ns-2.1b8a which comes with shadowing support. To answer your > question below whether it is hard to simulate, it's pretty simple to > simulate large-scale fading for any packet-level simulator. The real > challenge is trying to simulate bit-level effects like small-scale fading. > > Ray > > At 09:43 AM 1/29/2002 -0500, you wrote: > >On Mon, 28 Jan 2002, Raymond Wang wrote: > >Hi, Ray: > > > >Thanks for your reply! > >Actually, i didn't really get into the simulators GloMoSim and OPNET, but > >i did see through the code of ns-2 and didn't find anything regarding > >lognormal shadowing. The version i read was ns 2.1b4a and cmu extension > >1.1.2, could you please designate the version that added the shadowing, if > >any? > > > >Thanks a lot! > >Yi Lu > > > > > > > Hi Yi, > > > > > > Not sure where you got that info, but as far as I > > > know, GloMoSim/Qualnet, ns-2, and OPNET all support > > > lognormal shadowing, aka "large-scale" fading which is > > > usually on the order of distances of ~100 m. For most > > > of the foreseeable applications of ad hoc networks, > > > lognormal shadowing will be much less of a factor than > > > path loss and multipath, or "small-scale", fading > > > since these applications will generally be on a small > > > scale (i.e. <= 100 m) or, in many military apps, in an > > > environment where there is little to no shadowing. > > > > > > Ray > > > > > > --- Yi Lv wrote: > > > > Dear All: > > > > > > > > I am wondering if there's some network simulator > > > > that includes the > > > > shadowing in the propagation model. As i know, > > > > GloMoSim, ns-2 and OPNET > > > > all do not inlcude shadowing, while they have added > > > > or are going to add > > > > multipath fading. Is that because shadowing is not > > > > an main factor in > > > > ad-hoc network environment? Or is it hard to > > > > simulate? > > > > > > > > Thanks a lot! > > > > BR/Yi Lu > > > > > > > > > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Great stuff seeking new owners in Yahoo! Auctions! > > > http://auctions.yahoo.com > > > > From owner-manet@itd.nrl.navy.mil Wed Jan 30 02:49:54 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11920 for ; Wed, 30 Jan 2002 02:49:54 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id AAA28562 for manet-outgoing; Wed, 30 Jan 2002 00:25:47 -0500 (EST) Received: from mmlab.snu.ac.kr (mmlab.snu.ac.kr [147.46.114.112]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id AAA28553 for ; Wed, 30 Jan 2002 00:25:41 -0500 (EST) Received: from pretty (coral.snu.ac.kr [147.46.15.209]) by mmlab.snu.ac.kr (8.11.6/8.11.6) with SMTP id g0U5Qfs80698 for ; Wed, 30 Jan 2002 14:26:41 +0900 (KST) (envelope-from pretty@mmlab.snu.ac.kr) Message-ID: <00a901c1a94d$73a650e0$d10f2e93@pretty> From: "±èµ¿±Õ" To: Subject: CFP : SAWN2002 Date: Wed, 30 Jan 2002 14:17:45 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by itd.nrl.navy.mil id AAA28556 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit * Apologize if you receive multiple copies of this announcement ! Please feel free to distribute a copy of this CFP to those who might be interested. ======================================================================= The Second Symposium on Ad Hoc Wireless Networks (SAWN2002) in conjunction with IEEE GLOBECOM 2002. November 17 - 21, 2002. Taipei, Taiwan, R.O.C. http://mmlab.snu.ac.kr/~pretty/sawn/sawn02.html ----------------------------------------------------------- CALL FOR PAPERS Objectives The IEEE Symposium on Ad-Hoc Wireless Networks (SAWN2002) is a new and high quality technical meeting (to be held as part of IEEE GLOBECOM 2002) for researchers to present their latest research work related to the fast evolving field of ad hoc (multihop, adaptive, and self-organizing) wireless networks and pervasive communications. Such networks could have strong potential impact on our daily lives (for example at home and on-the-road) and the way we work. They are also particularly attractive for military and emergency operations due to their fast deployable and self-organizing characteristics. Future ad hoc networks are also capable of supporting multimedia. High quality papers are invited from researchers in academia and industries who are involved in this area of work. Submissions Submissions are welcomed in any area related ad hoc wireless networks. The topics os interest include, but are not limited to : * Ad Hoc Routing Protocols/Algorithms * Ad Hoc Multicasting Protocols/Algorithms * Ad Hoc Transport Issues * Service Discovery Algorithms * Media Access Techniques/Protocols * Low Power Algorithms and Protocols * Sensor & Data Fusion Ad Hoc Networks * Quality of Service Issues * Ad Hoc Network Architectures * Mobile IP with Ad Hoc * Error & Link Control Techniques * Performance of Bluetooth Networks * Access & Session Support * Integration Issues Technical papers should be submitted to the Globecom Committee following the general Globecom submission process and instructions. In order to ensure that your paper is properly routed to this Symposium, it is VERY IMPORTANT that you explicitly identify "Symposium on Ad Hoc Wireless Networks" as the intended symposium to which you are submitting the paper. Failure to do so may result in your paper being forwarded to another symposium. All submissions will be made electronically and accepted papers will be published with GLOBECOM proceedings. Papers of particular merit may be considered for journal publications. Important Dates =============== Submission Deadline : February 25, 2002 Acceptance Notification : June 30, 2002 Camera Ready Paper Due : August 15, 2002 All inquires should be directed to the symposium chairman at dkkim@jade.snu.ac.kr or pretty@mmlab.snu.ac.kr Paper that are more than 5 pages are allowed but once they are accepted for publication, the author/s must be prepared to pay for additional page charges. SAWN 2002 Technical Program Chair Dr. Dongkyun Kim Seoul National University Steering Committee Members Prof. Victor Li University of Hong Kong Dr. Justin Chuang MobilinkTel USA Prof. C-K. Toh (Steering Committee Chair) Technical Program Committee Members Dr. Kenneth Brayer MITRE, USA Prof. Elvino S. Sousa Univ. of Toronto, Canada Dr. Silvia. Giordano EPFL, Switzerland Prof. Bo Li Hongkong UST Dr. Chip Elliott BBN, USA Dr. Eric Fleury INRIA, France Prof. Nick Bambos Stanford U, USA Prof. Znati, Taieb NSF/Pittsburg U Syed Akbar TRW, USA Prof. Khaled Ben Letaief Hongkong UST Prof. Halim Yanikomeroglu Carleton U, Canada Dr. Yile Guo NOKIA, USA Prof. Adam Wolisz TU-berlin, Germany Dr. Nader Moayeri NIST, USA Prof. Y.H. Choi Seoul National Univ., Korea Dr. Chih-Lin I AT & T, USA Prof. K.C. Chen NTU, Taiwan Dr. Howard Lemberg Telcordia, USA Prof. Hussein Mouftah Queens University, Canada Prof. Jean-Yves Le-Boudec EPFL, Switzerland Dr. Bassam Hashem Nortel Networks Dr. PeiYing Zhu Nortel Networks Dr. Chatschik Bisdikian IBM Watson Lab. Prof. Per Gunningberg Uppsala U, Sweden From owner-manet@itd.nrl.navy.mil Wed Jan 30 05:42:13 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14280 for ; Wed, 30 Jan 2002 05:42:12 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id DAA00639 for manet-outgoing; Wed, 30 Jan 2002 03:37:11 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id DAA00629 for ; Wed, 30 Jan 2002 03:37:07 -0500 (EST) Received: from lt.eth.ericsson.se (lt.eth.ericsson.se [164.48.158.205]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g0U8b6X4009525 for ; Wed, 30 Jan 2002 09:37:06 +0100 (MET) Received: from wittgenstein.danubius by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA23756; Wed, 30 Jan 2002 09:37:04 +0100 (MET) Received: from eth.ericsson.se (localhost [127.0.0.1]) by wittgenstein.danubius (8.8.8+Sun/8.8.8) with ESMTP id JAA23412 for ; Wed, 30 Jan 2002 09:37:04 +0100 (MET) Message-ID: <3C57B0B0.6E490703@eth.ericsson.se> Date: Wed, 30 Jan 2002 09:37:04 +0100 From: Ferenc Kubinszky X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil Subject: Re: Multirate and 802.11 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hello, > I had a couple of questions about multirate support of IEEE 802.11. I > will be gratefuil if someone can provide pointers etc... > > (*) I know that the PHY preamble and headers are all sent at a basic rate > (1Mbps?). Is the RTS/CTS exchange also done at the basic rate ? > > (*)....if not then how do other overhearing nodes latch onto the > RTS/CTS.. ? Yes, they are. (or maybe at 2 Mbps, I can't remember exactly) But as I know the some manufacturers sometimes break the standard, use short preambles, and higher RTS/CTS bitrates to reduce the overhead, which is really high in the basic case. In that case older cards can't communicate, because they can't decode the CCK "modulation". Carrier detection still works in this case. With RTS/CTS mechanism the measured throughput between two nodes communicating at 11Mbps is smaller by 20% than without RTS/CTS (1500byte MTU). Is there any simulation or measurement results that proove the necessity of RTS/CTS ? Best regards, Ferenc From owner-manet@itd.nrl.navy.mil Wed Jan 30 07:25:45 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16125 for ; Wed, 30 Jan 2002 07:25:45 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA01996 for manet-outgoing; Wed, 30 Jan 2002 05:30:26 -0500 (EST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id FAA01991 for ; Wed, 30 Jan 2002 05:30:23 -0500 (EST) Received: from prisse (prisse.inria.fr [128.93.9.64]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g0UAUMr16041 for ; Wed, 30 Jan 2002 11:30:23 +0100 (MET) Message-ID: <001401c1a97a$bd680660$40095d80@inria.fr> From: "Philippe Jacquet" To: References: <200201291958.LAA13094@pit.erg.sri.com> Subject: Re: Manet flooding / broadcasting.... Date: Wed, 30 Jan 2002 11:41:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: To: Cc: Sent: Tuesday, January 29, 2002 8:58 PM Subject: Re: Manet flooding / broadcasting.... > > Since HELLOs are differential in TBRPF, this can be done with a > relatively small increase in overhead. However, in OSPF and OLSR, > since each HELLO contains all neighbor IDs, this would increase > overhead a lot if each node has a large number of neighbors. > Richard, again, OLSR HELLOs can be partial, you only need to refresh all neighbors within a certain period, and you can increase the hello rate for fast moving node. I think Laurent mentioned this to you before. However don't forget that even the overhead of an empty HELLO can be non negligible. In IEEE 802.11 the MAC-PHY overhead is around 192 usec (with option to 92 usec) which at 11 Mbps corresponds to approximately 60 IPv4 addresses. Philippe From owner-manet@itd.nrl.navy.mil Wed Jan 30 11:10:28 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23641 for ; Wed, 30 Jan 2002 11:10:27 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA06269 for manet-outgoing; Wed, 30 Jan 2002 08:52:26 -0500 (EST) Received: from mailgate5.cinetic.de (mailgate5.cinetic.de [217.72.192.165]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA06264 for ; Wed, 30 Jan 2002 08:52:22 -0500 (EST) Received: from web.de (fmomail02.dlan.cinetic.de [172.20.1.46]) by mailgate5.cinetic.de (8.11.2/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id g0UDqHC29702 for manet@itd.nrl.navy.mil; Wed, 30 Jan 2002 14:52:17 +0100 Date: Wed, 30 Jan 2002 14:52:17 +0100 Message-Id: <200201301352.g0UDqHC29702@mailgate5.cinetic.de> MIME-Version: 1.0 Organization: http://freemail.web.de/ From: Michael Sessinghaus To: manet@itd.nrl.navy.mil Subject: plot the trace file?? Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have a problem to plot the data streams from ns trace format. How I convert the ns trace to xgraph or matlab?? I search for a tutorial but i find nothing. I want to plot TCP throughput, goodput and other related data streams. PLEASE HELP ME! Thankful for your help. Best Regards, Michael. ________________________________________________________________ Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr! Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13 From owner-manet@itd.nrl.navy.mil Wed Jan 30 12:18:10 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25852 for ; Wed, 30 Jan 2002 12:18:10 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA09097 for manet-outgoing; Wed, 30 Jan 2002 10:07:36 -0500 (EST) Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA09086; Wed, 30 Jan 2002 10:07:31 -0500 (EST) From: sunghyun.choi@philips.com Received: from smtpscan-nl3.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id QAA12254; Wed, 30 Jan 2002 16:06:49 +0100 (CET) (envelope-from sunghyun.choi@philips.com) Received: from smtpscan-nl3.philips.com(130.139.36.23) by gw-nl4.philips.com via mwrap (4.0a) id xma012248; Wed, 30 Jan 02 16:06:49 +0100 Received: from smtprelay-us1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA22323; Wed, 30 Jan 2002 16:07:24 +0100 (MET) Received: from arj001soh.diamond.philips.com (amsoh01.diamond.philips.com [161.88.79.212]) by smtprelay-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id JAA11867; Wed, 30 Jan 2002 09:07:22 -0600 (CST) To: Vikram Kanodia Cc: manet@itd.nrl.navy.mil, owner-manet@itd.nrl.navy.mil Subject: Re: Multirate and 802.11 X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 30 Jan 2002 10:15:33 -0500 X-MIMETrack: Serialize by Router on arj001soh/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at 30/01/2002 09:11:01, Serialize complete at 30/01/2002 09:11:01 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005377C085256B51_=" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This is a multipart message in MIME format. --=_alternative 005377C085256B51_= Content-Type: text/plain; charset="us-ascii" Hi Vikram, Basically, RTS/CTS and all other control frames (e.g., ACK) frames should be transmitted at one of rates in the BSS Basic Rate Set. In the typical 802.11b network, the BSS Basic Rate Set is 1 & 2 Mbps. That means RTS/CTS will be transmitted at either 1 or 2 Mbps typically. At the same time, the BSS Basic Rate Set is really up to the station, which initiates each particular BSS, which would be an AP in case of infrastructure BSS, and the first station in case of independent BSS used for MANET, I believe. BTW, the BSS Basic Rate Set includes all the rates, which should be supported (i.e., receivable and transmittable) by all the stations in the particular BSS. That is, a station which does not support any of the rates in the BSS Basic Rate Set will not be allowed to be part of the BSS. This will ensure that all the stations will receive all the control frames including RTS/CTS. When 802.11g (a higher rate version of .11b) comes to the market, the whole 802.11b rates, i.e., 1, 2, 5.5, and 11 Mbps, may be used for the BSS Basic Rate Set, in many cases. FYI. Sunghyun ------------ Sunghyun Choi, Ph.D. Senior Member Research Staff WiCAN - Wireless Communications and Networking Department Philips Research USA, Briarcliff Manor, New York, USA Tel: (914) 945 6506 Fax: (914) 945 6580 E-mail: sunghyun.choi@philips.com URL 1: http://www.philabs.research.philips.com/~szc - Philips internal URL 2: http://www.eecs.umich.edu/~shchoi - Personal Homepage ** My opinions do not necessarily reflect those of my employer ** Vikram Kanodia Sent by: owner-manet@itd.nrl.navy.mil 01/29/2002 04:48 PM To: manet@itd.nrl.navy.mil cc: (bcc: Sunghyun Choi/BRQ/RESEARCH/PHILIPS) Subject: Multirate and 802.11 Classification: Hi, I had a couple of questions about multirate support of IEEE 802.11. I will be gratefuil if someone can provide pointers etc... (*) I know that the PHY preamble and headers are all sent at a basic rate (1Mbps?). Is the RTS/CTS exchange also done at the basic rate ? (*)....if not then how do other overhearing nodes latch onto the RTS/CTS.. ? Thanks, -Vikram -- Department of ECE, Rice University | 713 348 3786 (O)| 713 664 5650(H) WWW: http://www.ece.rice.edu/~kanodia --=_alternative 005377C085256B51_= Content-Type: text/html; charset="us-ascii"
Hi Vikram,

Basically, RTS/CTS and all other control frames (e.g., ACK) frames
should be transmitted at one of rates in the BSS Basic Rate Set.
In the typical 802.11b network, the BSS Basic Rate Set is 1 & 2 Mbps.
That means RTS/CTS will be transmitted at either 1 or 2 Mbps typically.

At the same time, the BSS Basic Rate Set is really up to the station,
which initiates each particular BSS, which would be an AP in case of infrastructure BSS,
and the first station in case of independent BSS used for MANET, I believe.

BTW, the BSS Basic Rate Set includes all the rates, which should be supported
(i.e., receivable and transmittable) by all the stations in the particular BSS.
That is, a station which does not support any of the rates in the BSS Basic Rate Set
will not be allowed to be part of the BSS.
This will ensure that all the stations will receive all the control frames including RTS/CTS.

When 802.11g (a higher rate version of .11b) comes to the market, the whole 802.11b rates, i.e.,
1, 2, 5.5, and 11 Mbps, may be used for the BSS Basic Rate Set, in many cases.

FYI.

Sunghyun

------------
Sunghyun Choi, Ph.D.
Senior Member Research Staff
WiCAN - Wireless Communications and Networking Department
Philips Research USA, Briarcliff Manor, New York, USA
Tel: (914) 945 6506 Fax: (914) 945 6580
E-mail: sunghyun.choi@philips.com
URL 1: http://www.philabs.research.philips.com/~szc - Philips internal
URL 2: http://www.eecs.umich.edu/~shchoi - Personal Homepage
** My opinions do not necessarily reflect those of my employer **

Vikram Kanodia <kanodia@rice.edu>
Sent by: owner-manet@itd.nrl.navy.mil

01/29/2002 04:48 PM

To: manet@itd.nrl.navy.mil
cc: (bcc: Sunghyun Choi/BRQ/RESEARCH/PHILIPS)
Subject: Multirate and 802.11

Classification:

Hi, I had a couple of questions about multirate support of IEEE 802.11. I will be gratefuil if someone can provide pointers etc... (*) I know that the PHY preamble and headers are all sent at a basic rate (1Mbps?). Is the RTS/CTS exchange also done at the basic rate ? (*)....if not then how do other overhearing nodes latch onto the RTS/CTS.. ? Thanks, -Vikram -- Department of ECE, Rice University | 713 348 3786 (O)| 713 664 5650(H) WWW: http://www.ece.rice.edu/~kanodia

--=_alternative 005377C085256B51_=-- From owner-manet@itd.nrl.navy.mil Wed Jan 30 14:05:01 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29346 for ; Wed, 30 Jan 2002 14:05:01 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA13141 for manet-outgoing; Wed, 30 Jan 2002 11:34:00 -0500 (EST) Received: from web21009.mail.yahoo.com (web21009.mail.yahoo.com [216.136.227.63]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id LAA13136 for ; Wed, 30 Jan 2002 11:33:57 -0500 (EST) Message-ID: <20020130163357.93178.qmail@web21009.mail.yahoo.com> Received: from [65.88.242.115] by web21009.mail.yahoo.com via HTTP; Wed, 30 Jan 2002 08:33:57 PST Date: Wed, 30 Jan 2002 08:33:57 -0800 (PST) From: Yang Xiao Reply-To: YangXiao@ieee.org Subject: Re: Multirate and 802.11 To: Ferenc Kubinszky , manet@itd.nrl.navy.mil In-Reply-To: <3C57B0B0.6E490703@eth.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk According to the standerd, the control frame data rate may be different from the data frame rate, and the control frame rate is one among the basic rate set. For example, in 802.11a, the basic rate set is {6, 12, 24} Mbps. One example of settings is to let the control rate for IEEE 802.11a be 24Mbps if the data rate 24Mbps, 6Mbps if the data rate <12Mbps, otherwise, is 12Mbps. RTS and CTS are control frames, and they are used as RTS-CTS-DATA-ACK. RTS/TCS is an option of IEEE 802.11 to reduce overhead. However, in a infrastructure with Ethernet presented as the distributed systemt (DS), the packet size normally 1500Bytes. In an ad hoc network, the packet size can be expected larger. Regards, Yang --- Ferenc Kubinszky wrote: > Hello, > > > I had a couple of questions about multirate support of IEEE 802.11. > I > > will be gratefuil if someone can provide pointers etc... > > > > (*) I know that the PHY preamble and headers are all sent at a > basic rate > > (1Mbps?). Is the RTS/CTS exchange also done at the basic rate ? > > > > (*)....if not then how do other overhearing nodes latch onto the > > RTS/CTS.. ? > > Yes, they are. (or maybe at 2 Mbps, I can't remember exactly) > But as I know the some manufacturers sometimes break the standard, > use > short preambles, and higher RTS/CTS bitrates to reduce the overhead, > which is really high in the basic case. > In that case older cards can't communicate, because they can't decode > the CCK "modulation". > Carrier detection still works in this case. > > With RTS/CTS mechanism the measured throughput between two nodes > communicating at 11Mbps is smaller by 20% than without RTS/CTS > (1500byte > MTU). > Is there any simulation or measurement results that proove the > necessity > of RTS/CTS ? > > Best regards, > Ferenc __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com From daemon@optimus.ietf.org Wed Jan 30 14:58:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00902 for ; Wed, 30 Jan 2002 14:58:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA19900 for manet-archive@odin.ietf.org; Wed, 30 Jan 2002 14:58:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19893 for ; Wed, 30 Jan 2002 14:58:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19876 for ; Wed, 30 Jan 2002 14:58:12 -0500 (EST) Received: from peregrine.nps.navy.mil (essex.ad.nps.navy.mil [131.120.18.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00897 for ; Wed, 30 Jan 2002 14:58:10 -0500 (EST) Received: from essex.ad.nps.navy.mil by peregrine.nps.navy.mil via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 30 Jan 2002 19:59:48 UT Received: by essex.ad.nps.navy.mil with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 11:55:30 -0800 Message-ID: <21255707C24105438C5BEA7061D33228B72F1C@essex.ad.nps.navy.mil> From: "Blackshear, Henry" To: "'manet@ietf.org'" Date: Wed, 30 Jan 2002 11:55:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Manet] AODV or DSR gateway for OPNET win 2000?? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org To anyone that can assist, I am trying to model an extended military mobile network that communicates to other mobile networks via an Airborne platform (i.e.UAV). I have the MANET protocols (DSR and AODV) developed by NIST. In my research I have found that a gateway is needed for communication outside of a subnet when using OPNET nodes that use the wireless MAC model. Have any experts developed a gateway, access point, or subnet leader for any of the published MANET protocols? I currently have both the DSR and AODV working on a windows 2000 machine. Any assistance is greatly appreciated. Capt Henry Blackshear _______________________________________________ Manet mailing list Manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From owner-manet@itd.nrl.navy.mil Wed Jan 30 15:41:13 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01799 for ; Wed, 30 Jan 2002 15:41:11 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA17437 for manet-outgoing; Wed, 30 Jan 2002 13:10:51 -0500 (EST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA17429 for ; Wed, 30 Jan 2002 13:10:47 -0500 (EST) Received: from impression.inria.fr (impression.inria.fr [128.93.17.98]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g0UIAfr05726; Wed, 30 Jan 2002 19:10:42 +0100 (MET) Received: by impression.inria.fr (sSMTP sendmail emulation); Wed, 30 Jan 2002 19:10:37 +0100 From: Laurent Viennot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15448.14109.929710.281170@impression.inria.fr> Date: Wed, 30 Jan 2002 19:10:37 +0100 To: ogier@erg.sri.com Cc: manet@itd.nrl.navy.mil Subject: Re: Manet flooding / broadcasting.... In-Reply-To: <200201291958.LAA13094@pit.erg.sri.com> References: <15446.32330.245417.347999@impression.inria.fr> <200201291958.LAA13094@pit.erg.sri.com> X-Mailer: VM 6.92 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-To: Laurent.Viennot@inria.fr Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Dear Richard, As mentioned by Philippe the overhead of sending a packet is quite high and makes differential updates significantly less attractive. But let me try to summarize the advantages of partial HELLOs as used in OLSR. Notice for example that partial HELLOs allow to make differential updates since you can advertise a new neighbor at any time (and also the loss of a neighbor thanks to the LOST_LINK status). Indeed, partial HELLOs is a very flexible way of advertising neighbors. Let me recall the basic principles of partial HELLOs : - the rule is: any neighbor must be advertised at least once in every HELLO_INTERVAL period of time - the list of neighbors can be advertised in any number of HELLO messages during that period of time - this allows to avoid fragmentation of HELLO messages if their size is higher than maximum size of MAC packets (fragmentation should be avoided because the loss of one packet will prevent from reading other packets) Link breakage detection is a sensitive part of a MANet and there are two main ways of doing that in OLSR : - either you can get link layer notification, and if a node gets a link failure notification it immediately sends a HELLO message with LOST_LINK status and a correcting TC message if necessary, - either you can't and then you rely on link hysteresis. Neighbor sensing with link hysteresis is a much more advanced way of testing links than counting the number of received HELLOs during a certain period of time. With link hysteresis, the quality of a link is estimated. If the quality is higher than HYST_THRESHOLD_HIGH, the link becomes valid. When the quality becomes lower than HYST_THRESHOLD_LOW, the link is then considered pending and is advertised as lost. Setting HYST_THRESHOLD_HIGH strictly higher than HYST_THRESHOLD_LOW allows to cope with dangling links. If power level is available from the link layer, it can be used for estimating the link quality and anticipating link breakage. When no information is available from the link layer, link hysteresis uses the reception and loss of control messages for estimating the link quality. Each time a control message is received, the link quality is increased and each time a control message is lost, the link quality is decreased. The sequence numbers of control messages allow to detect loss of messages. The loss of any control message is a valuable information for detecting link breakage and link hysteresis allows to do that. In conclusion, I would say that partial HELLOs together with link hysteresis is a better alternative than differential HELLOs. laurent ogier@erg.sri.com writes: > > Laurent, > > > Dear Richard, > > > > I agree that OLSR is an optimized adaptation of OSPF. But I don't follow > > your claim about reporting neighbors in TBRPF: > > > > > - In OSPF, each HELLO contains the ID of every neighbor, whereas > > > TBRPF uses much smaller differential HELLOs, which report only > > > *changes* in neighbor states. > > > > As I understand your draft, all neighbors are advertised regularly in > > every periodic topology update message (every > > PER_UPDATE_INTERVAL). Indeed I had a hard time for figuring that out > > from your pseudo-code. > > > > No matter whether you advertise the full list of neighbors in HELLOs > > or in TOPOLOGY UPDATES, the overhead is there. What is the right > > period for advertising this list is a tuning issue. > > > > laurent > > The main tuning issue regarding HELLOs (whether you are talking > about TBRPF, OLSR, or OSPF) is that if HELLOs are sent more > frequently, then the detection of link failures/breakages can be > done more quickly. Thus it would be good to send HELLOs more > frequently (e.g., every 0.5 sec) if nodes are moving fast. > > Since HELLOs are differential in TBRPF, this can be done with a > relatively small increase in overhead. However, in OSPF and OLSR, > since each HELLO contains all neighbor IDs, this would increase > overhead a lot if each node has a large number of neighbors. > > In TBRPF, each node reports links to all neighbors in periodic > topology updates, which are sent less frequently than HELLOs, > just as periodic TC messages are sent less frequently than > HELLOs in OLSR. For example, in a network with very fast moving > nodes, HELLOs might be sent every 0.5 second while periodic topology > updates are sent every 5 seconds. Therefore, TBRPF saves a lot of > overhead by reporting links to neighbors less frequently. > (In OLSR, each node needs to advertise its neighbor set more > frequently because this information is needed to select MPRs.) > > Another advantage of reporting links to neighbors in topology updates > instead of HELLOs is that (unlike OLSR) neighbor sensing performs ONLY > neighbor sensing. Thus, in TBRPF, neighbor sensing is completely modular > and separate from topology discovery. In OLSR, each node reports its links > to all neighbors (and also its MPRs) in HELLOs. Note that OSPF also > uses HELLOs only for neighbor sensing (even though the HELLOs are > not differential). I really think this is a better approach. > > A related issue is that TBRPF also uses differential topology updates > (unlike OLSR) so that a link failure (e.g., detected through link-layer > notification) can be quickly reported with minimal overhead to all > nodes that are affected by the failure. > > I noticed that OLSR allows triggered TC messages to be sent in response > to link-layer notification. Since these are full (not differential) > TC messages, I would expect that this will create a lot of additional > control traffic if link-layer notification is used in highly mobile > networks with a large number of streams. However, the simulation > study posted a few days (comparing OLSR to AODV) does not use link-layer > notification (resulting in a packet delivery fraction that is often > less than 50%), and the ns-2 code for OLSR available from the INRIA > site does not provide link-layer notification (as does the available > AODV code and the available TBRPF code at www.erg.sri.com/projects/tbrpf). > > I think it is important to conduct simulations that use link-layer > notification for the following reasons: > > 1. It is the only way to achieve a packet delivery fraction close > to 100% without end-to-end retransmission (which is not acceptable > for real-time traffic such as voice). > > 2. Link-layer notification is usually available on commercially > available 802.11 cards (e.g., Cisco Aironet). > > Regards, > Richard > > From owner-manet@itd.nrl.navy.mil Wed Jan 30 17:15:05 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03491 for ; Wed, 30 Jan 2002 17:15:05 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA22491 for manet-outgoing; Wed, 30 Jan 2002 15:05:33 -0500 (EST) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA22476; Wed, 30 Jan 2002 15:05:24 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id MAA18940; Wed, 30 Jan 2002 12:04:31 -0800 (PST) Message-Id: <200201302004.MAA18940@pit.erg.sri.com> To: Joe Macker cc: manet@itd.nrl.navy.mil Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: Some follow-up OLSR/AODV results In-reply-to: Your message of "Tue, 29 Jan 2002 20:15:19 EST." <5.0.1.4.2.20020129185253.031d1c10@pop.itd.nrl.navy.mil> Date: Wed, 30 Jan 2002 12:04:31 -0800 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Joe, > Richard/All: > > I ran some example OLSR performance curves vs. AODV to check against findings recently presented at the Salt Lake IETF. I used the s ame scenarios and cmu tools and was most interested initially in the static topology results since my early OLSR results were very diff erent from those presented. > > I posted one OLSR /AODV example output at http://protean.itd.nrl.navy.mil/manet/olsrstatic.pdf > I also used fixed scales to plot since I believe autoscaling plots can overexaggerate the difference s in performance between protoco ls > > In the 100 node case, Ogier's results have OLSR never obtaining more than 65% packet delivery or so. My results show it achieving cl ose to 100% packet delivery for the lower loading case and retaining reasonable performance as loading increases (it even beat the AODV model with link layer notification in this static example)...yes mobility is more interesting and OLSR degrades, but I am here trying to independently reproduce snapshots of the experiments you presented. > > Richard, I feel some of protocol points being raised are valid but I did want to present some results I obtained from running some tr ials that don't seem to match up with IETF presented results. I will try and produce some additional mobility curves and post them as well, my initial mobility results for OLSR (Aalborg) also look much better than you presented at the last meeting...(I know I mentioned alot about potential porting problems with jitter, event handlers,etc in the linux based source code you were working with)...not sure any of the differences could be caused by configuration or implementation issues but there must be some differences. Yes, there must be some differences, since the two versions of the code were written by different people. I will make some effort to determine the reason for the different results, but I am also re-running the experiments using the ns-2 code available from the INRIA site. Is the Aalborg code exactly the same as the ns-2 code available from the INRIA site? Are you using the WaveLAN 802.11 model with 2 Mbps bandwidth? Richard > In addition, we have almost completed some other work that is independently developing an OLSR ns2 implementation with optional link layer notification and faster localized MPR state repairing. This work was being done prior to recent discussions, but I thought I'd m ention it since people are discussing it. > > -joe > > > At 11:58 AM 1/29/2002 -0800, ogier@erg.sri.com wrote: > >I noticed that OLSR allows triggered TC messages to be sent in response > >to link-layer notification. Since these are full (not differential) > >TC messages, I would expect that this will create a lot of additional > >control traffic if link-layer notification is used in highly mobile > >networks with a large number of streams. However, the simulation > >study posted a few days (comparing OLSR to AODV) does not use link-layer > >notification (resulting in a packet delivery fraction that is often > >less than 50%), and the ns-2 code for OLSR available from the INRIA > >site does not provide link-layer notification (as does the available > >AODV code and the available TBRPF code at www.erg.sri.com/projects/tbrpf). > > > >I think it is important to conduct simulations that use link-layer > >notification for the following reasons: > > > > 1. It is the only way to achieve a packet delivery fraction close > > to 100% without end-to-end retransmission (which is not acceptable > > for real-time traffic such as voice). > > > > 2. Link-layer notification is usually available on commercially > > available 802.11 cards (e.g., Cisco Aironet). > > > >Regards, > >Richard > > From owner-manet@itd.nrl.navy.mil Wed Jan 30 17:21:59 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03637 for ; Wed, 30 Jan 2002 17:21:59 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA22892 for manet-outgoing; Wed, 30 Jan 2002 15:15:30 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA22886; Wed, 30 Jan 2002 15:15:25 -0500 (EST) Message-Id: <5.0.1.4.2.20020130151400.02b6b948@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Wed, 30 Jan 2002 15:24:27 -0500 To: Michael Sessinghaus , manet@itd.nrl.navy.mil From: Joe Macker Subject: Re: plot the trace file?? In-Reply-To: <200201301352.g0UDqHC29702@mailgate5.cinetic.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Michael: There are lots of possible tools for this and some very specific detailed tcp ones that are good. The ns distribution also has some example scripts. As another tool for your bag of tricks, you could look at something we developed, trpr, which has trace parsing and statistical analysis routines and acts as a front end to gnuplot. We use it to plot drec and tcpdump outputs both in real-time and non-realtime modes. We recently added an ns capability recently as well which may work for you. There is a description, source code, and user's guide here. http://proteantools.pf.itd.nrl.navy.mil/ and a source code project site at http://pf.itd.nrl.navy.mil/projects/proteantools/ -joe At 02:52 PM 1/30/2002 +0100, Michael Sessinghaus wrote: >Hi, > >I have a problem to plot the data streams from ns trace format. >How I convert the ns trace to xgraph or matlab?? >I search for a tutorial but i find nothing. >I want to plot TCP throughput, goodput and other related data streams. From owner-manet@itd.nrl.navy.mil Wed Jan 30 17:59:47 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04280 for ; Wed, 30 Jan 2002 17:59:47 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA25342 for manet-outgoing; Wed, 30 Jan 2002 16:09:21 -0500 (EST) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA25326; Wed, 30 Jan 2002 16:09:17 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id NAA19247; Wed, 30 Jan 2002 13:08:24 -0800 (PST) Message-Id: <200201302108.NAA19247@pit.erg.sri.com> To: Joe Macker cc: manet@itd.nrl.navy.mil Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: Some follow-up OLSR/AODV results In-reply-to: Your message of "Tue, 29 Jan 2002 20:15:19 EST." <5.0.1.4.2.20020129185253.031d1c10@pop.itd.nrl.navy.mil> Date: Wed, 30 Jan 2002 13:08:24 -0800 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Joe, > Richard/All: > > I ran some example OLSR performance curves vs. AODV to check against findings recently presented at the Sa lt Lake IETF. I used the same scenarios and cmu tools and was most interested initially in the static topol ogy results since my early OLSR results were very different from those presented. > > I posted one OLSR /AODV example output at http://protean.itd.nrl.navy.mil/manet/olsrstatic.pdf > I also used fixed scales to plot since I believe autoscaling plots can overexaggerate the difference s in performance between protocols > > In the 100 node case, Ogier's results have OLSR never obtaining more than 65% packet delivery or so. My r esults show it achieving close to 100% packet delivery for the lower loading case and retaining reasonable p erformance as loading increases (it even beat the AODV model with link layer notification in this static exa mple)...yes mobility is more interesting and OLSR degrades, but I am here trying to independently reproduce snapshots of the experiments you presented. We did not run simulations for the static case with 40 sources (which is what you are using) but we did run 20 m/s with 40 sources, and in this case TBRPF also performed significantly better than AODV. These results can be found at the TBRPF site: http://www.erg.sri.com/projects/tbrpf/ However, I should note that AODV did not use local repair (but both AODV and TBRPF used link-layer notification). I am thinking of using three different sets of assumptions in simulation experiments: 1. With link-layer notification, buffering of data packets at intermediate nodes allowed (In this case, AODV would use local repair.) 2. With link-layer notification, buffering of data packets at intermediate nodes NOT allowed (In this case, AODV would not use local repair since this requires buffering at intermediate nodes.) 3. No link-layer notification, buffering of data packets at intermediate nodes NOT allowed. Any comments? Richard From owner-manet@itd.nrl.navy.mil Wed Jan 30 18:10:24 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04510 for ; Wed, 30 Jan 2002 18:10:24 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA25324 for manet-outgoing; Wed, 30 Jan 2002 16:09:13 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA25319; Wed, 30 Jan 2002 16:09:04 -0500 (EST) Message-Id: <5.0.1.4.2.20020130152446.02c16e00@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Wed, 30 Jan 2002 15:35:30 -0500 To: ogier@erg.sri.com From: Joe Macker Subject: Re: Some follow-up OLSR/AODV results Cc: manet@itd.nrl.navy.mil In-Reply-To: <200201302004.MAA18940@pit.erg.sri.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 12:04 PM 1/30/2002 -0800, ogier@erg.sri.com wrote: >Joe, > >> Richard/All: >> >> I ran some example OLSR performance curves vs. AODV to check against findings recently presented at the Salt Lake IETF. I used the s >ame scenarios and cmu tools and was most interested initially in the static topology results since my early OLSR results were very diff >erent from those presented. >> >> I posted one OLSR /AODV example output at http://protean.itd.nrl.navy.mil/manet/olsrstatic.pdf >> I also used fixed scales to plot since I believe autoscaling plots can overexaggerate the difference s in performance between protoco >ls >> >> In the 100 node case, Ogier's results have OLSR never obtaining more than 65% packet delivery or so. My results show it achieving cl >ose to 100% packet delivery for the lower loading case and retaining reasonable performance as loading increases (it even beat the AODV > model with link layer notification in this static example)...yes mobility is more interesting and OLSR degrades, but I am here trying >to independently reproduce snapshots of the experiments you presented. >> >> Richard, I feel some of protocol points being raised are valid but I did want to present some results I obtained from running some tr >ials that don't seem to match up with IETF presented results. I will try and produce some additional mobility curves and post them as >well, my initial mobility results for OLSR (Aalborg) also look much better than you presented at the last meeting...(I know I mentioned > alot about potential porting problems with jitter, event handlers,etc in the linux based source code you were working with)...not sure > any of the differences could be caused by configuration or implementation issues but there must be some differences. > >Yes, there must be some differences, since the two versions of the code were written by >different people. I will make some effort to determine the reason for the different results, >but I am also re-running the experiments using the ns-2 code available from the INRIA site. >Is the Aalborg code exactly the same as the ns-2 code available from the INRIA site? I don't know that. Perhaps one of the developer's and releasing agents could chime in. >Are you using the WaveLAN 802.11 model with 2 Mbps bandwidth? Yes From owner-manet@itd.nrl.navy.mil Wed Jan 30 21:44:47 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07571 for ; Wed, 30 Jan 2002 21:44:47 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA01294 for manet-outgoing; Wed, 30 Jan 2002 19:08:33 -0500 (EST) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id TAA01288 for ; Wed, 30 Jan 2002 19:08:27 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id QAA19810; Wed, 30 Jan 2002 16:00:05 -0800 (PST) Message-Id: <200201310000.QAA19810@pit.erg.sri.com> To: "Philippe Jacquet" cc: manet@itd.nrl.navy.mil Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: Manet flooding / broadcasting.... In-reply-to: Your message of "Wed, 30 Jan 2002 11:41:57 +0100." <001401c1a97a$bd680660$40095d80@inria.fr> Date: Wed, 30 Jan 2002 16:00:05 -0800 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > ----- Original Message ----- > From: > To: > Cc: > Sent: Tuesday, January 29, 2002 8:58 PM > Subject: Re: Manet flooding / broadcasting.... > > > > > > Since HELLOs are differential in TBRPF, this can be done with a > > relatively small increase in overhead. However, in OSPF and OLSR, > > since each HELLO contains all neighbor IDs, this would increase > > overhead a lot if each node has a large number of neighbors. > > > Richard, again, OLSR HELLOs can be partial, you only need to refresh all > neighbors within a certain period, and you can increase the hello rate for > fast moving node. I think Laurent mentioned this to you before. Philippe, Yes, I know that HELLOs can be partial and that each neighbor must be included in at least one HELLO every HELLO interval, but unless there are too many neighbor IDs to fit into one packet, normally OLSR uses one full HELLO per HELLO interval. (Just check the source code.) But this does not affect my argument. What I am saying is that OLSR must include each neighbor in a HELLO every HELLO_INTERVAL, whereas TBRPF includes each neighbor only in periodic topology updates, which are less frequent (e.g., 10 times less frequent if the HELLO_INTERVAL is 0.5 s and the update period is 5 s). It is the HELLO_INTERVAL that determines how quickly a failed link is detected, e.g., if no HELLO is received within 3 * HELLO_INTERVAL, then the neighbor is declared to be lost. I also know that OLSR can use differential HELLOs, since it has recently added the LOST_LINK status (which TBRPF has had since version 01). *But this does not change the requirement that in OLSR each neighbor ID must be included in at least one HELLO every HELLO_INTERVAL.* You can increase HELLO_INTERVAL, but then it would take longer to detect a lost neighbor. OLSR could be *modified* so that each neighbor ID is reported less frequently than HELLO_INTERVAL (as in TBRPF), but I am not sure how this would affect MPR computation. > However don't forget that even the overhead of an empty HELLO can be non > negligible. In IEEE 802.11 the MAC-PHY overhead is around 192 usec (with > option to 92 usec) which at 11 Mbps corresponds to approximately 60 IPv4 > addresses. Yes, this is a good point. With the 92 usec option, this becomes about 30 IPv4 addresses (or router IDs). So if a node has 30 neighbors, then a full HELLO is about twice as big as an empty HELLO. I think that's significant. There are lots of differences between TBRPF and OLSR that can affect performance, and we have already discussed many of these. But it is difficult to predict how these differences affect performance. That's what simulations are for. Regards, Richard From owner-manet@itd.nrl.navy.mil Thu Jan 31 07:44:27 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24794 for ; Thu, 31 Jan 2002 07:44:27 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA09233 for manet-outgoing; Thu, 31 Jan 2002 05:10:10 -0500 (EST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id FAA09228 for ; Thu, 31 Jan 2002 05:10:05 -0500 (EST) Received: from impression.inria.fr (impression.inria.fr [128.93.17.98]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g0VAA3D28317; Thu, 31 Jan 2002 11:10:03 +0100 (MET) Received: by impression.inria.fr (sSMTP sendmail emulation); Thu, 31 Jan 2002 11:09:59 +0100 From: Laurent Viennot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15449.6135.411716.804489@impression.inria.fr> Date: Thu, 31 Jan 2002 11:09:59 +0100 To: ogier@erg.sri.com Cc: "Philippe Jacquet" , manet@itd.nrl.navy.mil Subject: Re: Manet flooding / broadcasting.... In-Reply-To: <200201310000.QAA19810@pit.erg.sri.com> References: <001401c1a97a$bd680660$40095d80@inria.fr> <200201310000.QAA19810@pit.erg.sri.com> X-Mailer: VM 6.92 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-To: Laurent.Viennot@inria.fr Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Dear Richard, Please take a look at previous mail about partial HELLOs in OLSR. I have to correct some points you mention here about OLSR that are wrong. laurent ogier@erg.sri.com writes: > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Tuesday, January 29, 2002 8:58 PM > > Subject: Re: Manet flooding / broadcasting.... > > > > > > > > > > Since HELLOs are differential in TBRPF, this can be done with a > > > relatively small increase in overhead. However, in OSPF and OLSR, > > > since each HELLO contains all neighbor IDs, this would increase > > > overhead a lot if each node has a large number of neighbors. > > > > > Richard, again, OLSR HELLOs can be partial, you only need to refresh all > > neighbors within a certain period, and you can increase the hello rate for > > fast moving node. I think Laurent mentioned this to you before. > > Philippe, > > Yes, I know that HELLOs can be partial and that each neighbor must be > included in at least one HELLO every HELLO interval, but unless there > are too many neighbor IDs to fit into one packet, normally OLSR uses one > full HELLO per HELLO interval. (Just check the source code.) > In the released code yes but the draft allows to do differently. > But this does not affect my argument. What I am saying is that OLSR > must include each neighbor in a HELLO every HELLO_INTERVAL, whereas > TBRPF includes each neighbor only in periodic topology updates, which are > less frequent (e.g., 10 times less frequent if the HELLO_INTERVAL is 0.5 s > and the update period is 5 s). > > It is the HELLO_INTERVAL that determines how quickly a failed link is > detected, e.g., if no HELLO is received within 3 * HELLO_INTERVAL, then > the neighbor is declared to be lost. > No, with link hysteresis, you can detect the loss of packet also through missing sequence numbers. > I also know that OLSR can use differential HELLOs, > since it has recently added the LOST_LINK status (which TBRPF has > had since version 01). *But this does not change the requirement that No, LOST_LINK status is mentioned since version 02 of the OLSR draft and was included in HIPERLAN type 1 standard, so it is an old idea. > in OLSR each neighbor ID must be included in at least one HELLO every > HELLO_INTERVAL.* You can increase HELLO_INTERVAL, but then it > would take longer to detect a lost neighbor. OLSR could be *modified* > so that each neighbor ID is reported less frequently than HELLO_INTERVAL > (as in TBRPF), but I am not sure how this would affect MPR computation. > > > However don't forget that even the overhead of an empty HELLO can be non > > negligible. In IEEE 802.11 the MAC-PHY overhead is around 192 usec (with > > option to 92 usec) which at 11 Mbps corresponds to approximately 60 IPv4 > > addresses. > > Yes, this is a good point. With the 92 usec option, this becomes about 30 > IPv4 addresses (or router IDs). So if a node has 30 neighbors, then a full > HELLO is about twice as big as an empty HELLO. I think that's significant. > > There are lots of differences between TBRPF and OLSR that can affect > performance, and we have already discussed many of these. > But it is difficult to predict how these differences affect performance. > That's what simulations are for. > > Regards, > Richard > From owner-manet@itd.nrl.navy.mil Thu Jan 31 09:31:52 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27644 for ; Thu, 31 Jan 2002 09:31:51 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA10733 for manet-outgoing; Thu, 31 Jan 2002 07:07:37 -0500 (EST) Received: from mailhost.cs.auc.dk (mailhost.cs.auc.dk [130.225.194.6]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA10712; Thu, 31 Jan 2002 07:07:32 -0500 (EST) From: T.Clausen@computer.org Received: from localhost (root@borg.cs.auc.dk [130.225.194.22]) by mailhost.cs.auc.dk (8.12.2/8.12.2) with ESMTP id g0VC7QvU006216; Thu, 31 Jan 2002 13:07:27 +0100 (MET) Date: Thu, 31 Jan 2002 13:07:25 +0100 (CET) X-Sender: voop@armada To: Joe Macker cc: ogier@erg.sri.com, manet@itd.nrl.navy.mil Subject: Re: Some follow-up OLSR/AODV results In-Reply-To: <5.0.1.4.2.20020130152446.02c16e00@pop.itd.nrl.navy.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Scanned-By: MIMEDefang 2.2 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8BIT On Wed, 30 Jan 2002, Joe Macker wrote: > At 12:04 PM 1/30/2002 -0800, ogier@erg.sri.com wrote: > >different people. I will make some effort to determine the reason for the different results, > >but I am also re-running the experiments using the ns-2 code available from the INRIA site. > >Is the Aalborg code exactly the same as the ns-2 code available from the INRIA site? > > I don't know that. Perhaps one of the developer's and releasing agents > could chime in. > The ns2-code, currently available from the INRIA www-site, is equivalent with what Joe refers to as the Aalborg code. -- ------------------------------------------- Thomas Heide Clausen Civilingeniør i Datateknik (cand.polyt) M.Sc in Computer Engineering E-Mail: T.Clausen@computer.org WWW: http://www.cs.auc.dk/~voop ------------------------------------------- From owner-manet@itd.nrl.navy.mil Thu Jan 31 09:32:37 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27683 for ; Thu, 31 Jan 2002 09:32:37 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA10854 for manet-outgoing; Thu, 31 Jan 2002 07:14:11 -0500 (EST) Received: from mailhost.cs.auc.dk (mailhost.cs.auc.dk [130.225.194.6]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA10849 for ; Thu, 31 Jan 2002 07:14:07 -0500 (EST) From: T.Clausen@computer.org Received: from localhost (root@borg.cs.auc.dk [130.225.194.22]) by mailhost.cs.auc.dk (8.12.2/8.12.2) with ESMTP id g0VCE2vU006776; Thu, 31 Jan 2002 13:14:02 +0100 (MET) Date: Thu, 31 Jan 2002 13:14:01 +0100 (CET) X-Sender: voop@armada To: ogier@erg.sri.com cc: Philippe Jacquet , manet@itd.nrl.navy.mil Subject: Re: Manet flooding / broadcasting.... In-Reply-To: <200201310000.QAA19810@pit.erg.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Scanned-By: MIMEDefang 2.2 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8BIT On Wed, 30 Jan 2002 ogier@erg.sri.com wrote: > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Tuesday, January 29, 2002 8:58 PM > > Subject: Re: Manet flooding / broadcasting.... > > > > > > > > > > Since HELLOs are differential in TBRPF, this can be done with a > > > relatively small increase in overhead. However, in OSPF and OLSR, > > > since each HELLO contains all neighbor IDs, this would increase > > > overhead a lot if each node has a large number of neighbors. > > > > > Richard, again, OLSR HELLOs can be partial, you only need to refresh all > > neighbors within a certain period, and you can increase the hello rate for > > fast moving node. I think Laurent mentioned this to you before. > > Philippe, > > Yes, I know that HELLOs can be partial and that each neighbor must be > included in at least one HELLO every HELLO interval, but unless there > are too many neighbor IDs to fit into one packet, normally OLSR uses one > full HELLO per HELLO interval. (Just check the source code.) Richard, Please keep seperate implementation choises from protocol specifications. In the current implementation, it may be chosen to use full HELLO's. It is also chosen not to use link-layer notifications. However, as is mentioned elsewhere on the list (by Laurent), another possible choise would be to include link-layer notifications and trigger partial HELLO's as a result hereof. While not provided by the implementation you are using, it cirtainly is permitted by the protocol specification. -- ------------------------------------------- Thomas Heide Clausen Civilingeniør i Datateknik (cand.polyt) M.Sc in Computer Engineering E-Mail: T.Clausen@computer.org WWW: http://www.cs.auc.dk/~voop ------------------------------------------- From owner-manet@itd.nrl.navy.mil Thu Jan 31 09:32:42 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27695 for ; Thu, 31 Jan 2002 09:32:41 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA10943 for manet-outgoing; Thu, 31 Jan 2002 07:18:26 -0500 (EST) Received: from mailhost.cs.auc.dk (mailhost.cs.auc.dk [130.225.194.6]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA10931 for ; Thu, 31 Jan 2002 07:18:07 -0500 (EST) From: T.Clausen@computer.org Received: from localhost (root@borg.cs.auc.dk [130.225.194.22]) by mailhost.cs.auc.dk (8.12.2/8.12.2) with ESMTP id g0VCHivU007079; Thu, 31 Jan 2002 13:17:49 +0100 (MET) Date: Thu, 31 Jan 2002 13:17:43 +0100 (CET) X-Sender: voop@armada To: MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN cc: "'ogier@erg.sri.com'" , Fred Baker , manet@itd.nrl.navy.mil Subject: Re: performance comparaison between Ad Hoc routing protocols In-Reply-To: <0489A7888F080B4BA73B53F7E145F29A022C9D@LANMHS20.rd.francetelecom.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Scanned-By: MIMEDefang 2.2 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8BIT There is a paper, including comparisons between AODV and OLSR: 'The Optimized Link State Routing Protocol, Evaluation through Experiments and Simulation' T.H. Clausen, G. Hansen, L. Christensen and G. Behrmann, IEEE Symposium on "Wireless Personal Mobile Communications", september 2001. It can be found here: http://menetou.inria.fr/olsr/ --thomas On Wed, 23 Jan 2002, MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN wrote: > hi all body > is there any new studies wich made a comparaison between all routing > protocols (espicially AODV and OLSR) . > thank you > best regards > > -- ------------------------------------------- Thomas Heide Clausen Civilingeniør i Datateknik (cand.polyt) M.Sc in Computer Engineering E-Mail: T.Clausen@computer.org WWW: http://www.cs.auc.dk/~voop ------------------------------------------- From owner-manet@itd.nrl.navy.mil Thu Jan 31 10:15:01 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28928 for ; Thu, 31 Jan 2002 10:15:01 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA11976 for manet-outgoing; Thu, 31 Jan 2002 07:52:43 -0500 (EST) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA11971 for ; Thu, 31 Jan 2002 07:52:40 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id EAA21375; Thu, 31 Jan 2002 04:51:45 -0800 (PST) Message-Id: <200201311251.EAA21375@pit.erg.sri.com> To: Laurent.Viennot@inria.fr cc: ogier@erg.sri.com, manet@itd.nrl.navy.mil Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: Manet flooding / broadcasting.... In-reply-to: Your message of "Thu, 31 Jan 2002 11:09:59 +0100." <15449.6135.411716.804489@impression.inria.fr> Date: Thu, 31 Jan 2002 04:51:44 -0800 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Laurent, > Dear Richard, > > Please take a look at previous mail about partial HELLOs in OLSR. I > have to correct some points you mention here about OLSR that are wrong. See below. > > laurent > > ogier@erg.sri.com writes: > > > > > ----- Original Message ----- > > > From: > > > To: > > > Cc: > > > Sent: Tuesday, January 29, 2002 8:58 PM > > > Subject: Re: Manet flooding / broadcasting.... > > > > > > > > > > > > > > Since HELLOs are differential in TBRPF, this can be done with a > > > > relatively small increase in overhead. However, in OSPF and OLSR, > > > > since each HELLO contains all neighbor IDs, this would increase > > > > overhead a lot if each node has a large number of neighbors. > > > > > > > Richard, again, OLSR HELLOs can be partial, you only need to refresh all > > > neighbors within a certain period, and you can increase the hello rate for > > > fast moving node. I think Laurent mentioned this to you before. > > > > Philippe, > > > > Yes, I know that HELLOs can be partial and that each neighbor must be > > included in at least one HELLO every HELLO interval, but unless there > > are too many neighbor IDs to fit into one packet, normally OLSR uses one > > full HELLO per HELLO interval. (Just check the source code.) > > > > In the released code yes but the draft allows to do differently. > > > But this does not affect my argument. What I am saying is that OLSR > > must include each neighbor in a HELLO every HELLO_INTERVAL, whereas > > TBRPF includes each neighbor only in periodic topology updates, which are > > less frequent (e.g., 10 times less frequent if the HELLO_INTERVAL is 0.5 s > > and the update period is 5 s). > > > > It is the HELLO_INTERVAL that determines how quickly a failed link is > > detected, e.g., if no HELLO is received within 3 * HELLO_INTERVAL, then > > the neighbor is declared to be lost. > > > > No, with link hysteresis, you can detect the loss of packet also through > missing sequence numbers. Right (that's why I wrote "e.g."). But this has no effect on my main point, which is that differential HELLOs can save bandwidth. > > I also know that OLSR can use differential HELLOs, > > since it has recently added the LOST_LINK status (which TBRPF has > > had since version 01). *But this does not change the requirement that > > in OLSR each neighbor ID must be included in at least one HELLO every > > HELLO_INTERVAL.* > > No, LOST_LINK status is mentioned since version 02 of the OLSR draft > and was included in HIPERLAN type 1 standard, so it is an old idea. You are right that OLSR *mentioned* the LOST_LINK status before, but it did not actually use it in HELLOs. Richard > > > in OLSR each neighbor ID must be included in at least one HELLO every > > HELLO_INTERVAL.* You can increase HELLO_INTERVAL, but then it > > would take longer to detect a lost neighbor. OLSR could be *modified* > > so that each neighbor ID is reported less frequently than HELLO_INTERVAL > > (as in TBRPF), but I am not sure how this would affect MPR computation. > > > > > However don't forget that even the overhead of an empty HELLO can be non > > > negligible. In IEEE 802.11 the MAC-PHY overhead is around 192 usec (with > > > option to 92 usec) which at 11 Mbps corresponds to approximately 60 IPv4 > > > addresses. > > > > Yes, this is a good point. With the 92 usec option, this becomes about 30 > > IPv4 addresses (or router IDs). So if a node has 30 neighbors, then a full > > HELLO is about twice as big as an empty HELLO. I think that's significant. > > > > There are lots of differences between TBRPF and OLSR that can affect > > performance, and we have already discussed many of these. > > But it is difficult to predict how these differences affect performance. > > That's what simulations are for. > > > > Regards, > > Richard > > From owner-manet@itd.nrl.navy.mil Thu Jan 31 11:35:46 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02417 for ; Thu, 31 Jan 2002 11:35:46 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA14307 for manet-outgoing; Thu, 31 Jan 2002 08:56:47 -0500 (EST) Received: from mailhost.cs.auc.dk (mailhost.cs.auc.dk [130.225.194.6]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA14302 for ; Thu, 31 Jan 2002 08:56:44 -0500 (EST) From: T.Clausen@computer.org Received: from localhost (root@borg.cs.auc.dk [130.225.194.22]) by mailhost.cs.auc.dk (8.12.2/8.12.2) with ESMTP id g0VDubvU015434; Thu, 31 Jan 2002 14:56:40 +0100 (MET) Date: Thu, 31 Jan 2002 14:56:37 +0100 (CET) X-Sender: voop@armada To: manet@itd.nrl.navy.mil cc: ogier@erg.sri.com Subject: Re: Manet flooding / broadcasting.... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Scanned-By: MIMEDefang 2.2 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8BIT Richard, (Sorry, Richard, for sending this twice. I forgot to Cc. the manet list the first time. My mistake) On Thu, 31 Jan 2002 ogier@erg.sri.com wrote: > > Thomas, > > > > Philippe, > > > > > > Yes, I know that HELLOs can be partial and that each neighbor must be > > > included in at least one HELLO every HELLO interval, but unless there > > > are too many neighbor IDs to fit into one packet, normally OLSR uses one > > > full HELLO per HELLO interval. (Just check the source code.) > > > > Richard, > > > > Please keep seperate implementation choises from protocol specifications. > > > > In the current implementation, it may be chosen to use full HELLO's. It > > is also chosen not to use link-layer notifications. However, as is > > mentioned elsewhere on the list (by Laurent), another possible choise > > would be to include link-layer notifications and trigger partial HELLO's > > as a result hereof. > > > > While not provided by the implementation you are using, it cirtainly is > > permitted by the protocol specification. > > I guess my statement above was not clear. > I was NOT precluding the possibility of sending partial HELLOs > indicating LOST neighbors, in *addition* to sending one > full HELLO per HELLO interval. > I was just saying that, if the number of neighbors is not > too large, they would normally be reported in a single full HELLO > (to minimize overhead) rather than in multiple partial HELLOs. > Actually, you are not even required to send any "full" HELLO's periodically. Just to refresh: the rule is, that within NEIGHB_HOLD_TIME information about each node must be transmitted at least once. Thus, as you propose, one (correct) implementation could periodically send "full" HELLO's and - as needed - send additional HELLO's, e.g. to indicate status change of a link. This would be a perfectly valid implementation. However if a neighbor has been reported in such a "non-periodic" additional HELLO-message, it is not required to include that neighbor in the following "periodic" HELLO-message. I.e. the "periodic" HELLO-messages would not necessarilly be "full". This would also be a perfectly valid implementation. Of course I agree that, in general, it makes sense to consider the overhead of transmitting a message on a given medium: when accessing the medium, it makes sense to accomodate the "overhead" of doing so by transmitting a reasonable amount of information. So a "smart" OLSR- implementation would take advantage of the transmission of an "additional" HELLO-message (reporting a neighbor link status change) to include refreshing of other, non-changed links. This would then further reduce the size of any "periodic" HELLO-messages - if not elliminate them completely. This too would make a valid implementation. However all this mostly concirns implementation choises, and may be dictated by different needs in a specific network. -- ------------------------------------------- Thomas Heide Clausen Civilingeniør i Datateknik (cand.polyt) M.Sc in Computer Engineering E-Mail: T.Clausen@computer.org WWW: http://www.cs.auc.dk/~voop ------------------------------------------- From owner-manet@itd.nrl.navy.mil Thu Jan 31 11:48:22 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02891 for ; Thu, 31 Jan 2002 11:48:22 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA16330 for manet-outgoing; Thu, 31 Jan 2002 09:40:30 -0500 (EST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA16323 for ; Thu, 31 Jan 2002 09:40:27 -0500 (EST) Received: from impression.inria.fr (impression.inria.fr [128.93.17.98]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g0VEeKD09142; Thu, 31 Jan 2002 15:40:20 +0100 (MET) Received: by impression.inria.fr (sSMTP sendmail emulation); Thu, 31 Jan 2002 15:40:14 +0100 From: Laurent Viennot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15449.22350.925104.777396@impression.inria.fr> Date: Thu, 31 Jan 2002 15:40:14 +0100 To: ogier@erg.sri.com Cc: manet@itd.nrl.navy.mil Subject: Re: Partial HELLOs vs. differential HELLOs In-Reply-To: <200201311251.EAA21375@pit.erg.sri.com> References: <15449.6135.411716.804489@impression.inria.fr> <200201311251.EAA21375@pit.erg.sri.com> X-Mailer: VM 6.92 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-To: Laurent.Viennot@inria.fr Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Dear Richard, I still disagree. ogier@erg.sri.com writes: > > > > > No, with link hysteresis, you can detect the loss of packet also through > > missing sequence numbers. > > Right (that's why I wrote "e.g."). > But this has no effect on my main point, which > is that differential HELLOs can save bandwidth. > I don't think that sending almost empty packets is a gain of bandwidth. If you want to say I am alive, any control packet is good for that and will carry more valuable information. Link hysteresis allows to consider any control packet as a << I am alive >> packet. > > No, LOST_LINK status is mentioned since version 02 of the OLSR draft > > and was included in HIPERLAN type 1 standard, so it is an old idea. > > You are right that OLSR *mentioned* the LOST_LINK status before, > but it did not actually use it in HELLOs. > It was used in the implementation released for draft 03 (even if this implementation is very basic and do not take advantage of all OLSR features), it is just a matter of maturation of the draft. I think our misunderstanding comes from different views of neighbor sensing. There are many features in neighbor sensing : - 1 - detecting new neighbors - 2 - checking bi-directionality of links - 3 - detecting link breakage - 4 - advertising list of neighbors From your point of view 1,2,3 is done through Hello messages and 4 through Topology updates. From the OLSR point of view 1,2,4 is done through Hello messages, and 3 is done through link hysteresis which uses all control messages and possibly link layer notifications. Wether 4 is part of the neighbor sensing or not can be debated, but it is not very interesting. In OSPF, it is included in both Hello messages and Topology updates. When optimizing bandwidth utilization it is logical to advertise the list only once. The reason for putting 4 in the neighbor sensing in OLSR is that neighbor sensing can be seen as a lower layer that provides also an optimized flooding mechanism. Your point is doing 1 and 3 at a higher rate than 4. Partial HELLOs and link hysteresis allow to do that more efficiently than differential HELLOs because they are more flexible. You can advertise a new neighbor at any time with partial HELLOs, so doing 1 at a higher rate is no problem. As mentioned Thomas, if you send an additional HELLO message then you would probably glue a part of your neighbor list with it to send more information in the packet and save some bandwidth with regards to packet overhead. Doing 3 at a higher rate is implementation dependent and OLSR link hysteresis mechanism is very flexible about that: you can use link layer notification of link breakage, or link layer notification of power level or loss of control messages. For example, if you split your list of neighbors in 10 HELLO messages, you will be able to discover link breakage 10 times quicker than with only 1 HELLO message (at the cost of more overhead). It is logical to send more control data when mobility increases. Partial HELLOs allow to react smoothly. laurent From owner-manet@itd.nrl.navy.mil Thu Jan 31 17:08:47 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14049 for ; Thu, 31 Jan 2002 17:08:47 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA00048 for manet-outgoing; Thu, 31 Jan 2002 14:26:19 -0500 (EST) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA00027; Thu, 31 Jan 2002 14:25:59 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id LAA22142; Thu, 31 Jan 2002 11:24:55 -0800 (PST) Message-Id: <200201311924.LAA22142@pit.erg.sri.com> To: T.Clausen@computer.org cc: Joe Macker , ogier@erg.sri.com, manet@itd.nrl.navy.mil Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: Some follow-up OLSR/AODV results In-reply-to: Your message of "Thu, 31 Jan 2002 13:07:25 +0100." Date: Thu, 31 Jan 2002 11:24:55 -0800 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > On Wed, 30 Jan 2002, Joe Macker wrote: > > > At 12:04 PM 1/30/2002 -0800, ogier@erg.sri.com wrote: > > > > > >different people. I will make some effort to determine the reason for the different results, > > >but I am also re-running the experiments using the ns-2 code available from the INRIA site. > > >Is the Aalborg code exactly the same as the ns-2 code available from the INRIA site? > > > > I don't know that. Perhaps one of the developer's and releasing agents > > could chime in. > > > > The ns2-code, currently available from the INRIA www-site, is equivalent > with what Joe refers to as the Aalborg code. I think I found a bug in that code regarding packet size. (I don't know whether the same bug is in Joe's code or in the code used for simulations that others have done.) When running simulations with that code, I noticed in the trace file that every OLSR packet has length 20 bytes, including the 20-byte IP header (i.e., ns-2 considers each OLSR message to have zero length not including the IP header). So I looked in the file ns-olsragent.cc and noticed the line ch->size() = IP_HDR_LEN; in the sendPacket() function, which explained the bug. I changed the line to ch->size() = IP_HDR_LEN + p->datalen(); which seemed to fix the bug. Am I missing something? Richard From owner-manet@itd.nrl.navy.mil Thu Jan 31 19:21:38 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16266 for ; Thu, 31 Jan 2002 19:21:38 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA06780 for manet-outgoing; Thu, 31 Jan 2002 17:11:08 -0500 (EST) Received: from mailhost2.malibunetworks.com (smtp.malibunet.com [63.150.98.26]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA06775 for ; Thu, 31 Jan 2002 17:11:05 -0500 (EST) Received: by mailhost2.malibunet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 14:12:12 -0800 Message-ID: <337F6EC31C8FD3119A10009027D63D874AD61A@mailhost2.malibunet.com> From: Ken Peirce To: manet@itd.nrl.navy.mil Subject: OpNet v NS-2 results available Date: Thu, 31 Jan 2002 14:12:04 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk All, Anyone interested in the results of the informal survey should email me. I don't want to post to the list and start a war. cheers, Ken From owner-manet@itd.nrl.navy.mil Thu Jan 31 21:19:55 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17657 for ; Thu, 31 Jan 2002 21:19:55 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA10107 for manet-outgoing; Thu, 31 Jan 2002 19:12:25 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id TAA10098; Thu, 31 Jan 2002 19:12:20 -0500 (EST) Message-Id: <5.0.1.4.2.20020131174924.02e6e100@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 31 Jan 2002 19:21:16 -0500 To: ogier@erg.sri.com, T.Clausen@computer.org From: Joe Macker Subject: Re: Some follow-up OLSR/AODV results Cc: manet@itd.nrl.navy.mil In-Reply-To: <200201311924.LAA22142@pit.erg.sri.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > >in the sendPacket() function, which explained the bug. I changed the line to > > ch->size() = IP_HDR_LEN + p->datalen(); > >which seemed to fix the bug. Am I missing something? Richard: Good catch, I also believe this a bug. I checked prototype olsrv4 ns2 code we developed here and it does not have this bug (it was independently developed from the INRIA code). I will add your fix and doublecheck my previous snapshot scenarios with both pieces of code. The initial points are still looking similar from running our code, although this is a third piece of code (its going to take awhile to get the full curves again).. From owner-manet@itd.nrl.navy.mil Thu Jan 31 23:00:55 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21027 for ; Thu, 31 Jan 2002 23:00:55 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA12436 for manet-outgoing; Thu, 31 Jan 2002 20:59:37 -0500 (EST) Received: from fluorine.mcis.singnet.com.sg (fluorine.singnet.com.sg [165.21.74.72]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id UAA12430; Thu, 31 Jan 2002 20:59:32 -0500 (EST) From: ogier@erg.sri.com Received: from mail pickup service by fluorine.mcis.singnet.com.sg with Microsoft SMTPSVC; Fri, 1 Feb 2002 09:47:04 +0800 Received: from mx16.singnet.com.sg ([165.21.74.116]) by fluorine.mcis.singnet.com.sg with Microsoft SMTPSVC(5.5.1877.687.68); Fri, 1 Feb 2002 06:19:41 +0800 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by mx16.singnet.com.sg (8.12.2/8.12.2) with ESMTP id g0VMJcba017735; Fri, 1 Feb 2002 06:19:39 +0800 Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA00048 for manet-outgoing; Thu, 31 Jan 2002 14:26:19 -0500 (EST) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA00027; Thu, 31 Jan 2002 14:25:59 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id LAA22142; Thu, 31 Jan 2002 11:24:55 -0800 (PST) Message-Id: <200201311924.LAA22142@pit.erg.sri.com> To: T.Clausen@computer.org cc: Joe Macker , ogier@erg.sri.com, manet@itd.nrl.navy.mil Reply-To: ogier@erg.sri.com Subject: Re: Some follow-up OLSR/AODV results In-reply-to: Your message of "Thu, 31 Jan 2002 13:07:25 +0100." Date: Thu, 31 Jan 2002 11:24:55 -0800 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > On Wed, 30 Jan 2002, Joe Macker wrote: > > > At 12:04 PM 1/30/2002 -0800, ogier@erg.sri.com wrote: > > > > > >different people. I will make some effort to determine the reason for the different results, > > >but I am also re-running the experiments using the ns-2 code available from the INRIA site. > > >Is the Aalborg code exactly the same as the ns-2 code available from the INRIA site? > > > > I don't know that. Perhaps one of the developer's and releasing agents > > could chime in. > > > > The ns2-code, currently available from the INRIA www-site, is equivalent > with what Joe refers to as the Aalborg code. I think I found a bug in that code regarding packet size. (I don't know whether the same bug is in Joe's code or in the code used for simulations that others have done.) When running simulations with that code, I noticed in the trace file that every OLSR packet has length 20 bytes, including the 20-byte IP header (i.e., ns-2 considers each OLSR message to have zero length not including the IP header). So I looked in the file ns-olsragent.cc and noticed the line ch->size() = IP_HDR_LEN; in the sendPacket() function, which explained the bug. I changed the line to ch->size() = IP_HDR_LEN + p->datalen(); which seemed to fix the bug. Am I missing something? Richard