From mailman-owner@ietf.org Wed May 1 06:41:23 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 GAA17335 for ; Wed, 1 May 2002 06:41:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08561 for ; Wed, 1 May 2002 06:41:25 -0400 (EDT) Date: Wed, 1 May 2002 06:41:25 -0400 (EDT) Message-Id: <200205011041.GAA08561@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: manet-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, manet-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for manet-archive@lists.ietf.org: List Password // URL ---- -------- manet@ietf.org FtOz https://www1.ietf.org/mailman/options/manet/manet-archive@lists.ietf.org From manet-admin@ietf.org Wed May 1 11:32:46 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 LAA03408 for ; Wed, 1 May 2002 11:32:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18546; Wed, 1 May 2002 10:55:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18512 for ; Wed, 1 May 2002 10:55:11 -0400 (EDT) Received: from amber.ccs.neu.edu (postfix@amber.ccs.neu.edu [129.10.116.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01466 for ; Wed, 1 May 2002 10:55:00 -0400 (EDT) Received: from CASABLANCA.ccs.neu.edu (casablanca.ccs.neu.edu [129.10.118.188]) by amber.ccs.neu.edu (Postfix) with ESMTP id DFB911AA8B; Wed, 1 May 2002 10:54:29 -0400 (EDT) Message-Id: <5.0.2.1.0.20020501104540.0328ceb0@mail.ccs.neu.edu> X-Sender: noubir@mail.ccs.neu.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 01 May 2002 10:45:48 -0400 To: manet@ietf.org From: "G. Noubir" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [manet] CFP: Workshop on Wireless Security (in conjunction with MobiCom 2002) 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 ----------------------------------------------------------------------- Please Accept Our Sincere Apologies Should you Receive Multiple Copies of this CFP ----------------------------------------------------------------------- Call for Papers Workshop on Wireless Security (WiSe) in conjunction with ACM MobiCom 2002 September 28, 2002 Atlanta, Georgia, U.S.A. http://www.crhc.uiuc.edu/~nhv/wise Sponsored by SIGMOBILE (pending) A workshop on Wireless Security will be held in conjunction with ACM MobiCom 2002. The objective of this workshop is to bring together researchers from research communities in wireless networking, security, and dependability, with the goal of fostering interaction among them. With the increasing reliance on wireless networks, issues related to secure and dependable operation of such networks are gaining importance. Topics of interest include, but are not limited to: * Key management in wireless/mobile environments * Intrusion detection * Secure MAC protocols * Secure routing * Denial of service * Privacy and anonymity * Prevention of traffic analysis * Dependable wireless networking * Monitoring and surveillance * Disaster response Paper submission instructions: Submission of papers based on work-in-progress is encouraged. Submitted papers must not be previously published elsewhere or currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs. All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their paper. Papers must meet the following restrictions: No longer than 10 pages (single or double column); in font no smaller than 11 points; must fit properly on US Letter-sized paper (8.5 inch x 11 inch) with reasonable margins. Instructions for electronic submission of papers will be posted at http://www.crhc.uiuc.edu/~nhv/wise/submission.html. Important dates: Paper submissions due: May 20, 2002 Notification of acceptance: July 5, 2002 Camera-ready papers due: July 31, 2002 Workshop date: September 28, 2002 Workshop Co-Chairs: * Douglas Maughan, Defense Advanced Research Projects Agency (dmaughan@darpa.mil) * Nitin Vaidya, University of Illinois at Urbana-Champaign (nhv@uiuc.edu) Program Committee: Yair Amir, Johns Hopkins University Pete Dinsmore, NAI Chip Elliott, BBN Technologies Zygmunt Haas, Cornell University Jean-Pierre Hubaux, EPFL-Lausanne David B. Johnson, Rice University Douglas Maughan, Defense Advanced Research Projects Agency (co-chair) Brian Noble, University of Michigan Ranga Ramanujan, Architecture Technology Corporation Frank Stajano, University of Cambridge Brian Van Leeuwen, Sandia National Laboratories Nitin Vaidya, University of Illinois at Urbana-Champaign (co-chair) Wei Zhao, Texas A&M University Taieb Znati, National Science Foundation, and University of Pittsburgh Publicity Co-Chairs: Mohsen Guizani, University of West Florida Guevara Noubir, Northeastern University Publication Chair: Saad Biaz, Auburn University Registration Chair: Robin Kravets, University of Illinois at Urbana-Champaign _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed May 1 11:32:47 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 LAA03425 for ; Wed, 1 May 2002 11:32:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21300 for manet-archive@odin.ietf.org; Wed, 1 May 2002 11:32:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18546; Wed, 1 May 2002 10:55:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18512 for ; Wed, 1 May 2002 10:55:11 -0400 (EDT) Received: from amber.ccs.neu.edu (postfix@amber.ccs.neu.edu [129.10.116.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01466 for ; Wed, 1 May 2002 10:55:00 -0400 (EDT) Received: from CASABLANCA.ccs.neu.edu (casablanca.ccs.neu.edu [129.10.118.188]) by amber.ccs.neu.edu (Postfix) with ESMTP id DFB911AA8B; Wed, 1 May 2002 10:54:29 -0400 (EDT) Message-Id: <5.0.2.1.0.20020501104540.0328ceb0@mail.ccs.neu.edu> X-Sender: noubir@mail.ccs.neu.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 01 May 2002 10:45:48 -0400 To: manet@ietf.org From: "G. Noubir" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [manet] CFP: Workshop on Wireless Security (in conjunction with MobiCom 2002) 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 ----------------------------------------------------------------------- Please Accept Our Sincere Apologies Should you Receive Multiple Copies of this CFP ----------------------------------------------------------------------- Call for Papers Workshop on Wireless Security (WiSe) in conjunction with ACM MobiCom 2002 September 28, 2002 Atlanta, Georgia, U.S.A. http://www.crhc.uiuc.edu/~nhv/wise Sponsored by SIGMOBILE (pending) A workshop on Wireless Security will be held in conjunction with ACM MobiCom 2002. The objective of this workshop is to bring together researchers from research communities in wireless networking, security, and dependability, with the goal of fostering interaction among them. With the increasing reliance on wireless networks, issues related to secure and dependable operation of such networks are gaining importance. Topics of interest include, but are not limited to: * Key management in wireless/mobile environments * Intrusion detection * Secure MAC protocols * Secure routing * Denial of service * Privacy and anonymity * Prevention of traffic analysis * Dependable wireless networking * Monitoring and surveillance * Disaster response Paper submission instructions: Submission of papers based on work-in-progress is encouraged. Submitted papers must not be previously published elsewhere or currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs. All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their paper. Papers must meet the following restrictions: No longer than 10 pages (single or double column); in font no smaller than 11 points; must fit properly on US Letter-sized paper (8.5 inch x 11 inch) with reasonable margins. Instructions for electronic submission of papers will be posted at http://www.crhc.uiuc.edu/~nhv/wise/submission.html. Important dates: Paper submissions due: May 20, 2002 Notification of acceptance: July 5, 2002 Camera-ready papers due: July 31, 2002 Workshop date: September 28, 2002 Workshop Co-Chairs: * Douglas Maughan, Defense Advanced Research Projects Agency (dmaughan@darpa.mil) * Nitin Vaidya, University of Illinois at Urbana-Champaign (nhv@uiuc.edu) Program Committee: Yair Amir, Johns Hopkins University Pete Dinsmore, NAI Chip Elliott, BBN Technologies Zygmunt Haas, Cornell University Jean-Pierre Hubaux, EPFL-Lausanne David B. Johnson, Rice University Douglas Maughan, Defense Advanced Research Projects Agency (co-chair) Brian Noble, University of Michigan Ranga Ramanujan, Architecture Technology Corporation Frank Stajano, University of Cambridge Brian Van Leeuwen, Sandia National Laboratories Nitin Vaidya, University of Illinois at Urbana-Champaign (co-chair) Wei Zhao, Texas A&M University Taieb Znati, National Science Foundation, and University of Pittsburgh Publicity Co-Chairs: Mohsen Guizani, University of West Florida Guevara Noubir, Northeastern University Publication Chair: Saad Biaz, Auburn University Registration Chair: Robin Kravets, University of Illinois at Urbana-Champaign _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 1 16:47:10 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 QAA00178 for ; Wed, 1 May 2002 16:47:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04617; Wed, 1 May 2002 15:22:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04575 for ; Wed, 1 May 2002 15:22:46 -0400 (EDT) Received: from cs.tamu.edu (IDENT:0@mailhost.cs.tamu.edu [128.194.130.106]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21474 for ; Wed, 1 May 2002 15:22:41 -0400 (EDT) Received: from dogbert.cs.tamu.edu (IDENT:4054@dogbert [128.194.130.18]) by cs.tamu.edu (8.11.0/8.11.0) with ESMTP id g41JMiO25874 for ; Wed, 1 May 2002 14:22:44 -0500 (CDT) Received: from localhost (b0l4549@localhost) by dogbert.cs.tamu.edu (8.11.0/8.11.0) with ESMTP id g41JMhm06755 for ; Wed, 1 May 2002 14:22:43 -0500 (CDT) X-Authentication-Warning: dogbert.cs.tamu.edu: b0l4549 owned process doing -bs Date: Wed, 1 May 2002 14:22:43 -0500 (CDT) From: Bin - Lu X-Sender: b0l4549@dogbert To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] ns code for aodv qos? 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 Hi, Does anyone know if there is any NS-2 code for AODV QoS that I could use? I'd appreciate it a lot! Bin Lu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 1 16:47:16 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 QAA00191 for ; Wed, 1 May 2002 16:47:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA08709 for manet-archive@odin.ietf.org; Wed, 1 May 2002 16:47:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04617; Wed, 1 May 2002 15:22:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04575 for ; Wed, 1 May 2002 15:22:46 -0400 (EDT) Received: from cs.tamu.edu (IDENT:0@mailhost.cs.tamu.edu [128.194.130.106]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21474 for ; Wed, 1 May 2002 15:22:41 -0400 (EDT) Received: from dogbert.cs.tamu.edu (IDENT:4054@dogbert [128.194.130.18]) by cs.tamu.edu (8.11.0/8.11.0) with ESMTP id g41JMiO25874 for ; Wed, 1 May 2002 14:22:44 -0500 (CDT) Received: from localhost (b0l4549@localhost) by dogbert.cs.tamu.edu (8.11.0/8.11.0) with ESMTP id g41JMhm06755 for ; Wed, 1 May 2002 14:22:43 -0500 (CDT) X-Authentication-Warning: dogbert.cs.tamu.edu: b0l4549 owned process doing -bs Date: Wed, 1 May 2002 14:22:43 -0500 (CDT) From: Bin - Lu X-Sender: b0l4549@dogbert To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] ns code for aodv qos? 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 Hi, Does anyone know if there is any NS-2 code for AODV QoS that I could use? I'd appreciate it a lot! Bin Lu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 2 02:08: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 CAA20700 for ; Thu, 2 May 2002 02:08:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09856; Thu, 2 May 2002 01:18:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09826 for ; Thu, 2 May 2002 01:18:22 -0400 (EDT) Received: from mailgw2.atr.co.jp (ns2p.atr.co.jp [210.166.163.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07264 for ; Thu, 2 May 2002 01:18:16 -0400 (EDT) Received: from vcms.atr.co.jp (epsilon.atr.co.jp [133.186.254.10]) by mailgw2.atr.co.jp (Postfix) with ESMTP id 1FF6618AC3 for ; Thu, 2 May 2002 14:17:48 +0900 (JST) Received: from acr.acr.atr.co.jp (localhost [127.0.0.1]) by vcms.atr.co.jp (Postfix) with ESMTP id 561313978E for ; Thu, 2 May 2002 14:17:47 +0900 (JST) Received: from rpc41 by acr.acr.atr.co.jp (8.9.3/3.7W) id OAA05591; Thu, 2 May 2002 14:17:46 +0900 (JST) From: "Shingo HORISAWA" To: "MANET Mailing List" Date: Thu, 2 May 2002 14:17:24 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [manet] FSR operation when a link breakage occurs. 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 Content-Transfer-Encoding: 7bit Hi, all. I'm interested in FSR ( or GSR). So, I would like to know the details that I couldn't read from Internet-Draft and papers. My question is as follows; (1) I want to know the contents of the fields of each table concretely. (2) When there are a link breakage or topology changes, which entry in the topology table is deleted, and how? Regards, ----- Shingo Horisawa _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu May 2 02:08:13 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 CAA20715 for ; Thu, 2 May 2002 02:08:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA12384 for manet-archive@odin.ietf.org; Thu, 2 May 2002 02:08:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09856; Thu, 2 May 2002 01:18:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09826 for ; Thu, 2 May 2002 01:18:22 -0400 (EDT) Received: from mailgw2.atr.co.jp (ns2p.atr.co.jp [210.166.163.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07264 for ; Thu, 2 May 2002 01:18:16 -0400 (EDT) Received: from vcms.atr.co.jp (epsilon.atr.co.jp [133.186.254.10]) by mailgw2.atr.co.jp (Postfix) with ESMTP id 1FF6618AC3 for ; Thu, 2 May 2002 14:17:48 +0900 (JST) Received: from acr.acr.atr.co.jp (localhost [127.0.0.1]) by vcms.atr.co.jp (Postfix) with ESMTP id 561313978E for ; Thu, 2 May 2002 14:17:47 +0900 (JST) Received: from rpc41 by acr.acr.atr.co.jp (8.9.3/3.7W) id OAA05591; Thu, 2 May 2002 14:17:46 +0900 (JST) From: "Shingo HORISAWA" To: "MANET Mailing List" Date: Thu, 2 May 2002 14:17:24 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [manet] FSR operation when a link breakage occurs. 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 Content-Transfer-Encoding: 7bit Hi, all. I'm interested in FSR ( or GSR). So, I would like to know the details that I couldn't read from Internet-Draft and papers. My question is as follows; (1) I want to know the contents of the fields of each table concretely. (2) When there are a link breakage or topology changes, which entry in the topology table is deleted, and how? Regards, ----- Shingo Horisawa _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 2 08:26:34 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 IAA18029 for ; Thu, 2 May 2002 08:26:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29929; Thu, 2 May 2002 07:54:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29903 for ; Thu, 2 May 2002 07:54:19 -0400 (EDT) Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15261 for ; Thu, 2 May 2002 07:54:15 -0400 (EDT) Received: from schaula (dhcp162-225.enst.fr [137.194.162.225]) by infres.enst.fr (Postfix) with SMTP id 2D2B8193F for ; Thu, 2 May 2002 13:54:15 +0200 (MEST) Message-ID: <002101c1f1d1$258dbf70$e1a2c289@galaxy.enst.fr> From: "Moustafa Hasnaa" To: Date: Thu, 2 May 2002 14:01:50 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C1F1E1.E844C080" 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 Subject: [manet] DSR Implementation 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 C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_001E_01C1F1E1.E844C080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Does anyone know if there is a recent implementation available for DSR = protocol, which is tested before ??? =20 Thanks ------=_NextPart_000_001E_01C1F1E1.E844C080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 Does anyone know if = there is a=20 recent implementation available for DSR protocol, which is tested before = ??? 
 
Thanks
------=_NextPart_000_001E_01C1F1E1.E844C080-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu May 2 08:26:34 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 IAA18040 for ; Thu, 2 May 2002 08:26:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA02419 for manet-archive@odin.ietf.org; Thu, 2 May 2002 08:26:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29929; Thu, 2 May 2002 07:54:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29903 for ; Thu, 2 May 2002 07:54:19 -0400 (EDT) Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15261 for ; Thu, 2 May 2002 07:54:15 -0400 (EDT) Received: from schaula (dhcp162-225.enst.fr [137.194.162.225]) by infres.enst.fr (Postfix) with SMTP id 2D2B8193F for ; Thu, 2 May 2002 13:54:15 +0200 (MEST) Message-ID: <002101c1f1d1$258dbf70$e1a2c289@galaxy.enst.fr> From: "Moustafa Hasnaa" To: Date: Thu, 2 May 2002 14:01:50 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C1F1E1.E844C080" 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 Subject: [manet] DSR Implementation 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 C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_001E_01C1F1E1.E844C080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Does anyone know if there is a recent implementation available for DSR = protocol, which is tested before ??? =20 Thanks ------=_NextPart_000_001E_01C1F1E1.E844C080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 Does anyone know if = there is a=20 recent implementation available for DSR protocol, which is tested before = ??? 
 
Thanks
------=_NextPart_000_001E_01C1F1E1.E844C080-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 2 09:47:11 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 JAA25549 for ; Thu, 2 May 2002 09:47:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05753; Thu, 2 May 2002 09:13:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05727 for ; Thu, 2 May 2002 09:13:21 -0400 (EDT) Received: from uria.its.uu.se (uria.its.UU.SE [130.238.7.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22201 for ; Thu, 2 May 2002 09:13:11 -0400 (EDT) Received: from dhcp-14-218.it.uu.se ([130.238.14.218]:33355 "EHLO genesis") by uria.its.uu.se with ESMTP id convert rfc822-to-8bit; Thu, 2 May 2002 15:09:20 +0200 Received: from cray (helo=localhost) by genesis with local-esmtp (Exim 3.35 #1 (Debian)) id 173GLa-0000dP-00; Thu, 02 May 2002 15:10:10 +0200 Date: Thu, 2 May 2002 15:10:10 +0200 (CEST) From: Stefan Lindstrom X-X-Sender: cray@fortress.se To: Moustafa Hasnaa cc: manet@ietf.org Subject: Re: [manet] DSR Implementation In-Reply-To: <002101c1f1d1$258dbf70$e1a2c289@galaxy.enst.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT 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 Content-Transfer-Encoding: 8BIT > Does anyone know if there is a recent implementation available for DSR > protocol, which is tested before ??? No, but I'm currently developing a DSR implementation as my master thesis. But I still in a very early stage right now and I expect a time frame of at least a month before it will be in some kind of a runnable state. -- Stefan Lindström email: stli3993@csd.uu.se homepage: http://www.csd.uu.se/~stli3993/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu May 2 09:47: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 JAA25563 for ; Thu, 2 May 2002 09:47:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08124 for manet-archive@odin.ietf.org; Thu, 2 May 2002 09:47:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05753; Thu, 2 May 2002 09:13:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05727 for ; Thu, 2 May 2002 09:13:21 -0400 (EDT) Received: from uria.its.uu.se (uria.its.UU.SE [130.238.7.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22201 for ; Thu, 2 May 2002 09:13:11 -0400 (EDT) Received: from dhcp-14-218.it.uu.se ([130.238.14.218]:33355 "EHLO genesis") by uria.its.uu.se with ESMTP id convert rfc822-to-8bit; Thu, 2 May 2002 15:09:20 +0200 Received: from cray (helo=localhost) by genesis with local-esmtp (Exim 3.35 #1 (Debian)) id 173GLa-0000dP-00; Thu, 02 May 2002 15:10:10 +0200 Date: Thu, 2 May 2002 15:10:10 +0200 (CEST) From: Stefan Lindstrom X-X-Sender: cray@fortress.se To: Moustafa Hasnaa cc: manet@ietf.org Subject: Re: [manet] DSR Implementation In-Reply-To: <002101c1f1d1$258dbf70$e1a2c289@galaxy.enst.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT 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 Content-Transfer-Encoding: 8BIT > Does anyone know if there is a recent implementation available for DSR > protocol, which is tested before ??? No, but I'm currently developing a DSR implementation as my master thesis. But I still in a very early stage right now and I expect a time frame of at least a month before it will be in some kind of a runnable state. -- Stefan Lindström email: stli3993@csd.uu.se homepage: http://www.csd.uu.se/~stli3993/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 2 14:14:07 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 OAA21562 for ; Thu, 2 May 2002 14:14:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23921; Thu, 2 May 2002 13:45:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23892 for ; Thu, 2 May 2002 13:44:56 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18262 for ; Thu, 2 May 2002 13:44:51 -0400 (EDT) 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 KAA04456; Thu, 2 May 2002 10:42:23 -0700 (PDT) Message-Id: <200205021742.KAA04456@pit.erg.sri.com> To: Fred Baker cc: ogier@erg.sri.com, manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Re: IPR issue for TBRPF In-reply-to: Your message of "Mon, 29 Apr 2002 12:58:41 PDT." <5.1.0.14.2.20020429125125.01af1910@mira-sjcm-4.cisco.com> Date: Thu, 02 May 2002 10:42:22 -0700 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 Fred, > My observation is my own, nobody else's, but it comes from someone > who has been watching the IETF for a *long* time. If you want to > guarantee a > scramble, say the word "patent", and if you want to > guarantee that the IETF > will proceed in a direction only under > duress, apply for one. Let me quote a sentence from "A Novice's Guide to the IETF" http://www.imc.org/novice-ietf.html "Sometimes, the patent holder is generous and promises to give all implementors of a standard a royalty-free license to the patent, thereby making it almost as easy to implement as it would have been if no patent existed." That is exactly what SRI is doing. Our IPR statement contains the following sentence: "If SRI's submission (or portions thereof) is accepted and becomes part of the IETF standard, then SRI will grant any party a royalty-free license under such patents for both commercial and non-commercial uses, to the extent necessary for compliance with the standard." Also note that ISATAP (in the NGTRANS WG) has exactly the same IPR statement as TBRPF: http://www.ietf.org/ietf/IPR/ISI-NGTRANS.txt This issue has been discussed previously on this list, e.g., see Ken Peirce's message dated 12/13/01. Also, in a recent email from Ken to you (Ken, you can chime in if you want), he pointed out that the patent (if awarded) is actually a *bonus* to TBRPF implementors, since SRI will give all implementors a royalty-free license if TBRPF becomes a standard. As Ken noted (and our lawyer agrees), in addition to guaranteeing that TBRPF will be unencumbered, it also provides some protection to TBRPF implementors from 3rd party infringement lawsuits. In your response to Ken, you stated that it is very unlikely that our lawyers will let us concede our rights to TBPRF. This is not true. In fact our lawyers are the ones who wrote the IPR statement. Our lawyers are currently updating the IPR statement to clarify that anyone can implement TBRPF for non-commercial research purposes while TBRPF is being considered by the IETF, as requested by Joe Macker. (The updated statement will be submitted to the IETF in a few days.) Now, if OLSR and TBRPF turn out to be equally good protocols for proactive routing in MANETs, then it would make sense to select the one that has no IPRs. But *so far*, TBRPF has outperformed OLSR significantly in our simulations (and has other advantages that I have previously discussed). These simulations are based on the OLSR code that is available from the INRIA web site, which has been outdated for several months (according to Clausen's message dated 11/29/01), so I hope that newer OLSR code will be available soon. Richard P.S. For reference, here is the excerpt from draft-baker-manet-review-01.txt that I think is unfair: "SRI has aggressively marketed TBRPF and its IPRs to the working group. The fact that a patent has been applied for on certain aspects is, however, severely limiting politically. If there is any way in which the IETF is absolutely predictable, it is that when confronted with a choice between a proposal encumbered with IPR issues and an unencumbered proposal, it will choose the unencumbered one." _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu May 2 14:14:08 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 OAA21573 for ; Thu, 2 May 2002 14:14:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26236 for manet-archive@odin.ietf.org; Thu, 2 May 2002 14:14:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23921; Thu, 2 May 2002 13:45:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23892 for ; Thu, 2 May 2002 13:44:56 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18262 for ; Thu, 2 May 2002 13:44:51 -0400 (EDT) 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 KAA04456; Thu, 2 May 2002 10:42:23 -0700 (PDT) Message-Id: <200205021742.KAA04456@pit.erg.sri.com> To: Fred Baker cc: ogier@erg.sri.com, manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Re: IPR issue for TBRPF In-reply-to: Your message of "Mon, 29 Apr 2002 12:58:41 PDT." <5.1.0.14.2.20020429125125.01af1910@mira-sjcm-4.cisco.com> Date: Thu, 02 May 2002 10:42:22 -0700 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 Fred, > My observation is my own, nobody else's, but it comes from someone > who has been watching the IETF for a *long* time. If you want to > guarantee a > scramble, say the word "patent", and if you want to > guarantee that the IETF > will proceed in a direction only under > duress, apply for one. Let me quote a sentence from "A Novice's Guide to the IETF" http://www.imc.org/novice-ietf.html "Sometimes, the patent holder is generous and promises to give all implementors of a standard a royalty-free license to the patent, thereby making it almost as easy to implement as it would have been if no patent existed." That is exactly what SRI is doing. Our IPR statement contains the following sentence: "If SRI's submission (or portions thereof) is accepted and becomes part of the IETF standard, then SRI will grant any party a royalty-free license under such patents for both commercial and non-commercial uses, to the extent necessary for compliance with the standard." Also note that ISATAP (in the NGTRANS WG) has exactly the same IPR statement as TBRPF: http://www.ietf.org/ietf/IPR/ISI-NGTRANS.txt This issue has been discussed previously on this list, e.g., see Ken Peirce's message dated 12/13/01. Also, in a recent email from Ken to you (Ken, you can chime in if you want), he pointed out that the patent (if awarded) is actually a *bonus* to TBRPF implementors, since SRI will give all implementors a royalty-free license if TBRPF becomes a standard. As Ken noted (and our lawyer agrees), in addition to guaranteeing that TBRPF will be unencumbered, it also provides some protection to TBRPF implementors from 3rd party infringement lawsuits. In your response to Ken, you stated that it is very unlikely that our lawyers will let us concede our rights to TBPRF. This is not true. In fact our lawyers are the ones who wrote the IPR statement. Our lawyers are currently updating the IPR statement to clarify that anyone can implement TBRPF for non-commercial research purposes while TBRPF is being considered by the IETF, as requested by Joe Macker. (The updated statement will be submitted to the IETF in a few days.) Now, if OLSR and TBRPF turn out to be equally good protocols for proactive routing in MANETs, then it would make sense to select the one that has no IPRs. But *so far*, TBRPF has outperformed OLSR significantly in our simulations (and has other advantages that I have previously discussed). These simulations are based on the OLSR code that is available from the INRIA web site, which has been outdated for several months (according to Clausen's message dated 11/29/01), so I hope that newer OLSR code will be available soon. Richard P.S. For reference, here is the excerpt from draft-baker-manet-review-01.txt that I think is unfair: "SRI has aggressively marketed TBRPF and its IPRs to the working group. The fact that a patent has been applied for on certain aspects is, however, severely limiting politically. If there is any way in which the IETF is absolutely predictable, it is that when confronted with a choice between a proposal encumbered with IPR issues and an unencumbered proposal, it will choose the unencumbered one." _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 2 15:39:49 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 PAA00112 for ; Thu, 2 May 2002 15:39:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28109; Thu, 2 May 2002 14:47:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28081 for ; Thu, 2 May 2002 14:47:12 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25544 for ; Thu, 2 May 2002 14:47:07 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g42IkOO17781; Thu, 2 May 2002 21:46:24 +0300 Date: Thu, 2 May 2002 21:46:24 +0300 (EEST) From: Pekka Savola To: ogier@erg.sri.com cc: Fred Baker , Subject: Re: [manet] Re: IPR issue for TBRPF In-Reply-To: <200205021742.KAA04456@pit.erg.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Thu, 2 May 2002 ogier@erg.sri.com wrote: > That is exactly what SRI is doing. Our IPR statement contains the > following sentence: "If SRI's submission (or portions thereof) is > accepted and becomes part of the IETF standard, then SRI will grant > any party a royalty-free license under such patents for both > commercial and non-commercial uses, to the extent necessary for > compliance with the standard." > > Also note that ISATAP (in the NGTRANS WG) has exactly the same IPR > statement as TBRPF: http://www.ietf.org/ietf/IPR/ISI-NGTRANS.txt Not so. From the URL: --8<-- [...] Any aspects or variants of SRI's submission that are not included in the IETF standard and/or are not necessary for compliance with the standard may require an additional license from SRI under terms to be negotiated by the parties. --8<-- This can be interpreted that every SHOULD, MAY or an additional draft (as they are not *required* for compliance) is subject to SRI's goodwill and claims in any time in the future. I wish I had known about this before wasting my time on ISATAP. There are no good patents. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu May 2 15:39:50 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 PAA00124 for ; Thu, 2 May 2002 15:39:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA01747 for manet-archive@odin.ietf.org; Thu, 2 May 2002 15:39:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28109; Thu, 2 May 2002 14:47:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28081 for ; Thu, 2 May 2002 14:47:12 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25544 for ; Thu, 2 May 2002 14:47:07 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g42IkOO17781; Thu, 2 May 2002 21:46:24 +0300 Date: Thu, 2 May 2002 21:46:24 +0300 (EEST) From: Pekka Savola To: ogier@erg.sri.com cc: Fred Baker , Subject: Re: [manet] Re: IPR issue for TBRPF In-Reply-To: <200205021742.KAA04456@pit.erg.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Thu, 2 May 2002 ogier@erg.sri.com wrote: > That is exactly what SRI is doing. Our IPR statement contains the > following sentence: "If SRI's submission (or portions thereof) is > accepted and becomes part of the IETF standard, then SRI will grant > any party a royalty-free license under such patents for both > commercial and non-commercial uses, to the extent necessary for > compliance with the standard." > > Also note that ISATAP (in the NGTRANS WG) has exactly the same IPR > statement as TBRPF: http://www.ietf.org/ietf/IPR/ISI-NGTRANS.txt Not so. From the URL: --8<-- [...] Any aspects or variants of SRI's submission that are not included in the IETF standard and/or are not necessary for compliance with the standard may require an additional license from SRI under terms to be negotiated by the parties. --8<-- This can be interpreted that every SHOULD, MAY or an additional draft (as they are not *required* for compliance) is subject to SRI's goodwill and claims in any time in the future. I wish I had known about this before wasting my time on ISATAP. There are no good patents. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 2 17:16:06 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 RAA08827 for ; Thu, 2 May 2002 17:16:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05168; Thu, 2 May 2002 16:47:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05139 for ; Thu, 2 May 2002 16:47:45 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05591 for ; Thu, 2 May 2002 16:47:40 -0400 (EDT) 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 NAA05664; Thu, 2 May 2002 13:45:17 -0700 (PDT) Message-Id: <200205022045.NAA05664@pit.erg.sri.com> To: Pekka Savola cc: ogier@erg.sri.com, Fred Baker , manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Re: IPR issue for TBRPF In-reply-to: Your message of "Thu, 02 May 2002 21:46:24 +0300." Date: Thu, 02 May 2002 13:45:17 -0700 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 Pekka, > On Thu, 2 May 2002 ogier@erg.sri.com wrote: > > That is exactly what SRI is doing. Our IPR statement contains the > > following sentence: "If SRI's submission (or portions thereof) is > > accepted and becomes part of the IETF standard, then SRI will grant > > any party a royalty-free license under such patents for both > > commercial and non-commercial uses, to the extent necessary for > > compliance with the standard." > > > > Also note that ISATAP (in the NGTRANS WG) has exactly the same IPR > > statement as TBRPF: http://www.ietf.org/ietf/IPR/ISI-NGTRANS.txt > > Not so. From the URL: > > --8<-- > [...] Any aspects or variants of > SRI's submission that are not included in the IETF standard and/or are > not necessary for compliance with the standard may require an additional > license from SRI under terms to be negotiated by the parties. > --8<-- > > This can be interpreted that every SHOULD, MAY or an additional draft (as > they are not *required* for compliance) is subject to SRI's goodwill and > claims in any time in the future. Good point. I am sure this was not the intention of our lawyers, and I will ask them to update the IPR statement (for both TBRPF and ISATAP) so that implementors can include the SHOULDs and MAYs without requiring any additional license. Richard > > I wish I had known about this before wasting my time on ISATAP. > > There are no good patents. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu May 2 17:16:07 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 RAA08838 for ; Thu, 2 May 2002 17:16:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA07969 for manet-archive@odin.ietf.org; Thu, 2 May 2002 17:16:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05168; Thu, 2 May 2002 16:47:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05139 for ; Thu, 2 May 2002 16:47:45 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05591 for ; Thu, 2 May 2002 16:47:40 -0400 (EDT) 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 NAA05664; Thu, 2 May 2002 13:45:17 -0700 (PDT) Message-Id: <200205022045.NAA05664@pit.erg.sri.com> To: Pekka Savola cc: ogier@erg.sri.com, Fred Baker , manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Re: IPR issue for TBRPF In-reply-to: Your message of "Thu, 02 May 2002 21:46:24 +0300." Date: Thu, 02 May 2002 13:45:17 -0700 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 Pekka, > On Thu, 2 May 2002 ogier@erg.sri.com wrote: > > That is exactly what SRI is doing. Our IPR statement contains the > > following sentence: "If SRI's submission (or portions thereof) is > > accepted and becomes part of the IETF standard, then SRI will grant > > any party a royalty-free license under such patents for both > > commercial and non-commercial uses, to the extent necessary for > > compliance with the standard." > > > > Also note that ISATAP (in the NGTRANS WG) has exactly the same IPR > > statement as TBRPF: http://www.ietf.org/ietf/IPR/ISI-NGTRANS.txt > > Not so. From the URL: > > --8<-- > [...] Any aspects or variants of > SRI's submission that are not included in the IETF standard and/or are > not necessary for compliance with the standard may require an additional > license from SRI under terms to be negotiated by the parties. > --8<-- > > This can be interpreted that every SHOULD, MAY or an additional draft (as > they are not *required* for compliance) is subject to SRI's goodwill and > claims in any time in the future. Good point. I am sure this was not the intention of our lawyers, and I will ask them to update the IPR statement (for both TBRPF and ISATAP) so that implementors can include the SHOULDs and MAYs without requiring any additional license. Richard > > I wish I had known about this before wasting my time on ISATAP. > > There are no good patents. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri May 3 02:31:54 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 CAA05784 for ; Fri, 3 May 2002 02:31:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12826; Fri, 3 May 2002 02:02:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12795 for ; Fri, 3 May 2002 02:02:46 -0400 (EDT) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00379 for ; Fri, 3 May 2002 02:02:43 -0400 (EDT) Received: from r3268756 ([64.163.242.98]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GVI008M4U4MX4@mta7.pltn13.pbi.net> for manet@ietf.org; Thu, 02 May 2002 23:02:46 -0700 (PDT) Date: Thu, 02 May 2002 23:02:45 -0700 From: Tom Sumaki To: manet@ietf.org Reply-to: tsumaki@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [manet] ABR, SSA Models avail? 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 Content-Transfer-Encoding: 7BIT Hi, I'm rather new to manet protocols, so my apologies if this is a oft covered item: Can someone point me to models on Associativity Based Routing and Signal Stability Routing? Although OPNET is preferred, I'd appreciate just about any. Thanks in advance. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri May 3 02:31:54 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 CAA05791 for ; Fri, 3 May 2002 02:31:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA14351 for manet-archive@odin.ietf.org; Fri, 3 May 2002 02:31:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12826; Fri, 3 May 2002 02:02:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12795 for ; Fri, 3 May 2002 02:02:46 -0400 (EDT) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00379 for ; Fri, 3 May 2002 02:02:43 -0400 (EDT) Received: from r3268756 ([64.163.242.98]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GVI008M4U4MX4@mta7.pltn13.pbi.net> for manet@ietf.org; Thu, 02 May 2002 23:02:46 -0700 (PDT) Date: Thu, 02 May 2002 23:02:45 -0700 From: Tom Sumaki To: manet@ietf.org Reply-to: tsumaki@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [manet] ABR, SSA Models avail? 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 Content-Transfer-Encoding: 7BIT Hi, I'm rather new to manet protocols, so my apologies if this is a oft covered item: Can someone point me to models on Associativity Based Routing and Signal Stability Routing? Although OPNET is preferred, I'd appreciate just about any. Thanks in advance. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri May 3 09:39:26 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 JAA13099 for ; Fri, 3 May 2002 09:39:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04496; Fri, 3 May 2002 09:08:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04467 for ; Fri, 3 May 2002 09:08:27 -0400 (EDT) Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12208 for ; Fri, 3 May 2002 09:08:22 -0400 (EDT) Received: from antd.nist.gov (stratus.antd.nist.gov [129.6.50.8]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g43D8M8q015053; Fri, 3 May 2002 09:08:23 -0400 (EDT) Message-ID: <3CD28BC2.9DFBE6C2@antd.nist.gov> Date: Fri, 03 May 2002 09:08:18 -0400 From: Leonard Miller Organization: NIST X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,ko MIME-Version: 1.0 To: Moustafa Hasnaa CC: manet@ietf.org Subject: Re: [manet] DSR Implementation References: <002101c1f1d1$258dbf70$e1a2c289@galaxy.enst.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Moustafa, Both from the NIST webpages and from the OPNET contributed models depot on the web, you can download an OPNET DSR implementation recently performed by a Master's student at Air Force Institute of Technology. http://w3.antd.nist.gov/wctg/prd_dsrfiles.html Regards, Len Miller > Moustafa Hasnaa wrote: > > Hi, > Does anyone know if there is a recent implementation available for > DSR protocol, which is tested before ??? > > Thanks -- ._.. . _. __ .. ._.. ._.. . ._. ._ _ _. .. ... _ Leonard E. Miller, Wireless Commun. Technologies Group National Institute of Standards & Technology (NIST) 100 Bureau Drive Stop 8920, Bldg. 820, Room 445 Gaithersburg, Maryland 20899-8920 Phone: 301-975-8018 Fax: 301-590-0932 email: lmiller@antd.nist.gov, LenMiller42@cs.com http://w3.antd.nist.gov/wctg/people/lmiller.html ._ _. ._ ._.. _.__ ... .. ... ._ _. _.. ... .. __ .._ ._.. ._ _ .. ___ _. ___... .__ .. ._. . ._.. . ... ... _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri May 3 09:39:57 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 JAA13110 for ; Fri, 3 May 2002 09:39:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06456 for manet-archive@odin.ietf.org; Fri, 3 May 2002 09:39:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04496; Fri, 3 May 2002 09:08:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04467 for ; Fri, 3 May 2002 09:08:27 -0400 (EDT) Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12208 for ; Fri, 3 May 2002 09:08:22 -0400 (EDT) Received: from antd.nist.gov (stratus.antd.nist.gov [129.6.50.8]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g43D8M8q015053; Fri, 3 May 2002 09:08:23 -0400 (EDT) Message-ID: <3CD28BC2.9DFBE6C2@antd.nist.gov> Date: Fri, 03 May 2002 09:08:18 -0400 From: Leonard Miller Organization: NIST X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,ko MIME-Version: 1.0 To: Moustafa Hasnaa CC: manet@ietf.org Subject: Re: [manet] DSR Implementation References: <002101c1f1d1$258dbf70$e1a2c289@galaxy.enst.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Moustafa, Both from the NIST webpages and from the OPNET contributed models depot on the web, you can download an OPNET DSR implementation recently performed by a Master's student at Air Force Institute of Technology. http://w3.antd.nist.gov/wctg/prd_dsrfiles.html Regards, Len Miller > Moustafa Hasnaa wrote: > > Hi, > Does anyone know if there is a recent implementation available for > DSR protocol, which is tested before ??? > > Thanks -- ._.. . _. __ .. ._.. ._.. . ._. ._ _ _. .. ... _ Leonard E. Miller, Wireless Commun. Technologies Group National Institute of Standards & Technology (NIST) 100 Bureau Drive Stop 8920, Bldg. 820, Room 445 Gaithersburg, Maryland 20899-8920 Phone: 301-975-8018 Fax: 301-590-0932 email: lmiller@antd.nist.gov, LenMiller42@cs.com http://w3.antd.nist.gov/wctg/people/lmiller.html ._ _. ._ ._.. _.__ ... .. ... ._ _. _.. ... .. __ .._ ._.. ._ _ .. ___ _. ___... .__ .. ._. . ._.. . ... ... _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon May 6 04:54:13 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 EAA10020 for ; Mon, 6 May 2002 04:54:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03786; Mon, 6 May 2002 04:05:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03752 for ; Mon, 6 May 2002 04:05:53 -0400 (EDT) Received: from luit.iitg.ernet.in (iitg.ernet.in [202.141.80.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09593 for ; Mon, 6 May 2002 04:05:45 -0400 (EDT) Received: from loktak.iitg.ernet.in (IDENT:WWJxVHqpH8WFWTsOcV7RldLLo9bpZ9yn@loktak.iitg.ernet.in [202.141.80.32]) by luit.iitg.ernet.in (8.12.2/8.12.0) with ESMTP id g4684tEt009096 for ; Mon, 6 May 2002 13:34:56 +0530 Received: from localhost (arijitg@localhost) by loktak.iitg.ernet.in (8.11.6/8.9.3) with ESMTP id g4681FY19843 for ; Mon, 6 May 2002 13:31:15 +0530 X-Authentication-Warning: loktak.iitg.ernet.in: arijitg owned process doing -bs Date: Mon, 6 May 2002 13:31:15 +0530 (IST) From: Arijit Ganguly To: Mobile Ad hoc Networks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Subject: [manet] ODMRP implementation on ns2 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 Hello Seniors PLease let me know if anyone of you has an ODMRP implementation on ns2. >From the earlier archives, it seems that ODMRP has been implemented on ns2. But its really hard to locate the code. The other option of using GloMoSim is totally out of questions. I have been trying hard with it, but there are too many bugs in that implementation. I expect the ns-2 implementation could be bug-free. Please help. Regards Arijit Ganguly -- ------------------------------------------------------------------------------ Arijit Ganguly Final Year Student Department of Computer Science & Engineering Indian Institute of Technology, Guwahati Guwahati - 781039, District Kamrup Assam, India ------------------------------------------------ Phone : +00-91-0361-690763 (room #203) Fax : +91 361 690762 email : ariganguly@yahoo.co.in CC : ariganguly@hotmail.com ------------------------------------------------ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon May 6 04:54:14 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 EAA10029 for ; Mon, 6 May 2002 04:54:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA05737 for manet-archive@odin.ietf.org; Mon, 6 May 2002 04:54:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03786; Mon, 6 May 2002 04:05:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03752 for ; Mon, 6 May 2002 04:05:53 -0400 (EDT) Received: from luit.iitg.ernet.in (iitg.ernet.in [202.141.80.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09593 for ; Mon, 6 May 2002 04:05:45 -0400 (EDT) Received: from loktak.iitg.ernet.in (IDENT:WWJxVHqpH8WFWTsOcV7RldLLo9bpZ9yn@loktak.iitg.ernet.in [202.141.80.32]) by luit.iitg.ernet.in (8.12.2/8.12.0) with ESMTP id g4684tEt009096 for ; Mon, 6 May 2002 13:34:56 +0530 Received: from localhost (arijitg@localhost) by loktak.iitg.ernet.in (8.11.6/8.9.3) with ESMTP id g4681FY19843 for ; Mon, 6 May 2002 13:31:15 +0530 X-Authentication-Warning: loktak.iitg.ernet.in: arijitg owned process doing -bs Date: Mon, 6 May 2002 13:31:15 +0530 (IST) From: Arijit Ganguly To: Mobile Ad hoc Networks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Subject: [manet] ODMRP implementation on ns2 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 Hello Seniors PLease let me know if anyone of you has an ODMRP implementation on ns2. >From the earlier archives, it seems that ODMRP has been implemented on ns2. But its really hard to locate the code. The other option of using GloMoSim is totally out of questions. I have been trying hard with it, but there are too many bugs in that implementation. I expect the ns-2 implementation could be bug-free. Please help. Regards Arijit Ganguly -- ------------------------------------------------------------------------------ Arijit Ganguly Final Year Student Department of Computer Science & Engineering Indian Institute of Technology, Guwahati Guwahati - 781039, District Kamrup Assam, India ------------------------------------------------ Phone : +00-91-0361-690763 (room #203) Fax : +91 361 690762 email : ariganguly@yahoo.co.in CC : ariganguly@hotmail.com ------------------------------------------------ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon May 6 10:17:38 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 KAA20548 for ; Mon, 6 May 2002 10:17:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20379; Mon, 6 May 2002 09:44:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20348 for ; Mon, 6 May 2002 09:44:32 -0400 (EDT) Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18681 for ; Mon, 6 May 2002 09:44:25 -0400 (EDT) Received: from schaula (dhcp162-225.enst.fr [137.194.162.225]) by infres.enst.fr (Postfix) with SMTP id C6FD518B0 for ; Mon, 6 May 2002 15:44:29 +0200 (MEST) Message-ID: <001001c1f505$360b33f0$e1a2c289@galaxy.enst.fr> From: "Moustafa Hasnaa" To: Date: Mon, 6 May 2002 15:52:06 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C1F515.F9181D30" 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 Subject: [manet] Concerning DSR 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 C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_000D_01C1F515.F9181D30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Does anyone know if there is a way to have a source code for the DSR = protocol=20 implementation ??? =20 Thanks ------=_NextPart_000_000D_01C1F515.F9181D30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
  Does anyone = know if=20 there is a way to have a source code for the DSR protocol =
  implementation=20 ???
 
Thanks

------=_NextPart_000_000D_01C1F515.F9181D30-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon May 6 10:17:44 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 KAA20557 for ; Mon, 6 May 2002 10:17:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA23388 for manet-archive@odin.ietf.org; Mon, 6 May 2002 10:17:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20379; Mon, 6 May 2002 09:44:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20348 for ; Mon, 6 May 2002 09:44:32 -0400 (EDT) Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18681 for ; Mon, 6 May 2002 09:44:25 -0400 (EDT) Received: from schaula (dhcp162-225.enst.fr [137.194.162.225]) by infres.enst.fr (Postfix) with SMTP id C6FD518B0 for ; Mon, 6 May 2002 15:44:29 +0200 (MEST) Message-ID: <001001c1f505$360b33f0$e1a2c289@galaxy.enst.fr> From: "Moustafa Hasnaa" To: Date: Mon, 6 May 2002 15:52:06 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C1F515.F9181D30" 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 Subject: [manet] Concerning DSR 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 C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_000D_01C1F515.F9181D30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Does anyone know if there is a way to have a source code for the DSR = protocol=20 implementation ??? =20 Thanks ------=_NextPart_000_000D_01C1F515.F9181D30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
  Does anyone = know if=20 there is a way to have a source code for the DSR protocol =
  implementation=20 ???
 
Thanks

------=_NextPart_000_000D_01C1F515.F9181D30-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon May 6 11:57:55 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 LAA24560 for ; Mon, 6 May 2002 11:57:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28476; Mon, 6 May 2002 11:27:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28452 for ; Mon, 6 May 2002 11:27:24 -0400 (EDT) Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23642 for ; Mon, 6 May 2002 11:27:12 -0400 (EDT) Received: from schaula (dhcp162-225.enst.fr [137.194.162.225]) by infres.enst.fr (Postfix) with SMTP id 19A4818A0 for ; Mon, 6 May 2002 17:27:14 +0200 (MEST) Message-ID: <008501c1f513$90214dd0$e1a2c289@galaxy.enst.fr> From: "Moustafa Hasnaa" To: Date: Mon, 6 May 2002 17:34:50 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0082_01C1F524.5364FE80" 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 Subject: [manet] A reactive protocol implementation 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 C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0082_01C1F524.5364FE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Does anyone know if there is a way to have a source code for any = reactive routing protocol implementation ??? As all what i found concern = onlt proactive ones =20 Thanks ------=_NextPart_000_0082_01C1F524.5364FE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
  Does anyone = know if=20 there is a way to have a source code for any reactive routing=20 protocol implementation ??? As=20 all what i found concern onlt proactive=20 ones
 
Thanks

------=_NextPart_000_0082_01C1F524.5364FE80-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon May 6 11:57:56 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 LAA24568 for ; Mon, 6 May 2002 11:57:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00364 for manet-archive@odin.ietf.org; Mon, 6 May 2002 11:58:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28476; Mon, 6 May 2002 11:27:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28452 for ; Mon, 6 May 2002 11:27:24 -0400 (EDT) Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23642 for ; Mon, 6 May 2002 11:27:12 -0400 (EDT) Received: from schaula (dhcp162-225.enst.fr [137.194.162.225]) by infres.enst.fr (Postfix) with SMTP id 19A4818A0 for ; Mon, 6 May 2002 17:27:14 +0200 (MEST) Message-ID: <008501c1f513$90214dd0$e1a2c289@galaxy.enst.fr> From: "Moustafa Hasnaa" To: Date: Mon, 6 May 2002 17:34:50 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0082_01C1F524.5364FE80" 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 Subject: [manet] A reactive protocol implementation 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 C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0082_01C1F524.5364FE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Does anyone know if there is a way to have a source code for any = reactive routing protocol implementation ??? As all what i found concern = onlt proactive ones =20 Thanks ------=_NextPart_000_0082_01C1F524.5364FE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
  Does anyone = know if=20 there is a way to have a source code for any reactive routing=20 protocol implementation ??? As=20 all what i found concern onlt proactive=20 ones
 
Thanks

------=_NextPart_000_0082_01C1F524.5364FE80-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon May 6 13:17:04 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 NAA27926 for ; Mon, 6 May 2002 13:17:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04457; Mon, 6 May 2002 12:43:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04425 for ; Mon, 6 May 2002 12:43:02 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26395 for ; Mon, 6 May 2002 12:42:55 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA05939; Mon, 6 May 2002 09:42:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g46GgTd01944; Mon, 6 May 2002 09:42:29 -0700 X-mProtect: <200205061642> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEWS5uS; Mon, 06 May 2002 09:42:28 PDT Message-ID: <3CD6B275.CB1FD0D3@iprg.nokia.com> Date: Mon, 06 May 2002 09:42:29 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Moustafa Hasnaa CC: manet@ietf.org Subject: Re: [manet] A reactive protocol implementation References: <008501c1f513$90214dd0$e1a2c289@galaxy.enst.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hrllo Moustafa, You can find a collection of freeware and other information about AODV at the following URL: http://moment.cs.ucsb.edu/AODV/aodv.html Regards, Charlie P. > Moustafa Hasnaa wrote: > > Hi, > Does anyone know if there is a way to have a source code for any reactive > routing protocol implementation ??? As all what i found concern onlt proactive > ones > > Thanks _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon May 6 13:17:05 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 NAA27937 for ; Mon, 6 May 2002 13:17:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA06208 for manet-archive@odin.ietf.org; Mon, 6 May 2002 13:17:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04457; Mon, 6 May 2002 12:43:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04425 for ; Mon, 6 May 2002 12:43:02 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26395 for ; Mon, 6 May 2002 12:42:55 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA05939; Mon, 6 May 2002 09:42:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g46GgTd01944; Mon, 6 May 2002 09:42:29 -0700 X-mProtect: <200205061642> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEWS5uS; Mon, 06 May 2002 09:42:28 PDT Message-ID: <3CD6B275.CB1FD0D3@iprg.nokia.com> Date: Mon, 06 May 2002 09:42:29 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Moustafa Hasnaa CC: manet@ietf.org Subject: Re: [manet] A reactive protocol implementation References: <008501c1f513$90214dd0$e1a2c289@galaxy.enst.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hrllo Moustafa, You can find a collection of freeware and other information about AODV at the following URL: http://moment.cs.ucsb.edu/AODV/aodv.html Regards, Charlie P. > Moustafa Hasnaa wrote: > > Hi, > Does anyone know if there is a way to have a source code for any reactive > routing protocol implementation ??? As all what i found concern onlt proactive > ones > > Thanks _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon May 6 17:47:06 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 RAA08572 for ; Mon, 6 May 2002 17:47:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22069; Mon, 6 May 2002 17:08:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22038 for ; Mon, 6 May 2002 17:08:42 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06812 for ; Mon, 6 May 2002 17:08:35 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <118087>; Mon, 6 May 2002 15:08:34 -0600 Message-Id: <02May6.150834mdt.118087@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: manet@ietf.org Date: Mon, 6 May 2002 15:08:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] Dumb Question? 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 Hello, I am looking for a term, but have had no luck. In wired nets, a packet is routed through the network from node to node, say by routing tables. However, in MANETs, in which packets are broadcast via omnidirectional antennae on a shared channel, such a thing is not possible. Instead, each node that receives a packet decides to: 1. Discard the packet, 2. "Read" the packet, since it is addressed to the node, and/or 3. Rebroadcast the packet. If the node is not to be an intermediary node in the end-to-end path between the source and the destination, or if the node is receiving a copy of a packet it had previously broadcast, it will not broadcast the packet. This is necessary to avoid overutilizing the channel. If the node is an intermediary node on the path, then it must rebroadcast the packet. I've got this much figured out, but what I do not know is what this process is called. It is the MANET equivalent to "routing," but is not really routing, since the sending node has no way of directing the packet. I've tried a number of searches and read a few glossaries, but have not been able to find this term. I'd appreciate any help. Thanks, John P. Mullen _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon May 6 17:47:06 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 RAA08581 for ; Mon, 6 May 2002 17:47:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA26025 for manet-archive@odin.ietf.org; Mon, 6 May 2002 17:47:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22069; Mon, 6 May 2002 17:08:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22038 for ; Mon, 6 May 2002 17:08:42 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06812 for ; Mon, 6 May 2002 17:08:35 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <118087>; Mon, 6 May 2002 15:08:34 -0600 Message-Id: <02May6.150834mdt.118087@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: manet@ietf.org Date: Mon, 6 May 2002 15:08:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] Dumb Question? 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 Hello, I am looking for a term, but have had no luck. In wired nets, a packet is routed through the network from node to node, say by routing tables. However, in MANETs, in which packets are broadcast via omnidirectional antennae on a shared channel, such a thing is not possible. Instead, each node that receives a packet decides to: 1. Discard the packet, 2. "Read" the packet, since it is addressed to the node, and/or 3. Rebroadcast the packet. If the node is not to be an intermediary node in the end-to-end path between the source and the destination, or if the node is receiving a copy of a packet it had previously broadcast, it will not broadcast the packet. This is necessary to avoid overutilizing the channel. If the node is an intermediary node on the path, then it must rebroadcast the packet. I've got this much figured out, but what I do not know is what this process is called. It is the MANET equivalent to "routing," but is not really routing, since the sending node has no way of directing the packet. I've tried a number of searches and read a few glossaries, but have not been able to find this term. I'd appreciate any help. Thanks, John P. Mullen _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon May 6 18:16:44 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 SAA09382 for ; Mon, 6 May 2002 18:16:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25191; Mon, 6 May 2002 17:38:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25160 for ; Mon, 6 May 2002 17:38:42 -0400 (EDT) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08104 for ; Mon, 6 May 2002 17:38:32 -0400 (EDT) Received: from vivi.cc.vt.edu (IDENT:mirapoint@vivi-lb.cc.vt.edu [10.1.1.12]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id g46LccZ407594; Mon, 6 May 2002 17:38:38 -0400 (EDT) Received: from TNT (h80ad3776.dhcp.vt.edu [128.173.55.118]) by vivi.cc.vt.edu (Mirapoint Messaging Server MOS 3.1.0.54-GA) with SMTP id ABU65104; Mon, 6 May 2002 17:38:36 -0400 (EDT) Message-ID: <007701c1f546$584c5d40$7637ad80@workgroup> From: "Tao Lin" To: "Mullen, John P. \(Contractor\)" Cc: References: <02May6.150834mdt.118087@gw.trac.wsmr.army.mil> Subject: Re: [manet] Dumb Question? Date: Mon, 6 May 2002 17:38:21 -0400 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 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit What you discorved are correct. MANET is just a term to describe the type of network (Mobile Ad hoc NETwork). Generally speaking, MANET routing protocols are used to help nodes to discover routes for all data packets. Since MANET topology can be random, routes can fail due to the movements of nodes. MANET routing protocols should be able to automatically detect that and recover failed paths. These protocols will help nodes to build proper routing table, which is similar to that of wired network, in real time. Don't know whether this replies your question. Tao ----- Original Message ----- From: "Mullen, John P. (Contractor)" To: Sent: Monday, May 06, 2002 5:08 PM Subject: [manet] Dumb Question? > Hello, > > I am looking for a term, but have had no luck. > > In wired nets, a packet is routed through the network from node to node, say > by routing tables. However, in MANETs, in which packets are broadcast via > omnidirectional antennae on a shared channel, such a thing is not possible. > Instead, each node that receives a packet decides to: > 1. Discard the packet, > 2. "Read" the packet, since it is addressed to the node, and/or > 3. Rebroadcast the packet. > > If the node is not to be an intermediary node in the end-to-end path between > the source and the destination, or if the node is receiving a copy of a > packet it had previously broadcast, it will not broadcast the packet. This > is necessary to avoid overutilizing the channel. > > If the node is an intermediary node on the path, then it must rebroadcast > the packet. > > I've got this much figured out, but what I do not know is what this process > is called. It is the MANET equivalent to "routing," but is not really > routing, since the sending node has no way of directing the packet. > > I've tried a number of searches and read a few glossaries, but have not been > able to find this term. > > I'd appreciate any help. > > Thanks, > > John P. Mullen > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon May 6 18:16:45 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 SAA09392 for ; Mon, 6 May 2002 18:16:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA27919 for manet-archive@odin.ietf.org; Mon, 6 May 2002 18:16:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25191; Mon, 6 May 2002 17:38:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25160 for ; Mon, 6 May 2002 17:38:42 -0400 (EDT) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08104 for ; Mon, 6 May 2002 17:38:32 -0400 (EDT) Received: from vivi.cc.vt.edu (IDENT:mirapoint@vivi-lb.cc.vt.edu [10.1.1.12]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id g46LccZ407594; Mon, 6 May 2002 17:38:38 -0400 (EDT) Received: from TNT (h80ad3776.dhcp.vt.edu [128.173.55.118]) by vivi.cc.vt.edu (Mirapoint Messaging Server MOS 3.1.0.54-GA) with SMTP id ABU65104; Mon, 6 May 2002 17:38:36 -0400 (EDT) Message-ID: <007701c1f546$584c5d40$7637ad80@workgroup> From: "Tao Lin" To: "Mullen, John P. \(Contractor\)" Cc: References: <02May6.150834mdt.118087@gw.trac.wsmr.army.mil> Subject: Re: [manet] Dumb Question? Date: Mon, 6 May 2002 17:38:21 -0400 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 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit What you discorved are correct. MANET is just a term to describe the type of network (Mobile Ad hoc NETwork). Generally speaking, MANET routing protocols are used to help nodes to discover routes for all data packets. Since MANET topology can be random, routes can fail due to the movements of nodes. MANET routing protocols should be able to automatically detect that and recover failed paths. These protocols will help nodes to build proper routing table, which is similar to that of wired network, in real time. Don't know whether this replies your question. Tao ----- Original Message ----- From: "Mullen, John P. (Contractor)" To: Sent: Monday, May 06, 2002 5:08 PM Subject: [manet] Dumb Question? > Hello, > > I am looking for a term, but have had no luck. > > In wired nets, a packet is routed through the network from node to node, say > by routing tables. However, in MANETs, in which packets are broadcast via > omnidirectional antennae on a shared channel, such a thing is not possible. > Instead, each node that receives a packet decides to: > 1. Discard the packet, > 2. "Read" the packet, since it is addressed to the node, and/or > 3. Rebroadcast the packet. > > If the node is not to be an intermediary node in the end-to-end path between > the source and the destination, or if the node is receiving a copy of a > packet it had previously broadcast, it will not broadcast the packet. This > is necessary to avoid overutilizing the channel. > > If the node is an intermediary node on the path, then it must rebroadcast > the packet. > > I've got this much figured out, but what I do not know is what this process > is called. It is the MANET equivalent to "routing," but is not really > routing, since the sending node has no way of directing the packet. > > I've tried a number of searches and read a few glossaries, but have not been > able to find this term. > > I'd appreciate any help. > > Thanks, > > John P. Mullen > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon May 6 18:53:20 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 SAA10107 for ; Mon, 6 May 2002 18:53:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27909; Mon, 6 May 2002 18:16:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27882 for ; Mon, 6 May 2002 18:16:42 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09379 for ; Mon, 6 May 2002 18:16:34 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA27525; Mon, 6 May 2002 15:16:46 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id PAA20689; Mon, 6 May 2002 15:16:37 -0700 (PDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g46MH5h22657; Mon, 6 May 2002 15:17:05 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 May 2002 15:16:36 -0700 Message-ID: From: "Nast, Douglas P" To: "'Mullen, John P. (Contractor)'" , manet@ietf.org Subject: RE: [manet] Dumb Question? Date: Mon, 6 May 2002 15:16:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 John, Actually, the manet folks are designing routing protocols in the classical sense, although the protocols of interest tend to be reactive rather than proactive. The fact that the mac layer supports broadcast via omni antennas does not change this. What you are suggesting is that an Manet does not need layer 3 routing since it can "switch" at layer 2. In effect, you would like to treat the manet as an ethernet segment where routing is not necessary within the segment because everyone has a shared medium. But I do not believe that this is the paradigm that this group is working to. I think the reason for this (I am just a hanger-on, not one of the old-timers) is that you need to talk to nodes that are not within range of your antenna. To get to them intermediate nodes have to forward your traffic. While this could be done at layer 2, it would involve building mechanisms at layer 2 that are as complicated as traditional layer 3 routing, and would not be as flexible (i.e. lead to stovepipe solutions). The name of the game seems to be to use IP infrastructure for multi-hop forwarding. Therefore layer 3 routing is indicated to relay the traffic across long distances. I would call the process you describe layer 2 switching, as in ethernet LANs. But it is not considered to be a general solution for Manets. Regards, Doug Nast, Boeing -----Original Message----- From: Mullen, John P. (Contractor) [mailto:mullenjp.contractor@trac.wsmr.army.mil] Sent: Monday, May 06, 2002 2:08 PM To: manet@ietf.org Subject: [manet] Dumb Question? Hello, I am looking for a term, but have had no luck. In wired nets, a packet is routed through the network from node to node, say by routing tables. However, in MANETs, in which packets are broadcast via omnidirectional antennae on a shared channel, such a thing is not possible. Instead, each node that receives a packet decides to: 1. Discard the packet, 2. "Read" the packet, since it is addressed to the node, and/or 3. Rebroadcast the packet. If the node is not to be an intermediary node in the end-to-end path between the source and the destination, or if the node is receiving a copy of a packet it had previously broadcast, it will not broadcast the packet. This is necessary to avoid overutilizing the channel. If the node is an intermediary node on the path, then it must rebroadcast the packet. I've got this much figured out, but what I do not know is what this process is called. It is the MANET equivalent to "routing," but is not really routing, since the sending node has no way of directing the packet. I've tried a number of searches and read a few glossaries, but have not been able to find this term. I'd appreciate any help. Thanks, John P. Mullen _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon May 6 18:53:21 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 SAA10122 for ; Mon, 6 May 2002 18:53:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29756 for manet-archive@odin.ietf.org; Mon, 6 May 2002 18:53:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27909; Mon, 6 May 2002 18:16:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27882 for ; Mon, 6 May 2002 18:16:42 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09379 for ; Mon, 6 May 2002 18:16:34 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA27525; Mon, 6 May 2002 15:16:46 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id PAA20689; Mon, 6 May 2002 15:16:37 -0700 (PDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g46MH5h22657; Mon, 6 May 2002 15:17:05 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 May 2002 15:16:36 -0700 Message-ID: From: "Nast, Douglas P" To: "'Mullen, John P. (Contractor)'" , manet@ietf.org Subject: RE: [manet] Dumb Question? Date: Mon, 6 May 2002 15:16:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 John, Actually, the manet folks are designing routing protocols in the classical sense, although the protocols of interest tend to be reactive rather than proactive. The fact that the mac layer supports broadcast via omni antennas does not change this. What you are suggesting is that an Manet does not need layer 3 routing since it can "switch" at layer 2. In effect, you would like to treat the manet as an ethernet segment where routing is not necessary within the segment because everyone has a shared medium. But I do not believe that this is the paradigm that this group is working to. I think the reason for this (I am just a hanger-on, not one of the old-timers) is that you need to talk to nodes that are not within range of your antenna. To get to them intermediate nodes have to forward your traffic. While this could be done at layer 2, it would involve building mechanisms at layer 2 that are as complicated as traditional layer 3 routing, and would not be as flexible (i.e. lead to stovepipe solutions). The name of the game seems to be to use IP infrastructure for multi-hop forwarding. Therefore layer 3 routing is indicated to relay the traffic across long distances. I would call the process you describe layer 2 switching, as in ethernet LANs. But it is not considered to be a general solution for Manets. Regards, Doug Nast, Boeing -----Original Message----- From: Mullen, John P. (Contractor) [mailto:mullenjp.contractor@trac.wsmr.army.mil] Sent: Monday, May 06, 2002 2:08 PM To: manet@ietf.org Subject: [manet] Dumb Question? Hello, I am looking for a term, but have had no luck. In wired nets, a packet is routed through the network from node to node, say by routing tables. However, in MANETs, in which packets are broadcast via omnidirectional antennae on a shared channel, such a thing is not possible. Instead, each node that receives a packet decides to: 1. Discard the packet, 2. "Read" the packet, since it is addressed to the node, and/or 3. Rebroadcast the packet. If the node is not to be an intermediary node in the end-to-end path between the source and the destination, or if the node is receiving a copy of a packet it had previously broadcast, it will not broadcast the packet. This is necessary to avoid overutilizing the channel. If the node is an intermediary node on the path, then it must rebroadcast the packet. I've got this much figured out, but what I do not know is what this process is called. It is the MANET equivalent to "routing," but is not really routing, since the sending node has no way of directing the packet. I've tried a number of searches and read a few glossaries, but have not been able to find this term. I'd appreciate any help. Thanks, John P. Mullen _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon May 6 19:27:37 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 TAA10996 for ; Mon, 6 May 2002 19:27:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00367; Mon, 6 May 2002 19:00:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00320 for ; Mon, 6 May 2002 19:00:37 -0400 (EDT) Received: from crystal.bbn.com (crystal.BBN.COM [128.89.80.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10336 for ; Mon, 6 May 2002 19:00:28 -0400 (EDT) Received: from crystal.bbn.com (localhost.bbn.com [127.0.0.1]) by crystal.bbn.com (8.9.3/8.8.8) with ESMTP id TAA85247; Mon, 6 May 2002 19:04:04 -0400 (EDT) (envelope-from ramanath@crystal.bbn.com) Message-Id: <200205062304.TAA85247@crystal.bbn.com> To: ramanath@bbn.com cc: "'Mullen, John P. (Contractor)'" , manet@ietf.org Subject: Re: [manet] Dumb Question? In-reply-to: Your message of "Mon, 06 May 2002 15:16:23 PDT." Date: Mon, 06 May 2002 19:04:04 -0400 From: Ram Ramanathan 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 John, I don't believe there is a term for this. Note that the path is implied by which node decides to rebroadcast and which doesn't. The set of decisions of the nodes, made in a distributed manner, decides the "route" of the packet. Thus, one could argue this is still "routing" from a global perspective, even though, from a node-specific viewpoint it may be different from what is being done traditionally. A couple months ago I also observed this, and was wondering if it could somehow simplify routing. It turns out that in order to decide whether to rebroadcast or not, a node has to look at which node the packet came from (plus the destination). Thus, you have a "previous hop" table instead of a next hop table, and each entry says one of three things -- keep, discard, rebroadcast. In other words, even though the node does not "direct" the packet in the "forward" direction, it does so implicitly *from* the "backward" direction. This leads to a mirror image of traditional routing with everything in reverse, but with sort of the same underlying constraints, although you may be able to have a smaller routing table (gintour table?:). This is a nice little thing for some bright grad student to see if there are any hidden nuggets. And coin a term and be famous, of course:) -Ram. > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Monday, May 06, 2002 2:08 PM > To: manet@ietf.org > Subject: [manet] Dumb Question? > > > Hello, > > I am looking for a term, but have had no luck. > > In wired nets, a packet is routed through the network from node to node, say > by routing tables. However, in MANETs, in which packets are broadcast via > omnidirectional antennae on a shared channel, such a thing is not possible. > Instead, each node that receives a packet decides to: > 1. Discard the packet, > 2. "Read" the packet, since it is addressed to the node, and/or > 3. Rebroadcast the packet. > > If the node is not to be an intermediary node in the end-to-end path between > the source and the destination, or if the node is receiving a copy of a > packet it had previously broadcast, it will not broadcast the packet. This > is necessary to avoid overutilizing the channel. > > If the node is an intermediary node on the path, then it must rebroadcast > the packet. > > I've got this much figured out, but what I do not know is what this process > is called. It is the MANET equivalent to "routing," but is not really > routing, since the sending node has no way of directing the packet. > > I've tried a number of searches and read a few glossaries, but have not been > able to find this term. > > I'd appreciate any help. > > Thanks, > > John P. Mullen > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon May 6 20:23:18 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 UAA11974 for ; Mon, 6 May 2002 20:23:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02456; Mon, 6 May 2002 19:32:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02425 for ; Mon, 6 May 2002 19:32:09 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11068 for ; Mon, 6 May 2002 19:32:00 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA01787; Mon, 6 May 2002 16:31:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g46NVV604454; Mon, 6 May 2002 16:31:31 -0700 X-mProtect: <200205062331> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkIHvfE; Mon, 06 May 2002 16:31:30 PDT Message-ID: <3CD71252.527340FB@iprg.nokia.com> Date: Mon, 06 May 2002 16:31:30 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ram Ramanathan CC: "'Mullen, John P. (Contractor)'" , manet@ietf.org Subject: Re: [manet] Dumb Question? References: <200205062304.TAA85247@crystal.bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Ram and John, I prefer a somewhat different conceptual model. Notice that if there were no framing for Ethernet packets on a shared channel, there wouldn't be much difference for the purposes of this discussion. One can easily imagine framing the broadcast packets with MAC addresses, and then John's question would almost evaporate. Regarding the observation that one might look at the (IP?) address of the last hop to decide what to do, that wouldn't be necessary with MAC addresses, but it's a good way to operate otherwise. I reckon that neighbors that are neither last nor next hop could use such broadcast information to acquire paths towards destinations, whether or not they currently need to have the information. Maybe "tuor"ing table is better than "routing" table. Or maybe just "last-hop" table. Or maybe it's a "not-forwarding" table or "not-backwarding" table. Regards, Charlie P. Ram Ramanathan wrote: > > John, > > I don't believe there is a term for this. > > Note that the path is implied by which node decides to rebroadcast and > which doesn't. The set of decisions of the nodes, made in a distributed > manner, decides the "route" of the packet. Thus, one could argue this > is still "routing" > from a global perspective, even though, from a node-specific viewpoint > it may be different from what is being done traditionally. > > A couple months ago I also observed this, and was wondering if it could > somehow simplify routing. It turns out that in order to decide whether to > rebroadcast or not, a node has to look at which node the packet came > from (plus the destination). Thus, you have a "previous hop" table > instead of a next hop table, and each entry says one of three things -- > keep, discard, rebroadcast. In other words, even though the node > does not "direct" the packet in the "forward" direction, it does so > implicitly *from* the "backward" direction. > > This leads to a mirror image of traditional routing with everything > in reverse, but with sort of the same underlying constraints, although you > may be able to have a smaller routing table (gintour table?:). This > is a nice little thing for some bright grad student to see if there > are any hidden nuggets. And coin a term and be famous, of course:) > > -Ram. > > > From: Mullen, John P. (Contractor) > > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > > Sent: Monday, May 06, 2002 2:08 PM > > To: manet@ietf.org > > Subject: [manet] Dumb Question? > > > > > > Hello, > > > > I am looking for a term, but have had no luck. > > > > In wired nets, a packet is routed through the network from node to node, say > > by routing tables. However, in MANETs, in which packets are broadcast via > > omnidirectional antennae on a shared channel, such a thing is not possible. > > Instead, each node that receives a packet decides to: > > 1. Discard the packet, > > 2. "Read" the packet, since it is addressed to the node, and/or > > 3. Rebroadcast the packet. > > > > If the node is not to be an intermediary node in the end-to-end path between > > the source and the destination, or if the node is receiving a copy of a > > packet it had previously broadcast, it will not broadcast the packet. This > > is necessary to avoid overutilizing the channel. > > > > If the node is an intermediary node on the path, then it must rebroadcast > > the packet. > > > > I've got this much figured out, but what I do not know is what this process > > is called. It is the MANET equivalent to "routing," but is not really > > routing, since the sending node has no way of directing the packet. > > > > I've tried a number of searches and read a few glossaries, but have not been > > able to find this term. > > > > I'd appreciate any help. > > > > Thanks, > > > > John P. Mullen > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon May 6 20:29:40 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 TAA11005 for ; Mon, 6 May 2002 19:27:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA01843 for manet-archive@odin.ietf.org; Mon, 6 May 2002 19:27:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00367; Mon, 6 May 2002 19:00:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00320 for ; Mon, 6 May 2002 19:00:37 -0400 (EDT) Received: from crystal.bbn.com (crystal.BBN.COM [128.89.80.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10336 for ; Mon, 6 May 2002 19:00:28 -0400 (EDT) Received: from crystal.bbn.com (localhost.bbn.com [127.0.0.1]) by crystal.bbn.com (8.9.3/8.8.8) with ESMTP id TAA85247; Mon, 6 May 2002 19:04:04 -0400 (EDT) (envelope-from ramanath@crystal.bbn.com) Message-Id: <200205062304.TAA85247@crystal.bbn.com> To: ramanath@bbn.com cc: "'Mullen, John P. (Contractor)'" , manet@ietf.org Subject: Re: [manet] Dumb Question? In-reply-to: Your message of "Mon, 06 May 2002 15:16:23 PDT." Date: Mon, 06 May 2002 19:04:04 -0400 From: Ram Ramanathan 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 John, I don't believe there is a term for this. Note that the path is implied by which node decides to rebroadcast and which doesn't. The set of decisions of the nodes, made in a distributed manner, decides the "route" of the packet. Thus, one could argue this is still "routing" from a global perspective, even though, from a node-specific viewpoint it may be different from what is being done traditionally. A couple months ago I also observed this, and was wondering if it could somehow simplify routing. It turns out that in order to decide whether to rebroadcast or not, a node has to look at which node the packet came from (plus the destination). Thus, you have a "previous hop" table instead of a next hop table, and each entry says one of three things -- keep, discard, rebroadcast. In other words, even though the node does not "direct" the packet in the "forward" direction, it does so implicitly *from* the "backward" direction. This leads to a mirror image of traditional routing with everything in reverse, but with sort of the same underlying constraints, although you may be able to have a smaller routing table (gintour table?:). This is a nice little thing for some bright grad student to see if there are any hidden nuggets. And coin a term and be famous, of course:) -Ram. > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Monday, May 06, 2002 2:08 PM > To: manet@ietf.org > Subject: [manet] Dumb Question? > > > Hello, > > I am looking for a term, but have had no luck. > > In wired nets, a packet is routed through the network from node to node, say > by routing tables. However, in MANETs, in which packets are broadcast via > omnidirectional antennae on a shared channel, such a thing is not possible. > Instead, each node that receives a packet decides to: > 1. Discard the packet, > 2. "Read" the packet, since it is addressed to the node, and/or > 3. Rebroadcast the packet. > > If the node is not to be an intermediary node in the end-to-end path between > the source and the destination, or if the node is receiving a copy of a > packet it had previously broadcast, it will not broadcast the packet. This > is necessary to avoid overutilizing the channel. > > If the node is an intermediary node on the path, then it must rebroadcast > the packet. > > I've got this much figured out, but what I do not know is what this process > is called. It is the MANET equivalent to "routing," but is not really > routing, since the sending node has no way of directing the packet. > > I've tried a number of searches and read a few glossaries, but have not been > able to find this term. > > I'd appreciate any help. > > Thanks, > > John P. Mullen > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon May 6 21:11:18 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 UAA11981 for ; Mon, 6 May 2002 20:23:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA05006 for manet-archive@odin.ietf.org; Mon, 6 May 2002 20:23:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02456; Mon, 6 May 2002 19:32:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02425 for ; Mon, 6 May 2002 19:32:09 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11068 for ; Mon, 6 May 2002 19:32:00 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA01787; Mon, 6 May 2002 16:31:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g46NVV604454; Mon, 6 May 2002 16:31:31 -0700 X-mProtect: <200205062331> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkIHvfE; Mon, 06 May 2002 16:31:30 PDT Message-ID: <3CD71252.527340FB@iprg.nokia.com> Date: Mon, 06 May 2002 16:31:30 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ram Ramanathan CC: "'Mullen, John P. (Contractor)'" , manet@ietf.org Subject: Re: [manet] Dumb Question? References: <200205062304.TAA85247@crystal.bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Ram and John, I prefer a somewhat different conceptual model. Notice that if there were no framing for Ethernet packets on a shared channel, there wouldn't be much difference for the purposes of this discussion. One can easily imagine framing the broadcast packets with MAC addresses, and then John's question would almost evaporate. Regarding the observation that one might look at the (IP?) address of the last hop to decide what to do, that wouldn't be necessary with MAC addresses, but it's a good way to operate otherwise. I reckon that neighbors that are neither last nor next hop could use such broadcast information to acquire paths towards destinations, whether or not they currently need to have the information. Maybe "tuor"ing table is better than "routing" table. Or maybe just "last-hop" table. Or maybe it's a "not-forwarding" table or "not-backwarding" table. Regards, Charlie P. Ram Ramanathan wrote: > > John, > > I don't believe there is a term for this. > > Note that the path is implied by which node decides to rebroadcast and > which doesn't. The set of decisions of the nodes, made in a distributed > manner, decides the "route" of the packet. Thus, one could argue this > is still "routing" > from a global perspective, even though, from a node-specific viewpoint > it may be different from what is being done traditionally. > > A couple months ago I also observed this, and was wondering if it could > somehow simplify routing. It turns out that in order to decide whether to > rebroadcast or not, a node has to look at which node the packet came > from (plus the destination). Thus, you have a "previous hop" table > instead of a next hop table, and each entry says one of three things -- > keep, discard, rebroadcast. In other words, even though the node > does not "direct" the packet in the "forward" direction, it does so > implicitly *from* the "backward" direction. > > This leads to a mirror image of traditional routing with everything > in reverse, but with sort of the same underlying constraints, although you > may be able to have a smaller routing table (gintour table?:). This > is a nice little thing for some bright grad student to see if there > are any hidden nuggets. And coin a term and be famous, of course:) > > -Ram. > > > From: Mullen, John P. (Contractor) > > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > > Sent: Monday, May 06, 2002 2:08 PM > > To: manet@ietf.org > > Subject: [manet] Dumb Question? > > > > > > Hello, > > > > I am looking for a term, but have had no luck. > > > > In wired nets, a packet is routed through the network from node to node, say > > by routing tables. However, in MANETs, in which packets are broadcast via > > omnidirectional antennae on a shared channel, such a thing is not possible. > > Instead, each node that receives a packet decides to: > > 1. Discard the packet, > > 2. "Read" the packet, since it is addressed to the node, and/or > > 3. Rebroadcast the packet. > > > > If the node is not to be an intermediary node in the end-to-end path between > > the source and the destination, or if the node is receiving a copy of a > > packet it had previously broadcast, it will not broadcast the packet. This > > is necessary to avoid overutilizing the channel. > > > > If the node is an intermediary node on the path, then it must rebroadcast > > the packet. > > > > I've got this much figured out, but what I do not know is what this process > > is called. It is the MANET equivalent to "routing," but is not really > > routing, since the sending node has no way of directing the packet. > > > > I've tried a number of searches and read a few glossaries, but have not been > > able to find this term. > > > > I'd appreciate any help. > > > > Thanks, > > > > John P. Mullen > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue May 7 08:05:06 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 IAA03975 for ; Tue, 7 May 2002 08:05:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA19709 for manet-archive@odin.ietf.org; Tue, 7 May 2002 08:05:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15280; Tue, 7 May 2002 07:10:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15253 for ; Tue, 7 May 2002 07:10:33 -0400 (EDT) Received: from mephisto.inf.tu-dresden.de (mephisto.inf.tu-dresden.de [141.76.40.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02010 for ; Tue, 7 May 2002 07:10:25 -0400 (EDT) Received: from acer.rn.inf.tu-dresden.de (acer.inf.tu-dresden.de [141.76.40.88]) by mephisto.inf.tu-dresden.de (8.8.7/8.8.7) with ESMTP id NAA08239; Tue, 7 May 2002 13:10:19 +0200 (MET DST) Message-Id: <5.1.0.14.0.20020507130355.00a9db58@harmless.inf.tu-dresden.de> X-Sender: gikaru@harmless.inf.tu-dresden.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 07 May 2002 13:10:30 +0200 To: Ram Ramanathan From: gikaru Subject: Re: [manet] Dumb Question? Cc: manet@ietf.org In-Reply-To: <200205062304.TAA85247@crystal.bbn.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Ram Your explanation is correct and appreciable but does not fully answer the question posed. The question is "What term is used in MANETs for the wired term routing ?" I personally would use the same term "routing in MANETs" while we wait for the "right term" to emerge. Willy At 19:04 06.05.2002 -0400, you wrote: >John, > >I don't believe there is a term for this. > >Note that the path is implied by which node decides to rebroadcast and >which doesn't. The set of decisions of the nodes, made in a distributed >manner, decides the "route" of the packet. Thus, one could argue this >is still "routing" >from a global perspective, even though, from a node-specific viewpoint >it may be different from what is being done traditionally. > >A couple months ago I also observed this, and was wondering if it could >somehow simplify routing. It turns out that in order to decide whether to >rebroadcast or not, a node has to look at which node the packet came >from (plus the destination). Thus, you have a "previous hop" table >instead of a next hop table, and each entry says one of three things -- >keep, discard, rebroadcast. In other words, even though the node >does not "direct" the packet in the "forward" direction, it does so >implicitly *from* the "backward" direction. > >This leads to a mirror image of traditional routing with everything >in reverse, but with sort of the same underlying constraints, although you >may be able to have a smaller routing table (gintour table?:). This >is a nice little thing for some bright grad student to see if there >are any hidden nuggets. And coin a term and be famous, of course:) > >-Ram. > > > > > > > > From: Mullen, John P. (Contractor) > > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > > Sent: Monday, May 06, 2002 2:08 PM > > To: manet@ietf.org > > Subject: [manet] Dumb Question? > > > > > > Hello, > > > > I am looking for a term, but have had no luck. > > > > In wired nets, a packet is routed through the network from node to > node, say > > by routing tables. However, in MANETs, in which packets are broadcast via > > omnidirectional antennae on a shared channel, such a thing is not possible. > > Instead, each node that receives a packet decides to: > > 1. Discard the packet, > > 2. "Read" the packet, since it is addressed to the node, and/or > > 3. Rebroadcast the packet. > > > > If the node is not to be an intermediary node in the end-to-end path > between > > the source and the destination, or if the node is receiving a copy of a > > packet it had previously broadcast, it will not broadcast the packet. This > > is necessary to avoid overutilizing the channel. > > > > If the node is an intermediary node on the path, then it must rebroadcast > > the packet. > > > > I've got this much figured out, but what I do not know is what this process > > is called. It is the MANET equivalent to "routing," but is not really > > routing, since the sending node has no way of directing the packet. > > > > I've tried a number of searches and read a few glossaries, but have not > been > > able to find this term. > > > > I'd appreciate any help. > > > > Thanks, > > > > John P. Mullen > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet Willy _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 7 08:28:34 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 IAA04628 for ; Tue, 7 May 2002 08:28:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18170; Tue, 7 May 2002 07:48:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18136 for ; Tue, 7 May 2002 07:48:05 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03326 for ; Tue, 7 May 2002 07:47:58 -0400 (EDT) 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 KNM9B69S; Tue, 7 May 2002 07:48:02 -0400 Message-ID: <013f01c1f5bd$0b075ae0$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Ram Ramanathan" , "gikaru" Cc: References: <5.1.0.14.0.20020507130355.00a9db58@harmless.inf.tu-dresden.de> Subject: Re: [manet] Dumb Question? Date: Tue, 7 May 2002 07:48:02 -0400 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 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit I find some of the comments more interesting than the original question. Is not AODV a particular implementation of an algorithm that solves the shortest path between all points problem? Is it not equivalent to the distributed bellman ford algorithm? I wonder why would choose not to call this routing??? ----- Original Message ----- From: "gikaru" To: "Ram Ramanathan" Cc: Sent: Tuesday, May 07, 2002 7:10 AM Subject: Re: [manet] Dumb Question? > Ram > Your explanation is correct and appreciable but does not fully answer the > question posed. The question is "What term is used in MANETs for the wired > term routing ?" I personally would use the same term "routing in MANETs" > while we wait for the "right term" to emerge. > Willy > > At 19:04 06.05.2002 -0400, you wrote: > > >John, > > > >I don't believe there is a term for this. > > > >Note that the path is implied by which node decides to rebroadcast and > >which doesn't. The set of decisions of the nodes, made in a distributed > >manner, decides the "route" of the packet. Thus, one could argue this > >is still "routing" > >from a global perspective, even though, from a node-specific viewpoint > >it may be different from what is being done traditionally. > > > >A couple months ago I also observed this, and was wondering if it could > >somehow simplify routing. It turns out that in order to decide whether to > >rebroadcast or not, a node has to look at which node the packet came > >from (plus the destination). Thus, you have a "previous hop" table > >instead of a next hop table, and each entry says one of three things -- > >keep, discard, rebroadcast. In other words, even though the node > >does not "direct" the packet in the "forward" direction, it does so > >implicitly *from* the "backward" direction. > > > >This leads to a mirror image of traditional routing with everything > >in reverse, but with sort of the same underlying constraints, although you > >may be able to have a smaller routing table (gintour table?:). This > >is a nice little thing for some bright grad student to see if there > >are any hidden nuggets. And coin a term and be famous, of course:) > > > >-Ram. > > > > > > > > > > > > > > > From: Mullen, John P. (Contractor) > > > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > > > Sent: Monday, May 06, 2002 2:08 PM > > > To: manet@ietf.org > > > Subject: [manet] Dumb Question? > > > > > > > > > Hello, > > > > > > I am looking for a term, but have had no luck. > > > > > > In wired nets, a packet is routed through the network from node to > > node, say > > > by routing tables. However, in MANETs, in which packets are broadcast via > > > omnidirectional antennae on a shared channel, such a thing is not possible. > > > Instead, each node that receives a packet decides to: > > > 1. Discard the packet, > > > 2. "Read" the packet, since it is addressed to the node, and/or > > > 3. Rebroadcast the packet. > > > > > > If the node is not to be an intermediary node in the end-to-end path > > between > > > the source and the destination, or if the node is receiving a copy of a > > > packet it had previously broadcast, it will not broadcast the packet. This > > > is necessary to avoid overutilizing the channel. > > > > > > If the node is an intermediary node on the path, then it must rebroadcast > > > the packet. > > > > > > I've got this much figured out, but what I do not know is what this process > > > is called. It is the MANET equivalent to "routing," but is not really > > > routing, since the sending node has no way of directing the packet. > > > > > > I've tried a number of searches and read a few glossaries, but have not > > been > > > able to find this term. > > > > > > I'd appreciate any help. > > > > > > Thanks, > > > > > > John P. Mullen > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > > > > > > > > > >_______________________________________________ > >manet mailing list > >manet@ietf.org > >https://www1.ietf.org/mailman/listinfo/manet > > Willy > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue May 7 08:28:39 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 IAA04637 for ; Tue, 7 May 2002 08:28:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20581 for manet-archive@odin.ietf.org; Tue, 7 May 2002 08:28:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18170; Tue, 7 May 2002 07:48:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18136 for ; Tue, 7 May 2002 07:48:05 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03326 for ; Tue, 7 May 2002 07:47:58 -0400 (EDT) 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 KNM9B69S; Tue, 7 May 2002 07:48:02 -0400 Message-ID: <013f01c1f5bd$0b075ae0$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Ram Ramanathan" , "gikaru" Cc: References: <5.1.0.14.0.20020507130355.00a9db58@harmless.inf.tu-dresden.de> Subject: Re: [manet] Dumb Question? Date: Tue, 7 May 2002 07:48:02 -0400 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 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit I find some of the comments more interesting than the original question. Is not AODV a particular implementation of an algorithm that solves the shortest path between all points problem? Is it not equivalent to the distributed bellman ford algorithm? I wonder why would choose not to call this routing??? ----- Original Message ----- From: "gikaru" To: "Ram Ramanathan" Cc: Sent: Tuesday, May 07, 2002 7:10 AM Subject: Re: [manet] Dumb Question? > Ram > Your explanation is correct and appreciable but does not fully answer the > question posed. The question is "What term is used in MANETs for the wired > term routing ?" I personally would use the same term "routing in MANETs" > while we wait for the "right term" to emerge. > Willy > > At 19:04 06.05.2002 -0400, you wrote: > > >John, > > > >I don't believe there is a term for this. > > > >Note that the path is implied by which node decides to rebroadcast and > >which doesn't. The set of decisions of the nodes, made in a distributed > >manner, decides the "route" of the packet. Thus, one could argue this > >is still "routing" > >from a global perspective, even though, from a node-specific viewpoint > >it may be different from what is being done traditionally. > > > >A couple months ago I also observed this, and was wondering if it could > >somehow simplify routing. It turns out that in order to decide whether to > >rebroadcast or not, a node has to look at which node the packet came > >from (plus the destination). Thus, you have a "previous hop" table > >instead of a next hop table, and each entry says one of three things -- > >keep, discard, rebroadcast. In other words, even though the node > >does not "direct" the packet in the "forward" direction, it does so > >implicitly *from* the "backward" direction. > > > >This leads to a mirror image of traditional routing with everything > >in reverse, but with sort of the same underlying constraints, although you > >may be able to have a smaller routing table (gintour table?:). This > >is a nice little thing for some bright grad student to see if there > >are any hidden nuggets. And coin a term and be famous, of course:) > > > >-Ram. > > > > > > > > > > > > > > > From: Mullen, John P. (Contractor) > > > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > > > Sent: Monday, May 06, 2002 2:08 PM > > > To: manet@ietf.org > > > Subject: [manet] Dumb Question? > > > > > > > > > Hello, > > > > > > I am looking for a term, but have had no luck. > > > > > > In wired nets, a packet is routed through the network from node to > > node, say > > > by routing tables. However, in MANETs, in which packets are broadcast via > > > omnidirectional antennae on a shared channel, such a thing is not possible. > > > Instead, each node that receives a packet decides to: > > > 1. Discard the packet, > > > 2. "Read" the packet, since it is addressed to the node, and/or > > > 3. Rebroadcast the packet. > > > > > > If the node is not to be an intermediary node in the end-to-end path > > between > > > the source and the destination, or if the node is receiving a copy of a > > > packet it had previously broadcast, it will not broadcast the packet. This > > > is necessary to avoid overutilizing the channel. > > > > > > If the node is an intermediary node on the path, then it must rebroadcast > > > the packet. > > > > > > I've got this much figured out, but what I do not know is what this process > > > is called. It is the MANET equivalent to "routing," but is not really > > > routing, since the sending node has no way of directing the packet. > > > > > > I've tried a number of searches and read a few glossaries, but have not > > been > > > able to find this term. > > > > > > I'd appreciate any help. > > > > > > Thanks, > > > > > > John P. Mullen > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > > > > > > > > > >_______________________________________________ > >manet mailing list > >manet@ietf.org > >https://www1.ietf.org/mailman/listinfo/manet > > Willy > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 7 08:56:23 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 IAA03968 for ; Tue, 7 May 2002 08:05:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15280; Tue, 7 May 2002 07:10:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15253 for ; Tue, 7 May 2002 07:10:33 -0400 (EDT) Received: from mephisto.inf.tu-dresden.de (mephisto.inf.tu-dresden.de [141.76.40.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02010 for ; Tue, 7 May 2002 07:10:25 -0400 (EDT) Received: from acer.rn.inf.tu-dresden.de (acer.inf.tu-dresden.de [141.76.40.88]) by mephisto.inf.tu-dresden.de (8.8.7/8.8.7) with ESMTP id NAA08239; Tue, 7 May 2002 13:10:19 +0200 (MET DST) Message-Id: <5.1.0.14.0.20020507130355.00a9db58@harmless.inf.tu-dresden.de> X-Sender: gikaru@harmless.inf.tu-dresden.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 07 May 2002 13:10:30 +0200 To: Ram Ramanathan From: gikaru Subject: Re: [manet] Dumb Question? Cc: manet@ietf.org In-Reply-To: <200205062304.TAA85247@crystal.bbn.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Ram Your explanation is correct and appreciable but does not fully answer the question posed. The question is "What term is used in MANETs for the wired term routing ?" I personally would use the same term "routing in MANETs" while we wait for the "right term" to emerge. Willy At 19:04 06.05.2002 -0400, you wrote: >John, > >I don't believe there is a term for this. > >Note that the path is implied by which node decides to rebroadcast and >which doesn't. The set of decisions of the nodes, made in a distributed >manner, decides the "route" of the packet. Thus, one could argue this >is still "routing" >from a global perspective, even though, from a node-specific viewpoint >it may be different from what is being done traditionally. > >A couple months ago I also observed this, and was wondering if it could >somehow simplify routing. It turns out that in order to decide whether to >rebroadcast or not, a node has to look at which node the packet came >from (plus the destination). Thus, you have a "previous hop" table >instead of a next hop table, and each entry says one of three things -- >keep, discard, rebroadcast. In other words, even though the node >does not "direct" the packet in the "forward" direction, it does so >implicitly *from* the "backward" direction. > >This leads to a mirror image of traditional routing with everything >in reverse, but with sort of the same underlying constraints, although you >may be able to have a smaller routing table (gintour table?:). This >is a nice little thing for some bright grad student to see if there >are any hidden nuggets. And coin a term and be famous, of course:) > >-Ram. > > > > > > > > From: Mullen, John P. (Contractor) > > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > > Sent: Monday, May 06, 2002 2:08 PM > > To: manet@ietf.org > > Subject: [manet] Dumb Question? > > > > > > Hello, > > > > I am looking for a term, but have had no luck. > > > > In wired nets, a packet is routed through the network from node to > node, say > > by routing tables. However, in MANETs, in which packets are broadcast via > > omnidirectional antennae on a shared channel, such a thing is not possible. > > Instead, each node that receives a packet decides to: > > 1. Discard the packet, > > 2. "Read" the packet, since it is addressed to the node, and/or > > 3. Rebroadcast the packet. > > > > If the node is not to be an intermediary node in the end-to-end path > between > > the source and the destination, or if the node is receiving a copy of a > > packet it had previously broadcast, it will not broadcast the packet. This > > is necessary to avoid overutilizing the channel. > > > > If the node is an intermediary node on the path, then it must rebroadcast > > the packet. > > > > I've got this much figured out, but what I do not know is what this process > > is called. It is the MANET equivalent to "routing," but is not really > > routing, since the sending node has no way of directing the packet. > > > > I've tried a number of searches and read a few glossaries, but have not > been > > able to find this term. > > > > I'd appreciate any help. > > > > Thanks, > > > > John P. Mullen > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet Willy _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 7 10:31:47 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 KAA09771 for ; Tue, 7 May 2002 10:31:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26398; Tue, 7 May 2002 09:52:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26367 for ; Tue, 7 May 2002 09:52:33 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08164 for ; Tue, 7 May 2002 09:52:20 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g47Dpvn16987 for ; Tue, 7 May 2002 15:51:57 +0200 (MET DST) Message-ID: <005901c1f5d1$528c9740$3ac033c1@inria.fr> From: "Philippe Jacquet" To: References: <5.1.0.14.0.20020507130355.00a9db58@harmless.inf.tu-dresden.de> <013f01c1f5bd$0b075ae0$6200000a@meshnetworks.com> Subject: Re: [manet] Dumb Question? Date: Tue, 7 May 2002 16:13:11 +0200 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Strictly speaking AODV is not equivalent to a distributed Bellman Ford algorithm as DSDV was. The shortest path obtained by flooding may be longer than the absolute shortest path. This is routing anyhow. Philippe ----- Original Message ----- From: Phil Neumiller To: Ram Ramanathan ; gikaru Cc: Sent: Tuesday, May 07, 2002 1:48 PM Subject: Re: [manet] Dumb Question? > I find some of the comments more interesting than the original question. Is not > AODV a particular implementation of an algorithm that solves the shortest path > between all points problem? Is it not equivalent to the distributed bellman ford > algorithm? I wonder why would choose not to call this routing??? > > > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue May 7 10:31:47 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 KAA09780 for ; Tue, 7 May 2002 10:31:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29633 for manet-archive@odin.ietf.org; Tue, 7 May 2002 10:31:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26398; Tue, 7 May 2002 09:52:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26367 for ; Tue, 7 May 2002 09:52:33 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08164 for ; Tue, 7 May 2002 09:52:20 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g47Dpvn16987 for ; Tue, 7 May 2002 15:51:57 +0200 (MET DST) Message-ID: <005901c1f5d1$528c9740$3ac033c1@inria.fr> From: "Philippe Jacquet" To: References: <5.1.0.14.0.20020507130355.00a9db58@harmless.inf.tu-dresden.de> <013f01c1f5bd$0b075ae0$6200000a@meshnetworks.com> Subject: Re: [manet] Dumb Question? Date: Tue, 7 May 2002 16:13:11 +0200 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Strictly speaking AODV is not equivalent to a distributed Bellman Ford algorithm as DSDV was. The shortest path obtained by flooding may be longer than the absolute shortest path. This is routing anyhow. Philippe ----- Original Message ----- From: Phil Neumiller To: Ram Ramanathan ; gikaru Cc: Sent: Tuesday, May 07, 2002 1:48 PM Subject: Re: [manet] Dumb Question? > I find some of the comments more interesting than the original question. Is not > AODV a particular implementation of an algorithm that solves the shortest path > between all points problem? Is it not equivalent to the distributed bellman ford > algorithm? I wonder why would choose not to call this routing??? > > > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 8 11:21:08 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 LAA12168 for ; Wed, 8 May 2002 11:21:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00131; Wed, 8 May 2002 10:24:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00098 for ; Wed, 8 May 2002 10:24:51 -0400 (EDT) Received: from mail.ececs.uc.edu (mail.ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08864 for ; Wed, 8 May 2002 10:24:42 -0400 (EDT) Received: from capricorn.rhod.uc.edu (capricorn.rhod.uc.edu [10.63.7.117]) by mail.ececs.uc.edu (8.12.2/8.12.2) with ESMTP id g48EOKxH001759 for ; Wed, 8 May 2002 10:24:20 -0400 (EDT) Received: from localhost (luyy@localhost) by capricorn.rhod.uc.edu (8.9.3/8.9.1) with ESMTP id KAA01544 for ; Wed, 8 May 2002 10:24:19 -0400 X-Authentication-Warning: capricorn.rhod.uc.edu: luyy owned process doing -bs Date: Wed, 8 May 2002 10:24:19 -0400 (EDT) From: Yi Lv X-Sender: luyy@capricorn.rhod.uc.edu To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] 802.11 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 Hi, all: First, i'm not sure if it's appropriate to put my questions here.:) As you know, 802.11 defines not only the MAC layer, but also the physical layer. I am not very familiar with the physical layer, such as DSSS. On my understanding, DSSS should be fighting for some interference. Does that mean from the MAC layer point of view, it is possible that physical layer offers the unicast service? While the mac layer seems to assume only broadcast can be done by physical layer. If unicast can be implemented by physical layer, the probability of collisions should be less than the current assumption. Can anyone tell me what's the prototype for the model of physical layer in ns-2 or some other simulators? Thanks a lot! Yi Lu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed May 8 11:21:08 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 LAA12178 for ; Wed, 8 May 2002 11:21:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05763 for manet-archive@odin.ietf.org; Wed, 8 May 2002 11:21:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00131; Wed, 8 May 2002 10:24:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00098 for ; Wed, 8 May 2002 10:24:51 -0400 (EDT) Received: from mail.ececs.uc.edu (mail.ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08864 for ; Wed, 8 May 2002 10:24:42 -0400 (EDT) Received: from capricorn.rhod.uc.edu (capricorn.rhod.uc.edu [10.63.7.117]) by mail.ececs.uc.edu (8.12.2/8.12.2) with ESMTP id g48EOKxH001759 for ; Wed, 8 May 2002 10:24:20 -0400 (EDT) Received: from localhost (luyy@localhost) by capricorn.rhod.uc.edu (8.9.3/8.9.1) with ESMTP id KAA01544 for ; Wed, 8 May 2002 10:24:19 -0400 X-Authentication-Warning: capricorn.rhod.uc.edu: luyy owned process doing -bs Date: Wed, 8 May 2002 10:24:19 -0400 (EDT) From: Yi Lv X-Sender: luyy@capricorn.rhod.uc.edu To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] 802.11 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 Hi, all: First, i'm not sure if it's appropriate to put my questions here.:) As you know, 802.11 defines not only the MAC layer, but also the physical layer. I am not very familiar with the physical layer, such as DSSS. On my understanding, DSSS should be fighting for some interference. Does that mean from the MAC layer point of view, it is possible that physical layer offers the unicast service? While the mac layer seems to assume only broadcast can be done by physical layer. If unicast can be implemented by physical layer, the probability of collisions should be less than the current assumption. Can anyone tell me what's the prototype for the model of physical layer in ns-2 or some other simulators? Thanks a lot! Yi Lu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 8 13:22:45 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 NAA17076 for ; Wed, 8 May 2002 13:22:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13581; Wed, 8 May 2002 12:47:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13548 for ; Wed, 8 May 2002 12:47:15 -0400 (EDT) Received: from kuma.upv.es (kuma.cc.upv.es [158.42.4.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16151 for ; Wed, 8 May 2002 12:47:07 -0400 (EDT) Received: from pop.upv.es (maia.cc.upv.es [158.42.4.11]) by kuma.upv.es (8.9.3/8.9.3) with ESMTP id SAA03816; Wed, 8 May 2002 18:47:02 +0200 Received: from smtp2.upv.es (smtp.cc.upv.es [158.42.250.10]) by pop.upv.es (8.11.3/8.11.3) with ESMTP id g48Gl1T11683; Wed, 8 May 2002 18:47:01 +0200 (METDST) Received: from miguelsa (msanchez.disca.upv.es [158.42.53.17]) by smtp2.upv.es (8.11.4/8.11.4) with SMTP id g48Gl0L28501; Wed, 8 May 2002 18:47:01 +0200 Message-ID: <009d01c1f6af$da707f80$11352a9e@miguelsa> From: "Miguel Sanchez" To: "Yi Lv" , References: Subject: Re: [manet] 802.11 Date: Wed, 8 May 2002 18:46:07 +0200 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hi, > As you know, 802.11 defines not only the MAC layer, but also the physical > layer. I am not very familiar with the physical layer, such as DSSS. On my > understanding, DSSS should be fighting for some interference. Does that > mean from the MAC layer point of view, it is possible that physical layer > offers the unicast service? While the mac layer seems to assume only > broadcast can be done by physical layer. If unicast can be implemented by > physical layer, the probability of collisions should be less than the > current assumption. It depends on what your assumptions are about the available antenna(s). The use of some kind of directional antennas can change the broadcast nature of the physical medium. Some papers have proposed such a scheme, either tied to a single radio or to multiple transceivers per node. > > Can anyone tell me what's the prototype for the model of physical layer > in ns-2 or some other simulators? ns-2 has two propagation models: free space and two-ray ground reflection (equations shown below , copied from the source code comments). /* * Friis free space propagation equation: * * Pt * Gt * Gr * (lambda^2) * P = -------------------------- * (4 *pi * d)^2 * L */ /* * if d < crossover_dist, use Friis free space model * if d >= crossover_dist, use two ray model * * Two-ray ground reflection model. * * Pt * Gt * Gr * (ht^2 * hr^2) * Pr = ---------------------------- * d^4 * L * * The original equation in Rappaport's book assumes L = 1. * To be consistant with the free space equation, L is added here. */ I hope this helps, Miguel Sanchez -- Universidad Politecnica de Valencia Camino de Vera, 14 46022 VALENCIA (Spain) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed May 8 13:22:46 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 NAA17093 for ; Wed, 8 May 2002 13:22:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA16227 for manet-archive@odin.ietf.org; Wed, 8 May 2002 13:22:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13581; Wed, 8 May 2002 12:47:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13548 for ; Wed, 8 May 2002 12:47:15 -0400 (EDT) Received: from kuma.upv.es (kuma.cc.upv.es [158.42.4.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16151 for ; Wed, 8 May 2002 12:47:07 -0400 (EDT) Received: from pop.upv.es (maia.cc.upv.es [158.42.4.11]) by kuma.upv.es (8.9.3/8.9.3) with ESMTP id SAA03816; Wed, 8 May 2002 18:47:02 +0200 Received: from smtp2.upv.es (smtp.cc.upv.es [158.42.250.10]) by pop.upv.es (8.11.3/8.11.3) with ESMTP id g48Gl1T11683; Wed, 8 May 2002 18:47:01 +0200 (METDST) Received: from miguelsa (msanchez.disca.upv.es [158.42.53.17]) by smtp2.upv.es (8.11.4/8.11.4) with SMTP id g48Gl0L28501; Wed, 8 May 2002 18:47:01 +0200 Message-ID: <009d01c1f6af$da707f80$11352a9e@miguelsa> From: "Miguel Sanchez" To: "Yi Lv" , References: Subject: Re: [manet] 802.11 Date: Wed, 8 May 2002 18:46:07 +0200 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hi, > As you know, 802.11 defines not only the MAC layer, but also the physical > layer. I am not very familiar with the physical layer, such as DSSS. On my > understanding, DSSS should be fighting for some interference. Does that > mean from the MAC layer point of view, it is possible that physical layer > offers the unicast service? While the mac layer seems to assume only > broadcast can be done by physical layer. If unicast can be implemented by > physical layer, the probability of collisions should be less than the > current assumption. It depends on what your assumptions are about the available antenna(s). The use of some kind of directional antennas can change the broadcast nature of the physical medium. Some papers have proposed such a scheme, either tied to a single radio or to multiple transceivers per node. > > Can anyone tell me what's the prototype for the model of physical layer > in ns-2 or some other simulators? ns-2 has two propagation models: free space and two-ray ground reflection (equations shown below , copied from the source code comments). /* * Friis free space propagation equation: * * Pt * Gt * Gr * (lambda^2) * P = -------------------------- * (4 *pi * d)^2 * L */ /* * if d < crossover_dist, use Friis free space model * if d >= crossover_dist, use two ray model * * Two-ray ground reflection model. * * Pt * Gt * Gr * (ht^2 * hr^2) * Pr = ---------------------------- * d^4 * L * * The original equation in Rappaport's book assumes L = 1. * To be consistant with the free space equation, L is added here. */ I hope this helps, Miguel Sanchez -- Universidad Politecnica de Valencia Camino de Vera, 14 46022 VALENCIA (Spain) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 8 18:17:44 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 SAA25176 for ; Wed, 8 May 2002 18:17:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00084; Wed, 8 May 2002 17:43:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00055 for ; Wed, 8 May 2002 17:43:13 -0400 (EDT) Received: from aspen.cs.ucla.edu (Aspen.CS.UCLA.EDU [131.179.120.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24554 for ; Wed, 8 May 2002 17:43:04 -0400 (EDT) Received: from cs.ucla.edu (Buck.CS.UCLA.EDU [131.179.120.25]) by aspen.cs.ucla.edu (8.11.2/UCLACS-5.0) with ESMTP id g48LfVM03647; Wed, 8 May 2002 14:41:31 -0700 (PDT) Message-ID: <3CD99B92.F3CC6C53@cs.ucla.edu> Date: Wed, 08 May 2002 14:41:38 -0700 From: Mineo Takai X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Yi Lv CC: manet@ietf.org Subject: Re: [manet] 802.11 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hello Yi, The IEEE 802.11 DSSS PHY specifies a single 11-bit spreading code, which means that its DSSS does not help reduce interference from other 802.11 radios. It should help if the interference source is something else, like microwave ovens, hair dryers, or jammers in military scenarios. The IEEE 802.11 DSSS PHY models in common manet simulators (ns-2, GloMoSim, QualNet and OPNET) do not simulate spreading/despreading, and that should be fine unless non-802.11 noise sources are involved in the simulation scenario. Mineo Takai Yi Lv wrote: > > Hi, all: > > First, i'm not sure if it's appropriate to put my questions here.:) > > As you know, 802.11 defines not only the MAC layer, but also the physical > layer. I am not very familiar with the physical layer, such as DSSS. On my > understanding, DSSS should be fighting for some interference. Does that > mean from the MAC layer point of view, it is possible that physical layer > offers the unicast service? While the mac layer seems to assume only > broadcast can be done by physical layer. If unicast can be implemented by > physical layer, the probability of collisions should be less than the > current assumption. > > Can anyone tell me what's the prototype for the model of physical layer > in ns-2 or some other simulators? > > Thanks a lot! > Yi Lu > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed May 8 18:17:45 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 SAA25188 for ; Wed, 8 May 2002 18:17:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA02156 for manet-archive@odin.ietf.org; Wed, 8 May 2002 18:17:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00084; Wed, 8 May 2002 17:43:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00055 for ; Wed, 8 May 2002 17:43:13 -0400 (EDT) Received: from aspen.cs.ucla.edu (Aspen.CS.UCLA.EDU [131.179.120.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24554 for ; Wed, 8 May 2002 17:43:04 -0400 (EDT) Received: from cs.ucla.edu (Buck.CS.UCLA.EDU [131.179.120.25]) by aspen.cs.ucla.edu (8.11.2/UCLACS-5.0) with ESMTP id g48LfVM03647; Wed, 8 May 2002 14:41:31 -0700 (PDT) Message-ID: <3CD99B92.F3CC6C53@cs.ucla.edu> Date: Wed, 08 May 2002 14:41:38 -0700 From: Mineo Takai X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Yi Lv CC: manet@ietf.org Subject: Re: [manet] 802.11 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hello Yi, The IEEE 802.11 DSSS PHY specifies a single 11-bit spreading code, which means that its DSSS does not help reduce interference from other 802.11 radios. It should help if the interference source is something else, like microwave ovens, hair dryers, or jammers in military scenarios. The IEEE 802.11 DSSS PHY models in common manet simulators (ns-2, GloMoSim, QualNet and OPNET) do not simulate spreading/despreading, and that should be fine unless non-802.11 noise sources are involved in the simulation scenario. Mineo Takai Yi Lv wrote: > > Hi, all: > > First, i'm not sure if it's appropriate to put my questions here.:) > > As you know, 802.11 defines not only the MAC layer, but also the physical > layer. I am not very familiar with the physical layer, such as DSSS. On my > understanding, DSSS should be fighting for some interference. Does that > mean from the MAC layer point of view, it is possible that physical layer > offers the unicast service? While the mac layer seems to assume only > broadcast can be done by physical layer. If unicast can be implemented by > physical layer, the probability of collisions should be less than the > current assumption. > > Can anyone tell me what's the prototype for the model of physical layer > in ns-2 or some other simulators? > > Thanks a lot! > Yi Lu > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 8 22:11:46 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 WAA29588 for ; Wed, 8 May 2002 22:11:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10261; Wed, 8 May 2002 21:16:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10232 for ; Wed, 8 May 2002 21:16:25 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27821 for ; Wed, 8 May 2002 21:16:16 -0400 (EDT) From: haas@ece.cornell.edu Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g491GM117795; Wed, 8 May 2002 21:16:22 -0400 Date: Wed, 8 May 2002 21:16:16 -0400 (EDT) X-Sender: haas@verdi.ee.cornell.edu To: Mineo Takai cc: manet@ietf.org Subject: Re: [manet] 802.11 In-Reply-To: <3CD99B92.F3CC6C53@cs.ucla.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hi Mineo, On Wed, 8 May 2002, Mineo Takai wrote: > The IEEE 802.11 DSSS PHY specifies a single 11-bit spreading code, which > means that its DSSS does not help reduce interference from other 802.11 > radios. It should help if the interference source is something else, > like microwave ovens, hair dryers, or jammers in military scenarios. I am not sure that this is correct. Even if there is a *single* spreading sequence, but the sequence is with low autocorrelation function (for all time shifts, except at the orgin), then the spreading *does* provide some degree of interference reduction. The key here is that the transmissions from different nodes will not be chip-synchronized. Thus, due to the low autocorrelation, there will be some rejection of the other transmissions. Best, Zygmunt. ==--==-=-=== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed May 8 22:11:47 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 WAA29599 for ; Wed, 8 May 2002 22:11:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA13770 for manet-archive@odin.ietf.org; Wed, 8 May 2002 22:11:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10261; Wed, 8 May 2002 21:16:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10232 for ; Wed, 8 May 2002 21:16:25 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27821 for ; Wed, 8 May 2002 21:16:16 -0400 (EDT) From: haas@ece.cornell.edu Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g491GM117795; Wed, 8 May 2002 21:16:22 -0400 Date: Wed, 8 May 2002 21:16:16 -0400 (EDT) X-Sender: haas@verdi.ee.cornell.edu To: Mineo Takai cc: manet@ietf.org Subject: Re: [manet] 802.11 In-Reply-To: <3CD99B92.F3CC6C53@cs.ucla.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hi Mineo, On Wed, 8 May 2002, Mineo Takai wrote: > The IEEE 802.11 DSSS PHY specifies a single 11-bit spreading code, which > means that its DSSS does not help reduce interference from other 802.11 > radios. It should help if the interference source is something else, > like microwave ovens, hair dryers, or jammers in military scenarios. I am not sure that this is correct. Even if there is a *single* spreading sequence, but the sequence is with low autocorrelation function (for all time shifts, except at the orgin), then the spreading *does* provide some degree of interference reduction. The key here is that the transmissions from different nodes will not be chip-synchronized. Thus, due to the low autocorrelation, there will be some rejection of the other transmissions. Best, Zygmunt. ==--==-=-=== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 8 22:29:38 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 WAA00054 for ; Wed, 8 May 2002 22:29:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA12173; Wed, 8 May 2002 21:48:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA12145 for ; Wed, 8 May 2002 21:48:30 -0400 (EDT) Received: from mail.ececs.uc.edu (mail.ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29265 for ; Wed, 8 May 2002 21:48:20 -0400 (EDT) Received: from capricorn.rhod.uc.edu (capricorn.rhod.uc.edu [10.63.7.117]) by mail.ececs.uc.edu (8.12.2/8.12.2) with ESMTP id g491lRxH022570; Wed, 8 May 2002 21:47:27 -0400 (EDT) Received: from localhost (luyy@localhost) by capricorn.rhod.uc.edu (8.9.3/8.9.1) with ESMTP id VAA01915; Wed, 8 May 2002 21:47:27 -0400 X-Authentication-Warning: capricorn.rhod.uc.edu: luyy owned process doing -bs Date: Wed, 8 May 2002 21:47:27 -0400 (EDT) From: Yi Lv X-Sender: luyy@capricorn.rhod.uc.edu To: Mineo Takai cc: manet@ietf.org Subject: Re: [manet] 802.11 In-Reply-To: <3CD99B92.F3CC6C53@cs.ucla.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hi, Mineo: On Wed, 8 May 2002, Mineo Takai wrote: > Hello Yi, > > The IEEE 802.11 DSSS PHY specifies a single 11-bit spreading code, which > means that its DSSS does not help reduce interference from other 802.11 > radios. It should help if the interference source is something else, > like microwave ovens, hair dryers, or jammers in military scenarios. What's the reason why only one spreading code is used? Is that because it's hard to deploy different spreading codes to each node? Since only one code is used, what's the benifit of DSSS? Only to avoid the interference with other devices, which use the different codes? Thanks a lot! Yi Lu > > The IEEE 802.11 DSSS PHY models in common manet simulators (ns-2, > GloMoSim, QualNet and OPNET) do not simulate spreading/despreading, and > that should be fine unless non-802.11 noise sources are involved in the > simulation scenario. > > Mineo Takai > > Yi Lv wrote: > > > > Hi, all: > > > > First, i'm not sure if it's appropriate to put my questions here.:) > > > > As you know, 802.11 defines not only the MAC layer, but also the physical > > layer. I am not very familiar with the physical layer, such as DSSS. On my > > understanding, DSSS should be fighting for some interference. Does that > > mean from the MAC layer point of view, it is possible that physical layer > > offers the unicast service? While the mac layer seems to assume only > > broadcast can be done by physical layer. If unicast can be implemented by > > physical layer, the probability of collisions should be less than the > > current assumption. > > > > Can anyone tell me what's the prototype for the model of physical layer > > in ns-2 or some other simulators? > > > > Thanks a lot! > > Yi Lu > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed May 8 22:29:39 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 WAA00064 for ; Wed, 8 May 2002 22:29:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA14751 for manet-archive@odin.ietf.org; Wed, 8 May 2002 22:29:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA12173; Wed, 8 May 2002 21:48:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA12145 for ; Wed, 8 May 2002 21:48:30 -0400 (EDT) Received: from mail.ececs.uc.edu (mail.ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29265 for ; Wed, 8 May 2002 21:48:20 -0400 (EDT) Received: from capricorn.rhod.uc.edu (capricorn.rhod.uc.edu [10.63.7.117]) by mail.ececs.uc.edu (8.12.2/8.12.2) with ESMTP id g491lRxH022570; Wed, 8 May 2002 21:47:27 -0400 (EDT) Received: from localhost (luyy@localhost) by capricorn.rhod.uc.edu (8.9.3/8.9.1) with ESMTP id VAA01915; Wed, 8 May 2002 21:47:27 -0400 X-Authentication-Warning: capricorn.rhod.uc.edu: luyy owned process doing -bs Date: Wed, 8 May 2002 21:47:27 -0400 (EDT) From: Yi Lv X-Sender: luyy@capricorn.rhod.uc.edu To: Mineo Takai cc: manet@ietf.org Subject: Re: [manet] 802.11 In-Reply-To: <3CD99B92.F3CC6C53@cs.ucla.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hi, Mineo: On Wed, 8 May 2002, Mineo Takai wrote: > Hello Yi, > > The IEEE 802.11 DSSS PHY specifies a single 11-bit spreading code, which > means that its DSSS does not help reduce interference from other 802.11 > radios. It should help if the interference source is something else, > like microwave ovens, hair dryers, or jammers in military scenarios. What's the reason why only one spreading code is used? Is that because it's hard to deploy different spreading codes to each node? Since only one code is used, what's the benifit of DSSS? Only to avoid the interference with other devices, which use the different codes? Thanks a lot! Yi Lu > > The IEEE 802.11 DSSS PHY models in common manet simulators (ns-2, > GloMoSim, QualNet and OPNET) do not simulate spreading/despreading, and > that should be fine unless non-802.11 noise sources are involved in the > simulation scenario. > > Mineo Takai > > Yi Lv wrote: > > > > Hi, all: > > > > First, i'm not sure if it's appropriate to put my questions here.:) > > > > As you know, 802.11 defines not only the MAC layer, but also the physical > > layer. I am not very familiar with the physical layer, such as DSSS. On my > > understanding, DSSS should be fighting for some interference. Does that > > mean from the MAC layer point of view, it is possible that physical layer > > offers the unicast service? While the mac layer seems to assume only > > broadcast can be done by physical layer. If unicast can be implemented by > > physical layer, the probability of collisions should be less than the > > current assumption. > > > > Can anyone tell me what's the prototype for the model of physical layer > > in ns-2 or some other simulators? > > > > Thanks a lot! > > Yi Lu > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 9 04:45:15 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 EAA14148 for ; Thu, 9 May 2002 04:45:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07550; Thu, 9 May 2002 03:47:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07510 for ; Thu, 9 May 2002 03:47:36 -0400 (EDT) Received: from kuma.upv.es (kuma.cc.upv.es [158.42.4.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13486 for ; Thu, 9 May 2002 03:47:25 -0400 (EDT) Received: from pop.upv.es (maia.cc.upv.es [158.42.4.11]) by kuma.upv.es (8.9.3/8.9.3) with ESMTP id JAA31611; Thu, 9 May 2002 09:47:25 +0200 Received: from smtp2.upv.es (smtp.cc.upv.es [158.42.250.10]) by pop.upv.es (8.11.3/8.11.3) with ESMTP id g497lOT18640; Thu, 9 May 2002 09:47:24 +0200 (METDST) Received: from miguelsa (msanchez.disca.upv.es [158.42.53.17]) by smtp2.upv.es (8.11.4/8.11.4) with SMTP id g497lNL27200; Thu, 9 May 2002 09:47:24 +0200 Message-ID: <00e001c1f72d$a71c4000$11352a9e@miguelsa> From: "Miguel Sanchez" To: "Yi Lv" , "Mineo Takai" Cc: References: Subject: Re: [manet] 802.11 Date: Thu, 9 May 2002 09:46:38 +0200 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hi, > What's the reason why only one spreading code is used? Is that because > it's hard to deploy different spreading codes to each node? A single shared channel is achieved when all the nodes use the same channel. If you use different codes/channels you make MAC (and multihop routing) more complex than if you just use a common channel. (Most receivers can only correlate receiver signal with one predifined code). > Since only one code is used, what's the benifit of DSSS? Only to avoid the > interference with other devices, which use the different codes? It is my understanting that DSSS allows a more graceful degradation as noise floor raises than narrow band transmission. Using 802.11 an unlicensed band, where pontetially you can have multiple sources of interference, the goal was to create a interference resilient system. Regards, Miguel Sanchez -- Universidad Politecnica de Valencia Camino de Vera, 14 46022 VALENCIA (Spain) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu May 9 05:31:40 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 EAA14157 for ; Thu, 9 May 2002 04:45:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA10734 for manet-archive@odin.ietf.org; Thu, 9 May 2002 04:45:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07550; Thu, 9 May 2002 03:47:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07510 for ; Thu, 9 May 2002 03:47:36 -0400 (EDT) Received: from kuma.upv.es (kuma.cc.upv.es [158.42.4.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13486 for ; Thu, 9 May 2002 03:47:25 -0400 (EDT) Received: from pop.upv.es (maia.cc.upv.es [158.42.4.11]) by kuma.upv.es (8.9.3/8.9.3) with ESMTP id JAA31611; Thu, 9 May 2002 09:47:25 +0200 Received: from smtp2.upv.es (smtp.cc.upv.es [158.42.250.10]) by pop.upv.es (8.11.3/8.11.3) with ESMTP id g497lOT18640; Thu, 9 May 2002 09:47:24 +0200 (METDST) Received: from miguelsa (msanchez.disca.upv.es [158.42.53.17]) by smtp2.upv.es (8.11.4/8.11.4) with SMTP id g497lNL27200; Thu, 9 May 2002 09:47:24 +0200 Message-ID: <00e001c1f72d$a71c4000$11352a9e@miguelsa> From: "Miguel Sanchez" To: "Yi Lv" , "Mineo Takai" Cc: References: Subject: Re: [manet] 802.11 Date: Thu, 9 May 2002 09:46:38 +0200 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hi, > What's the reason why only one spreading code is used? Is that because > it's hard to deploy different spreading codes to each node? A single shared channel is achieved when all the nodes use the same channel. If you use different codes/channels you make MAC (and multihop routing) more complex than if you just use a common channel. (Most receivers can only correlate receiver signal with one predifined code). > Since only one code is used, what's the benifit of DSSS? Only to avoid the > interference with other devices, which use the different codes? It is my understanting that DSSS allows a more graceful degradation as noise floor raises than narrow band transmission. Using 802.11 an unlicensed band, where pontetially you can have multiple sources of interference, the goal was to create a interference resilient system. Regards, Miguel Sanchez -- Universidad Politecnica de Valencia Camino de Vera, 14 46022 VALENCIA (Spain) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 9 10:41:18 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 KAA24391 for ; Thu, 9 May 2002 10:41:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27671; Thu, 9 May 2002 10:00:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27624 for ; Thu, 9 May 2002 10:00:31 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22043 for ; Thu, 9 May 2002 10:00:21 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA18638; Thu, 9 May 2002 07:00:28 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA28851; Thu, 9 May 2002 09:00:17 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g49E0GG27507; Thu, 9 May 2002 07:00:16 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 May 2002 10:00:16 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3900@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Miguel Sanchez'" Cc: manet@ietf.org Subject: RE: [manet] 802.11 Date: Thu, 9 May 2002 10:00:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 > -----Original Message----- > From: Miguel Sanchez [mailto:misan@ieee.org] > > Hi, > > > What's the reason why only one spreading code is used? Is > that because > > it's hard to deploy different spreading codes to each node? > > A single shared channel is achieved when all the nodes use > the same channel. > If you use different codes/channels you make MAC (and > multihop routing) more > complex than if you just use a common channel. (Most > receivers can only > correlate receiver signal with one predifined code). This sounds right to me. In CDMA cellular telephones, multiple spreading codes are used, because each mobile sets up a different connection with the base station (and from there, the PSTN). You don't want two mobiles interfering with one another. You don't want two conversations to be superimposed. The connections of other phones sharing the same frequency band appear as background noise (the codes are not completely orthogonal). But IEEE 802.11 is meant to be Ethernet-like, in the sense that every mobile host is _supposed_ to hear the others in that same wireless LAN. The LAN's bandwidth is shared by collision detection and backoff, rather than by assigning different codes to each mobile. Much as the medium is shared in a wired Ethernet. Using different codes would create multiple wireless LANs. > > Since only one code is used, what's the benifit of DSSS? > Only to avoid the > > interference with other devices, which use the different codes? > > It is my understanting that DSSS allows a more graceful > degradation as noise > floor raises than narrow band transmission. Using 802.11 an > unlicensed band, > where pontetially you can have multiple sources of > interference, the goal > was to create a interference resilient system. Sounds right to me as well. Any kind of spread spectrum is a mechanism to allow sharing a given frequency band. The only question here is whether or not the users of _an_ IEEE 802.11 network want to hear on another or not, and I believe the answer is that they must hear one another. Bert albert.e.manfredi@boeing.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu May 9 10:41:19 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 KAA24400 for ; Thu, 9 May 2002 10:41:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01068 for manet-archive@odin.ietf.org; Thu, 9 May 2002 10:41:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27671; Thu, 9 May 2002 10:00:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27624 for ; Thu, 9 May 2002 10:00:31 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22043 for ; Thu, 9 May 2002 10:00:21 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA18638; Thu, 9 May 2002 07:00:28 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA28851; Thu, 9 May 2002 09:00:17 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g49E0GG27507; Thu, 9 May 2002 07:00:16 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 May 2002 10:00:16 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3900@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Miguel Sanchez'" Cc: manet@ietf.org Subject: RE: [manet] 802.11 Date: Thu, 9 May 2002 10:00:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 > -----Original Message----- > From: Miguel Sanchez [mailto:misan@ieee.org] > > Hi, > > > What's the reason why only one spreading code is used? Is > that because > > it's hard to deploy different spreading codes to each node? > > A single shared channel is achieved when all the nodes use > the same channel. > If you use different codes/channels you make MAC (and > multihop routing) more > complex than if you just use a common channel. (Most > receivers can only > correlate receiver signal with one predifined code). This sounds right to me. In CDMA cellular telephones, multiple spreading codes are used, because each mobile sets up a different connection with the base station (and from there, the PSTN). You don't want two mobiles interfering with one another. You don't want two conversations to be superimposed. The connections of other phones sharing the same frequency band appear as background noise (the codes are not completely orthogonal). But IEEE 802.11 is meant to be Ethernet-like, in the sense that every mobile host is _supposed_ to hear the others in that same wireless LAN. The LAN's bandwidth is shared by collision detection and backoff, rather than by assigning different codes to each mobile. Much as the medium is shared in a wired Ethernet. Using different codes would create multiple wireless LANs. > > Since only one code is used, what's the benifit of DSSS? > Only to avoid the > > interference with other devices, which use the different codes? > > It is my understanting that DSSS allows a more graceful > degradation as noise > floor raises than narrow band transmission. Using 802.11 an > unlicensed band, > where pontetially you can have multiple sources of > interference, the goal > was to create a interference resilient system. Sounds right to me as well. Any kind of spread spectrum is a mechanism to allow sharing a given frequency band. The only question here is whether or not the users of _an_ IEEE 802.11 network want to hear on another or not, and I believe the answer is that they must hear one another. Bert albert.e.manfredi@boeing.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 9 13:27:03 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 NAA01566 for ; Thu, 9 May 2002 13:27:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08538; Thu, 9 May 2002 12:49:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24085 for ; Tue, 30 Apr 2002 09:33:56 -0400 (EDT) Received: from web11504.mail.yahoo.com (web11504.mail.yahoo.com [216.136.172.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19696 for ; Tue, 30 Apr 2002 09:33:53 -0400 (EDT) Message-ID: <20020430133355.97782.qmail@web11504.mail.yahoo.com> Received: from [133.1.52.47] by web11504.mail.yahoo.com via HTTP; Tue, 30 Apr 2002 06:33:55 PDT Date: Tue, 30 Apr 2002 06:33:55 -0700 (PDT) From: ricky wang To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] AODV control packet length: 32 bits ? 32 bytes? 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 Hello, I have read the AODV internet draft version 10. In the draft, it is stated that the control packet length is 32. May I know whether it means 32 bits or 32 bytes ? I am still new in ad-hoc networking research. Thank you for your kind advice. Regards, Ricky __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu May 9 13:27:04 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 NAA01576 for ; Thu, 9 May 2002 13:27:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11267 for manet-archive@odin.ietf.org; Thu, 9 May 2002 13:27:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08538; Thu, 9 May 2002 12:49:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24085 for ; Tue, 30 Apr 2002 09:33:56 -0400 (EDT) Received: from web11504.mail.yahoo.com (web11504.mail.yahoo.com [216.136.172.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19696 for ; Tue, 30 Apr 2002 09:33:53 -0400 (EDT) Message-ID: <20020430133355.97782.qmail@web11504.mail.yahoo.com> Received: from [133.1.52.47] by web11504.mail.yahoo.com via HTTP; Tue, 30 Apr 2002 06:33:55 PDT Date: Tue, 30 Apr 2002 06:33:55 -0700 (PDT) From: ricky wang To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] AODV control packet length: 32 bits ? 32 bytes? 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 Hello, I have read the AODV internet draft version 10. In the draft, it is stated that the control packet length is 32. May I know whether it means 32 bits or 32 bytes ? I am still new in ad-hoc networking research. Thank you for your kind advice. Regards, Ricky __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 9 13:34:44 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 NAA01807 for ; Thu, 9 May 2002 13:34:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08507; Thu, 9 May 2002 12:49:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01383 for ; Tue, 30 Apr 2002 11:18:07 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24714 for ; Tue, 30 Apr 2002 11:18:02 -0400 (EDT) Message-ID: <006901c1f059$fb2b5080$7e6015ac@T23KEMPF> From: "James Kempf" To: "Phil Neumiller" , "Scott Corson" , , "Dr. Chane L. Fullmer" Cc: "Carl Williams" , "Aaron Falk" References: <8C92E23A3E87FB479988285F9E22BE4699472E@ftmail> <02cd01c1efb5$13356530$6200000a@meshnetworks.com> <023f01c1efca$f8bf3f80$7e6015ac@T23KEMPF> <031101c1f03c$f45af430$6200000a@meshnetworks.com> Subject: Re: [manet] Link API was [ Link layer notification ] Date: Tue, 30 Apr 2002 08:16:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit There was a pre-BOF, I believe the decision was to use the PILC mailing list for discussion. Aaron and Carl, who were chairs can say more. I assume we will be having a full BOF in Yokohama. jak ----- Original Message ----- From: "Phil Neumiller" To: "James Kempf" ; "Scott Corson" ; ; "Dr. Chane L. Fullmer" Cc: "Carl Williams" ; "Aaron Falk" Sent: Tuesday, April 30, 2002 4:48 AM Subject: Re: [manet] Link API was [ Link layer notification ] > James, > > I was unable to make that BOF. Did it happen? Is there a list? I was going to write up > a draft and just throw it at the IESG to see if it sicks and where they stick it. My interests > are WLAN/MANET primarily. I do not want to create anything to heavy, just something > immediately useful facilitating QoS and security issues with ad hoc wireless devices. Is there > a web page for the BOF? > > Thanks, > > Phil > > ----- Original Message ----- > From: "James Kempf" > To: "Phil Neumiller" ; "Scott Corson" ; ; "Dr. Chane L. Fullmer" > > Cc: "Carl Williams" ; "Aaron Falk" > Sent: Monday, April 29, 2002 6:12 PM > Subject: Re: [manet] Link API was [ Link layer notification ] > > > > Phil, > > > > I think these would be of potential interest to the L2 triggers BOF. > > > > jak > > > > ----- Original Message ----- > > From: "Phil Neumiller" > > To: "Scott Corson" ; ; "Dr. Chane L. > > Fullmer" > > Cc: "James Kempf" > > Sent: Monday, April 29, 2002 12:35 PM > > Subject: Re: [manet] Link API was [ Link layer notification ] > > > > > > > Hi Scott, > > > > > > I have some drafty draft stuff too. Is anybody else interested in > > this? I will start writing a draft > > > since I have been "complaining" about this for years, so its time for > > me to put up or shut up. :-) > > > I will start the water boiling for the spaghetti and mail my own > > drafty draft to folks that are > > > interested. Also, if I missing some major body of work that has > > happened on this matter in > > > the IETF or elsewhere could somebody kindly point it out to me (its > > pretty hard to keep up > > > with so much stuff)? > > > > > > The most essential things to me seem to be: > > > > > > 1). A generic interrupting system, where L2 can "call" (or call back > > / publish / tigger) something to > > > the underbelly of IP and tell it something has happened. That > > something could simply be > > > a code with no qualification or a code with complete TLV > > qualification, as long as the IP > > > layers interpretation is consitent there is not a problem. > > > > > > This type of mechanism could be the basis for a generic L2 > > signaling mechanism. It could also > > > be the basis for passing link status up to (and even more > > importantly through the IP layer > > > as out of band data (OOBD)). Routing mechanisms residing above > > or at the IP layer would > > > very much like to use information passed from the link layer. > > I suggest using the model view > > > controller model for this. > > > > > > Subscriber ---> Publisher > > > ^ ^ > > > | | > > > View --------> Model <---- Controller > > > > > > Where say a MANET routing protocol is a subcriber to certain > > classes of L2 information such as > > > pilot notification or received signal strentgth indication > > RSSI. Some of these will be wireless > > > specific, some optics specific etc, but either way they are > > not tied to any particular L2. > > > > > > 2). Certain categories of these triggers are essential "base class" > > triggers, i.e. get a hunk of > > > signaling info (possibly in the form of TLV) up to IP > > efficiently. The more L2 independent > > > the better (please don't suggest ASN.1!). > > > > > > 3). It is necessary for IP to support a plethora of LLC/MAC(L2s) > > simultaneously. Each of these > > > L2s will have different behaviour classifications for TTL, > > TOS fields etc. It will be important > > > to abstract the behaviors across many different L2s so that > > the particular L2 does not have > > > to be identified, only its interaction pattern with IP. > > > > > > 4). One could also postulate multiple stacks on a host (IPv4 and > > IPv6 at least) where it may be > > > desirable for the L2 to send IPv4 packets one way and others > > another way. Also, one could > > > imagine running multiple stacks per virtual machine on some > > hosts and having the L2 send > > > the traffic to the properly bound host IP stack (IPsec with > > multiple many hostile users comes > > > to mind). > > > > > > Thanks, > > > > > > Phil > > > > > > > > > ----- Original Message ----- > > > From: "Scott Corson" > > > To: "'Phil Neumiller'" ; > > ; "Dr. Chane L. Fullmer" > > > Sent: Monday, April 29, 2002 2:30 PM > > > Subject: RE: [manet] Link API was [ Link layer notification ] > > > > > > > > > > > > > > > Yes, it would be very interesting to see. I am not so much > > > > > interested in standardizing the > > > > > LLC/MAC layer API for the use of IP, as I am standardizing > > > > > the bottom half of IP looking > > > > > in from an LLC/MAC perspective. > > > > > > > > Phil, > > > > > > > > I'll second that, and I can see you're interested in building > > something > > > > useful... ;-) > > > > > > > > I've got a drafty draft written along these lines in hopes of an > > eventual L2 > > > > triggers BOF...very drafty of course as I've zero time to put into > > this. > > > > Maybe we should each throw some pasta at the IESG wall and see if > > anything > > > > sticks. ;-) > > > > > > > > -Scott > > > > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu May 9 13:34:45 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 NAA01816 for ; Thu, 9 May 2002 13:34:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA12111 for manet-archive@odin.ietf.org; Thu, 9 May 2002 13:34:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08507; Thu, 9 May 2002 12:49:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01383 for ; Tue, 30 Apr 2002 11:18:07 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24714 for ; Tue, 30 Apr 2002 11:18:02 -0400 (EDT) Message-ID: <006901c1f059$fb2b5080$7e6015ac@T23KEMPF> From: "James Kempf" To: "Phil Neumiller" , "Scott Corson" , , "Dr. Chane L. Fullmer" Cc: "Carl Williams" , "Aaron Falk" References: <8C92E23A3E87FB479988285F9E22BE4699472E@ftmail> <02cd01c1efb5$13356530$6200000a@meshnetworks.com> <023f01c1efca$f8bf3f80$7e6015ac@T23KEMPF> <031101c1f03c$f45af430$6200000a@meshnetworks.com> Subject: Re: [manet] Link API was [ Link layer notification ] Date: Tue, 30 Apr 2002 08:16:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit There was a pre-BOF, I believe the decision was to use the PILC mailing list for discussion. Aaron and Carl, who were chairs can say more. I assume we will be having a full BOF in Yokohama. jak ----- Original Message ----- From: "Phil Neumiller" To: "James Kempf" ; "Scott Corson" ; ; "Dr. Chane L. Fullmer" Cc: "Carl Williams" ; "Aaron Falk" Sent: Tuesday, April 30, 2002 4:48 AM Subject: Re: [manet] Link API was [ Link layer notification ] > James, > > I was unable to make that BOF. Did it happen? Is there a list? I was going to write up > a draft and just throw it at the IESG to see if it sicks and where they stick it. My interests > are WLAN/MANET primarily. I do not want to create anything to heavy, just something > immediately useful facilitating QoS and security issues with ad hoc wireless devices. Is there > a web page for the BOF? > > Thanks, > > Phil > > ----- Original Message ----- > From: "James Kempf" > To: "Phil Neumiller" ; "Scott Corson" ; ; "Dr. Chane L. Fullmer" > > Cc: "Carl Williams" ; "Aaron Falk" > Sent: Monday, April 29, 2002 6:12 PM > Subject: Re: [manet] Link API was [ Link layer notification ] > > > > Phil, > > > > I think these would be of potential interest to the L2 triggers BOF. > > > > jak > > > > ----- Original Message ----- > > From: "Phil Neumiller" > > To: "Scott Corson" ; ; "Dr. Chane L. > > Fullmer" > > Cc: "James Kempf" > > Sent: Monday, April 29, 2002 12:35 PM > > Subject: Re: [manet] Link API was [ Link layer notification ] > > > > > > > Hi Scott, > > > > > > I have some drafty draft stuff too. Is anybody else interested in > > this? I will start writing a draft > > > since I have been "complaining" about this for years, so its time for > > me to put up or shut up. :-) > > > I will start the water boiling for the spaghetti and mail my own > > drafty draft to folks that are > > > interested. Also, if I missing some major body of work that has > > happened on this matter in > > > the IETF or elsewhere could somebody kindly point it out to me (its > > pretty hard to keep up > > > with so much stuff)? > > > > > > The most essential things to me seem to be: > > > > > > 1). A generic interrupting system, where L2 can "call" (or call back > > / publish / tigger) something to > > > the underbelly of IP and tell it something has happened. That > > something could simply be > > > a code with no qualification or a code with complete TLV > > qualification, as long as the IP > > > layers interpretation is consitent there is not a problem. > > > > > > This type of mechanism could be the basis for a generic L2 > > signaling mechanism. It could also > > > be the basis for passing link status up to (and even more > > importantly through the IP layer > > > as out of band data (OOBD)). Routing mechanisms residing above > > or at the IP layer would > > > very much like to use information passed from the link layer. > > I suggest using the model view > > > controller model for this. > > > > > > Subscriber ---> Publisher > > > ^ ^ > > > | | > > > View --------> Model <---- Controller > > > > > > Where say a MANET routing protocol is a subcriber to certain > > classes of L2 information such as > > > pilot notification or received signal strentgth indication > > RSSI. Some of these will be wireless > > > specific, some optics specific etc, but either way they are > > not tied to any particular L2. > > > > > > 2). Certain categories of these triggers are essential "base class" > > triggers, i.e. get a hunk of > > > signaling info (possibly in the form of TLV) up to IP > > efficiently. The more L2 independent > > > the better (please don't suggest ASN.1!). > > > > > > 3). It is necessary for IP to support a plethora of LLC/MAC(L2s) > > simultaneously. Each of these > > > L2s will have different behaviour classifications for TTL, > > TOS fields etc. It will be important > > > to abstract the behaviors across many different L2s so that > > the particular L2 does not have > > > to be identified, only its interaction pattern with IP. > > > > > > 4). One could also postulate multiple stacks on a host (IPv4 and > > IPv6 at least) where it may be > > > desirable for the L2 to send IPv4 packets one way and others > > another way. Also, one could > > > imagine running multiple stacks per virtual machine on some > > hosts and having the L2 send > > > the traffic to the properly bound host IP stack (IPsec with > > multiple many hostile users comes > > > to mind). > > > > > > Thanks, > > > > > > Phil > > > > > > > > > ----- Original Message ----- > > > From: "Scott Corson" > > > To: "'Phil Neumiller'" ; > > ; "Dr. Chane L. Fullmer" > > > Sent: Monday, April 29, 2002 2:30 PM > > > Subject: RE: [manet] Link API was [ Link layer notification ] > > > > > > > > > > > > > > > Yes, it would be very interesting to see. I am not so much > > > > > interested in standardizing the > > > > > LLC/MAC layer API for the use of IP, as I am standardizing > > > > > the bottom half of IP looking > > > > > in from an LLC/MAC perspective. > > > > > > > > Phil, > > > > > > > > I'll second that, and I can see you're interested in building > > something > > > > useful... ;-) > > > > > > > > I've got a drafty draft written along these lines in hopes of an > > eventual L2 > > > > triggers BOF...very drafty of course as I've zero time to put into > > this. > > > > Maybe we should each throw some pasta at the IESG wall and see if > > anything > > > > sticks. ;-) > > > > > > > > -Scott > > > > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 9 18:07:53 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 SAA11667 for ; Thu, 9 May 2002 18:07:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26176; Thu, 9 May 2002 17:42:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26147 for ; Thu, 9 May 2002 17:42:14 -0400 (EDT) Received: from mithrandir.scalable-networks.com (lsanca1-ar3-159-091.biz.dsl.gtei.net [4.33.159.91]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10605 for ; Thu, 9 May 2002 17:42:01 -0400 (EDT) Received: (qmail 29662 invoked from network); 9 May 2002 21:42:33 -0000 Received: from lsanca1-ar3-159-090.biz.dsl.gtei.net (HELO cs.ucla.edu) (mineo@4.33.159.90) by 192.168.0.160 with SMTP; 9 May 2002 21:42:33 -0000 Message-ID: <3CDAED7C.11D786D@cs.ucla.edu> Date: Thu, 09 May 2002 14:43:25 -0700 From: Mineo Takai X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: haas@ece.cornell.edu CC: manet@ietf.org Subject: Re: [manet] 802.11 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hi Zygmunt, I admit that DSSS may provide some processing gain even if interfering signals use the same spreading code, but I do not know how much gain we would get. I do not usually simulate systems in chip level, but will talk to EE friends if it is worth analyzing. Regards, Mineo haas@ece.cornell.edu wrote: > > Hi Mineo, > > On Wed, 8 May 2002, Mineo Takai wrote: > > The IEEE 802.11 DSSS PHY specifies a single 11-bit spreading code, which > > means that its DSSS does not help reduce interference from other 802.11 > > radios. It should help if the interference source is something else, > > like microwave ovens, hair dryers, or jammers in military scenarios. > > I am not sure that this is correct. Even if there is a *single* spreading > sequence, but the sequence is with low autocorrelation function (for all > time shifts, except at the orgin), then the spreading *does* provide some > degree of interference reduction. The key here is that the transmissions > from different nodes will not be chip-synchronized. Thus, due to the low > autocorrelation, there will be some rejection of the other transmissions. > > Best, > > Zygmunt. > ==--==-=-=== > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > Wireless Networks Laboratory http://wnl.ece.cornell.edu > School of Electrical Engineering > Cornell University tel: +1-607-255-3454 > 323 Frank Rhodes Hall fax: +1-607-255-9072 > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > U.S.A > WNL web page: http://wnl.ece.cornell.edu > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu May 9 18:07:53 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 SAA11677 for ; Thu, 9 May 2002 18:07:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28055 for manet-archive@odin.ietf.org; Thu, 9 May 2002 18:08:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26176; Thu, 9 May 2002 17:42:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26147 for ; Thu, 9 May 2002 17:42:14 -0400 (EDT) Received: from mithrandir.scalable-networks.com (lsanca1-ar3-159-091.biz.dsl.gtei.net [4.33.159.91]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10605 for ; Thu, 9 May 2002 17:42:01 -0400 (EDT) Received: (qmail 29662 invoked from network); 9 May 2002 21:42:33 -0000 Received: from lsanca1-ar3-159-090.biz.dsl.gtei.net (HELO cs.ucla.edu) (mineo@4.33.159.90) by 192.168.0.160 with SMTP; 9 May 2002 21:42:33 -0000 Message-ID: <3CDAED7C.11D786D@cs.ucla.edu> Date: Thu, 09 May 2002 14:43:25 -0700 From: Mineo Takai X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: haas@ece.cornell.edu CC: manet@ietf.org Subject: Re: [manet] 802.11 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hi Zygmunt, I admit that DSSS may provide some processing gain even if interfering signals use the same spreading code, but I do not know how much gain we would get. I do not usually simulate systems in chip level, but will talk to EE friends if it is worth analyzing. Regards, Mineo haas@ece.cornell.edu wrote: > > Hi Mineo, > > On Wed, 8 May 2002, Mineo Takai wrote: > > The IEEE 802.11 DSSS PHY specifies a single 11-bit spreading code, which > > means that its DSSS does not help reduce interference from other 802.11 > > radios. It should help if the interference source is something else, > > like microwave ovens, hair dryers, or jammers in military scenarios. > > I am not sure that this is correct. Even if there is a *single* spreading > sequence, but the sequence is with low autocorrelation function (for all > time shifts, except at the orgin), then the spreading *does* provide some > degree of interference reduction. The key here is that the transmissions > from different nodes will not be chip-synchronized. Thus, due to the low > autocorrelation, there will be some rejection of the other transmissions. > > Best, > > Zygmunt. > ==--==-=-=== > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > Wireless Networks Laboratory http://wnl.ece.cornell.edu > School of Electrical Engineering > Cornell University tel: +1-607-255-3454 > 323 Frank Rhodes Hall fax: +1-607-255-9072 > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > U.S.A > WNL web page: http://wnl.ece.cornell.edu > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 9 18:26:17 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 SAA12102 for ; Thu, 9 May 2002 18:26:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27635; Thu, 9 May 2002 18:01:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27608 for ; Thu, 9 May 2002 18:01:45 -0400 (EDT) Received: from mithrandir.scalable-networks.com (lsanca1-ar3-159-091.biz.dsl.gtei.net [4.33.159.91]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11491 for ; Thu, 9 May 2002 18:01:31 -0400 (EDT) Received: (qmail 23427 invoked from network); 9 May 2002 22:02:03 -0000 Received: from lsanca1-ar3-159-090.biz.dsl.gtei.net (HELO cs.ucla.edu) (mineo@4.33.159.90) by 192.168.0.160 with SMTP; 9 May 2002 22:02:03 -0000 Message-ID: <3CDAF212.E831114A@cs.ucla.edu> Date: Thu, 09 May 2002 15:02:58 -0700 From: Mineo Takai X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yi Lv CC: manet@ietf.org Subject: Re: [manet] 802.11 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hi Yi, I think other folks have already answered your questions. FYI, IEEE 802.11b includes CCK (Complementary Code Keying), which changes spreading codes dynamically. However, different codes are not used to reduce the interference, but to realize higher data rates. Regards, Mineo Yi Lv wrote: > > Hi, Mineo: > > On Wed, 8 May 2002, Mineo Takai wrote: > > > Hello Yi, > > > > The IEEE 802.11 DSSS PHY specifies a single 11-bit spreading code, which > > means that its DSSS does not help reduce interference from other 802.11 > > radios. It should help if the interference source is something else, > > like microwave ovens, hair dryers, or jammers in military scenarios. > > What's the reason why only one spreading code is used? Is that because > it's hard to deploy different spreading codes to each node? > > Since only one code is used, what's the benifit of DSSS? Only to avoid the > interference with other devices, which use the different codes? > > Thanks a lot! > Yi Lu > > > > > The IEEE 802.11 DSSS PHY models in common manet simulators (ns-2, > > GloMoSim, QualNet and OPNET) do not simulate spreading/despreading, and > > that should be fine unless non-802.11 noise sources are involved in the > > simulation scenario. > > > > Mineo Takai > > > > Yi Lv wrote: > > > > > > Hi, all: > > > > > > First, i'm not sure if it's appropriate to put my questions here.:) > > > > > > As you know, 802.11 defines not only the MAC layer, but also the physical > > > layer. I am not very familiar with the physical layer, such as DSSS. On my > > > understanding, DSSS should be fighting for some interference. Does that > > > mean from the MAC layer point of view, it is possible that physical layer > > > offers the unicast service? While the mac layer seems to assume only > > > broadcast can be done by physical layer. If unicast can be implemented by > > > physical layer, the probability of collisions should be less than the > > > current assumption. > > > > > > Can anyone tell me what's the prototype for the model of physical layer > > > in ns-2 or some other simulators? > > > > > > Thanks a lot! > > > Yi Lu > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu May 9 18:26:17 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 SAA12113 for ; Thu, 9 May 2002 18:26:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28868 for manet-archive@odin.ietf.org; Thu, 9 May 2002 18:26:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27635; Thu, 9 May 2002 18:01:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27608 for ; Thu, 9 May 2002 18:01:45 -0400 (EDT) Received: from mithrandir.scalable-networks.com (lsanca1-ar3-159-091.biz.dsl.gtei.net [4.33.159.91]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11491 for ; Thu, 9 May 2002 18:01:31 -0400 (EDT) Received: (qmail 23427 invoked from network); 9 May 2002 22:02:03 -0000 Received: from lsanca1-ar3-159-090.biz.dsl.gtei.net (HELO cs.ucla.edu) (mineo@4.33.159.90) by 192.168.0.160 with SMTP; 9 May 2002 22:02:03 -0000 Message-ID: <3CDAF212.E831114A@cs.ucla.edu> Date: Thu, 09 May 2002 15:02:58 -0700 From: Mineo Takai X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yi Lv CC: manet@ietf.org Subject: Re: [manet] 802.11 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hi Yi, I think other folks have already answered your questions. FYI, IEEE 802.11b includes CCK (Complementary Code Keying), which changes spreading codes dynamically. However, different codes are not used to reduce the interference, but to realize higher data rates. Regards, Mineo Yi Lv wrote: > > Hi, Mineo: > > On Wed, 8 May 2002, Mineo Takai wrote: > > > Hello Yi, > > > > The IEEE 802.11 DSSS PHY specifies a single 11-bit spreading code, which > > means that its DSSS does not help reduce interference from other 802.11 > > radios. It should help if the interference source is something else, > > like microwave ovens, hair dryers, or jammers in military scenarios. > > What's the reason why only one spreading code is used? Is that because > it's hard to deploy different spreading codes to each node? > > Since only one code is used, what's the benifit of DSSS? Only to avoid the > interference with other devices, which use the different codes? > > Thanks a lot! > Yi Lu > > > > > The IEEE 802.11 DSSS PHY models in common manet simulators (ns-2, > > GloMoSim, QualNet and OPNET) do not simulate spreading/despreading, and > > that should be fine unless non-802.11 noise sources are involved in the > > simulation scenario. > > > > Mineo Takai > > > > Yi Lv wrote: > > > > > > Hi, all: > > > > > > First, i'm not sure if it's appropriate to put my questions here.:) > > > > > > As you know, 802.11 defines not only the MAC layer, but also the physical > > > layer. I am not very familiar with the physical layer, such as DSSS. On my > > > understanding, DSSS should be fighting for some interference. Does that > > > mean from the MAC layer point of view, it is possible that physical layer > > > offers the unicast service? While the mac layer seems to assume only > > > broadcast can be done by physical layer. If unicast can be implemented by > > > physical layer, the probability of collisions should be less than the > > > current assumption. > > > > > > Can anyone tell me what's the prototype for the model of physical layer > > > in ns-2 or some other simulators? > > > > > > Thanks a lot! > > > Yi Lu > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri May 10 18:01:31 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 SAA20674 for ; Fri, 10 May 2002 18:01:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15528; Fri, 10 May 2002 17:31:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15505 for ; Fri, 10 May 2002 17:31:51 -0400 (EDT) Received: from ns0.utdallas.edu (ns0.utdallas.edu [129.110.10.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19297 for ; Fri, 10 May 2002 17:31:40 -0400 (EDT) Received: from dslab10 (dslab10.utdallas.edu [129.110.94.72]) by ns0.utdallas.edu (Postfix) with SMTP id 98AB81A149B for ; Fri, 10 May 2002 16:31:43 -0500 (CDT) Message-ID: <002a01c1f86a$35bdd660$485e6e81@dslab10> From: "Mansoor Mohsin" To: Date: Fri, 10 May 2002 16:32:39 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C1F840.4CAAC560" 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 Subject: [manet] POMC - Call for Papers 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 This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C1F840.4CAAC560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Call For Papers --------------- Preliminary Announcement and Call for Papers POMC 2002 Workshop on Principles of Mobile Computing October 30-31, 2002, Toulouse, France. Workshop URL: www.utdallas.edu/~ravip/pomc/POMC/POMC.html Sponsor: ACM SIGACT Accepted papers published by ACM Submission deadline : July 5, 2002 To be held in conjunction with International Symposium on DIStributed = Computing (DISC 2002) http://www.enseeiht.fr/~disc02/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mobile computing and communications devices are proliferating in recent = years. The mobility of distributed computing components raises a number = of interesting, and difficult, algorithmic issues. This two-day workshop is intended to bring together researchers in = mobile computing (especially, but not exclusively, ad hoc networks) and = distributed algorithms (especially, but not exclusively, dynamic = networks). To facilitate such interaction, the workshop is scheduled to = begin on the last day of DISC 2002. The planned format is a combination of contributed papers and one-hour = tutorials. Significant time for discussion will be allocated. It is = intended to be a lively and informal meeting, and to foster cooperation = among mobile computing systems researchers and distributed algorithms = theoreticians. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Topics ------ Papers are solicited in all research and applied areas that touch on the = application of, or need for, distributed algorithms in the context of = mobile computing systems. Papers covering work in progress are = especially welcome. Papers should describe original, previously = unpublished work that is not currently under review by another = conference, workshop, or journal. Specific topics include, but are not limited to: - distributed algorithms=20 - routing=20 - dynamic networks=20 - dynamic graph algorithms=20 - location tracking=20 - middleware=20 - security=20 - scheduling=20 - media access techniques=20 - quality-of-service issues=20 - sensor networks=20 - complexity analysis of algorithms for mobile environments=20 Please consult any member of the technical program committee if you are = uncertain whether your paper falls within the scope of the workshop. Submission Instructions ---------------------- Submission should be up to 10 pages in length with reasonable margins = and line spacing using at least 11-point font. Submission instructions will be available on the conference website. Important Dates: Paper Submissions Due: July 5, 2002 Notification of Acceptance: August 8, 2002 Camera-ready Version Due: August 30, 2002 Authors of accepted papers are expected to present their paper at the = workshop. FOR MORE INFORMATION: Check the workshop website or send email to Ravi = Prakash (ravip@utdallas.edu) Organsing Commitee =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D General Chair - Andre Schiper, EPFL=20 andre.schiper@epfl.ch=20 Technical Program Co-chairs - Roberto Baldoni, University of Rome "La Sapienza" baldoni@dis.uniroma1.it - Ravi Prakash, University of Texas at Dallas ravip@utdallas.edu Technical Program Committee - Maurizio Bonuccelli, University of Pisa bonucce@di.unipi.it=20 - Sandeep Gupta, Arizona State University sandeep.gupta@asu.edu=20 - David B. Johnson, Rice University dbj@cs.rice.edu=20 - Marc-Olivier Killijian, LAAS-CNRS=20 marco.killijian@laas.fr=20 - Amy Murphy, University of Rochester murphy@cs.rochester.edu=20 - Michel Raynal, IRISA=20 michel.raynal@irisa.fr=20 - Mukesh Singhal, University of Kentucky singhal@cs.uky.edu=20 Registration and Finance Chair - Xavier Defago, JAIST=20 defago@jaist.ac.jp=20 Local Arrangements Chair - Marc-Olivier Killijian, LAAS-CNRS=20 marco.killijian@laas.fr Webmaster and Publicity Co-chair - Mansoor Mohsin, University of Texas at Dallas mmohsin@utdallas.edu - Parag Agarwal, University of Texas at Dallas pxa016500@utdallas.edu Steering Committee - Nancy Lynch, MIT=20 lynch@theory.lcs.mit.edu=20 - Andre Schiper, EPFL=20 andre.schiper@epfl.ch=20 - Nitin Vaidya, University of Illinois at Urbana-Champaign nhv@uiuc.edu=20 - Jennifer Welch, Texas A&M University=20 welch@cs.tamu.edu -------------------------------------------------------------------------= ------- Mansoor Mohsin=20 ------=_NextPart_000_0027_01C1F840.4CAAC560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Call For=20 Papers
---------------
 
Preliminary = Announcement and Call=20 for Papers
 
POMC 2002
Workshop = on Principles=20 of Mobile Computing
October 30-31, 2002, Toulouse, = France.
 
Workshop URL: www.utdallas.= edu/~ravip/pomc/POMC/POMC.html
 
Sponsor: ACM = SIGACT
 
Accepted papers = published by=20 ACM
 
Submission deadline : = July 5,=20 2002
 
To be held in = conjunction with=20 International Symposium on DIStributed Computing (DISC 2002)
http://www.enseeiht.fr/~disc02/<= /A>
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
 
Mobile computing and = communications=20 devices are proliferating in recent years. The mobility of distributed = computing=20 components raises a number of interesting, and difficult, algorithmic=20 issues.
 
This two-day workshop = is intended=20 to bring together researchers in mobile computing (especially, but not=20 exclusively, ad hoc networks) and distributed algorithms (especially, = but not=20 exclusively, dynamic networks). To facilitate such interaction, the = workshop is=20 scheduled to begin on the last day of DISC 2002.
 
The planned format is = a combination=20 of contributed papers and one-hour tutorials. Significant time for = discussion=20 will be allocated. It is intended to be a lively and informal meeting, = and to=20 foster cooperation among mobile computing systems researchers and = distributed=20 algorithms theoreticians.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
 
Topics
------
 
Papers are solicited = in all=20 research and applied areas that touch on the application of, or need = for,=20 distributed algorithms in the context of mobile computing systems. = Papers=20 covering work in progress are especially welcome. Papers should describe = original, previously unpublished work that is not currently under review = by=20 another conference, workshop, or journal.
 
Specific topics = include, but are=20 not limited to:
 
- distributed = algorithms
-=20 routing
- dynamic networks
- dynamic graph algorithms
- = location=20 tracking
- middleware
- security
- scheduling
- media = access=20 techniques
- quality-of-service issues
- sensor networks
-=20 complexity analysis of algorithms for mobile environments
 
Please consult any = member of the=20 technical program committee if you are uncertain whether your paper = falls within=20 the scope of the workshop.
 
Submission=20 Instructions
----------------------
 
Submission should be = up to 10 pages=20 in length with reasonable margins and line spacing using at least = 11-point=20 font.
 
Submission = instructions will be=20 available on the conference website.
 
Important = Dates:
 
Paper Submissions = Due: July 5,=20 2002
Notification of Acceptance: August 8, = 2002
Camera-ready Version Due: August 30,=20 2002
Authors of accepted papers are = expected to=20 present their paper at the workshop.
 
FOR MORE INFORMATION: = Check the=20 workshop website or send  email to Ravi=20 Prakash (ravip@utdallas.edu)
 

Organsing = Commitee
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
General Chair
 
- Andre Schiper, EPFL
 
Technical Program Co-chairs
 
- Roberto Baldoni, University of Rome "La = Sapienza"
 =20 baldoni@dis.uniroma1.it
=
 
- Ravi Prakash, University of Texas at = Dallas
  ravip@utdallas.edu
 
Technical Program Committee
 
- Maurizio Bonuccelli, University of Pisa
  = bonucce@di.unipi.it
 
- Sandeep Gupta, Arizona State University
  = sandeep.gupta@asu.edu
 
- David B. Johnson, Rice University
  dbj@cs.rice.edu
 
- Marc-Olivier Killijian, LAAS-CNRS 
  = marco.killijian@laas.fr =
 
- Amy Murphy, University of Rochester
  murphy@cs.rochester.edu =
 
- Michel Raynal, IRISA 
  michel.raynal@irisa.fr
 
- Mukesh Singhal, University of Kentucky
  = singhal@cs.uky.edu
 
Registration and Finance Chair
 
- Xavier Defago, JAIST
 
Local Arrangements Chair
 
- Marc-Olivier Killijian, LAAS-CNRS 
  = marco.killijian@laas.fr
=
 
Webmaster and Publicity Co-chair
 
- Mansoor Mohsin, University of Texas at = Dallas
  mmohsin@utdallas.edu
 
- Parag Agarwal, University of Texas at = Dallas
  pxa016500@utdallas.edu
 
Steering Committee
 
- Nancy Lynch, MIT
  lynch@theory.lcs.mit.edu =
 
- Andre Schiper, EPFL
 
- Nitin Vaidya, University of Illinois at=20 Urbana-Champaign
  nhv@uiuc.edu
 
- Jennifer Welch, Texas A&M = University 
  welch@cs.tamu.edu

Mansoor=20 Mohsin
------=_NextPart_000_0027_01C1F840.4CAAC560-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri May 10 18:01:40 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 SAA20683 for ; Fri, 10 May 2002 18:01:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA17160 for manet-archive@odin.ietf.org; Fri, 10 May 2002 18:01:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15528; Fri, 10 May 2002 17:31:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15505 for ; Fri, 10 May 2002 17:31:51 -0400 (EDT) Received: from ns0.utdallas.edu (ns0.utdallas.edu [129.110.10.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19297 for ; Fri, 10 May 2002 17:31:40 -0400 (EDT) Received: from dslab10 (dslab10.utdallas.edu [129.110.94.72]) by ns0.utdallas.edu (Postfix) with SMTP id 98AB81A149B for ; Fri, 10 May 2002 16:31:43 -0500 (CDT) Message-ID: <002a01c1f86a$35bdd660$485e6e81@dslab10> From: "Mansoor Mohsin" To: Date: Fri, 10 May 2002 16:32:39 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C1F840.4CAAC560" 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 Subject: [manet] POMC - Call for Papers 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 This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C1F840.4CAAC560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Call For Papers --------------- Preliminary Announcement and Call for Papers POMC 2002 Workshop on Principles of Mobile Computing October 30-31, 2002, Toulouse, France. Workshop URL: www.utdallas.edu/~ravip/pomc/POMC/POMC.html Sponsor: ACM SIGACT Accepted papers published by ACM Submission deadline : July 5, 2002 To be held in conjunction with International Symposium on DIStributed = Computing (DISC 2002) http://www.enseeiht.fr/~disc02/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mobile computing and communications devices are proliferating in recent = years. The mobility of distributed computing components raises a number = of interesting, and difficult, algorithmic issues. This two-day workshop is intended to bring together researchers in = mobile computing (especially, but not exclusively, ad hoc networks) and = distributed algorithms (especially, but not exclusively, dynamic = networks). To facilitate such interaction, the workshop is scheduled to = begin on the last day of DISC 2002. The planned format is a combination of contributed papers and one-hour = tutorials. Significant time for discussion will be allocated. It is = intended to be a lively and informal meeting, and to foster cooperation = among mobile computing systems researchers and distributed algorithms = theoreticians. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Topics ------ Papers are solicited in all research and applied areas that touch on the = application of, or need for, distributed algorithms in the context of = mobile computing systems. Papers covering work in progress are = especially welcome. Papers should describe original, previously = unpublished work that is not currently under review by another = conference, workshop, or journal. Specific topics include, but are not limited to: - distributed algorithms=20 - routing=20 - dynamic networks=20 - dynamic graph algorithms=20 - location tracking=20 - middleware=20 - security=20 - scheduling=20 - media access techniques=20 - quality-of-service issues=20 - sensor networks=20 - complexity analysis of algorithms for mobile environments=20 Please consult any member of the technical program committee if you are = uncertain whether your paper falls within the scope of the workshop. Submission Instructions ---------------------- Submission should be up to 10 pages in length with reasonable margins = and line spacing using at least 11-point font. Submission instructions will be available on the conference website. Important Dates: Paper Submissions Due: July 5, 2002 Notification of Acceptance: August 8, 2002 Camera-ready Version Due: August 30, 2002 Authors of accepted papers are expected to present their paper at the = workshop. FOR MORE INFORMATION: Check the workshop website or send email to Ravi = Prakash (ravip@utdallas.edu) Organsing Commitee =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D General Chair - Andre Schiper, EPFL=20 andre.schiper@epfl.ch=20 Technical Program Co-chairs - Roberto Baldoni, University of Rome "La Sapienza" baldoni@dis.uniroma1.it - Ravi Prakash, University of Texas at Dallas ravip@utdallas.edu Technical Program Committee - Maurizio Bonuccelli, University of Pisa bonucce@di.unipi.it=20 - Sandeep Gupta, Arizona State University sandeep.gupta@asu.edu=20 - David B. Johnson, Rice University dbj@cs.rice.edu=20 - Marc-Olivier Killijian, LAAS-CNRS=20 marco.killijian@laas.fr=20 - Amy Murphy, University of Rochester murphy@cs.rochester.edu=20 - Michel Raynal, IRISA=20 michel.raynal@irisa.fr=20 - Mukesh Singhal, University of Kentucky singhal@cs.uky.edu=20 Registration and Finance Chair - Xavier Defago, JAIST=20 defago@jaist.ac.jp=20 Local Arrangements Chair - Marc-Olivier Killijian, LAAS-CNRS=20 marco.killijian@laas.fr Webmaster and Publicity Co-chair - Mansoor Mohsin, University of Texas at Dallas mmohsin@utdallas.edu - Parag Agarwal, University of Texas at Dallas pxa016500@utdallas.edu Steering Committee - Nancy Lynch, MIT=20 lynch@theory.lcs.mit.edu=20 - Andre Schiper, EPFL=20 andre.schiper@epfl.ch=20 - Nitin Vaidya, University of Illinois at Urbana-Champaign nhv@uiuc.edu=20 - Jennifer Welch, Texas A&M University=20 welch@cs.tamu.edu -------------------------------------------------------------------------= ------- Mansoor Mohsin=20 ------=_NextPart_000_0027_01C1F840.4CAAC560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Call For=20 Papers
---------------
 
Preliminary = Announcement and Call=20 for Papers
 
POMC 2002
Workshop = on Principles=20 of Mobile Computing
October 30-31, 2002, Toulouse, = France.
 
Workshop URL: www.utdallas.= edu/~ravip/pomc/POMC/POMC.html
 
Sponsor: ACM = SIGACT
 
Accepted papers = published by=20 ACM
 
Submission deadline : = July 5,=20 2002
 
To be held in = conjunction with=20 International Symposium on DIStributed Computing (DISC 2002)
http://www.enseeiht.fr/~disc02/<= /A>
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
 
Mobile computing and = communications=20 devices are proliferating in recent years. The mobility of distributed = computing=20 components raises a number of interesting, and difficult, algorithmic=20 issues.
 
This two-day workshop = is intended=20 to bring together researchers in mobile computing (especially, but not=20 exclusively, ad hoc networks) and distributed algorithms (especially, = but not=20 exclusively, dynamic networks). To facilitate such interaction, the = workshop is=20 scheduled to begin on the last day of DISC 2002.
 
The planned format is = a combination=20 of contributed papers and one-hour tutorials. Significant time for = discussion=20 will be allocated. It is intended to be a lively and informal meeting, = and to=20 foster cooperation among mobile computing systems researchers and = distributed=20 algorithms theoreticians.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
 
Topics
------
 
Papers are solicited = in all=20 research and applied areas that touch on the application of, or need = for,=20 distributed algorithms in the context of mobile computing systems. = Papers=20 covering work in progress are especially welcome. Papers should describe = original, previously unpublished work that is not currently under review = by=20 another conference, workshop, or journal.
 
Specific topics = include, but are=20 not limited to:
 
- distributed = algorithms
-=20 routing
- dynamic networks
- dynamic graph algorithms
- = location=20 tracking
- middleware
- security
- scheduling
- media = access=20 techniques
- quality-of-service issues
- sensor networks
-=20 complexity analysis of algorithms for mobile environments
 
Please consult any = member of the=20 technical program committee if you are uncertain whether your paper = falls within=20 the scope of the workshop.
 
Submission=20 Instructions
----------------------
 
Submission should be = up to 10 pages=20 in length with reasonable margins and line spacing using at least = 11-point=20 font.
 
Submission = instructions will be=20 available on the conference website.
 
Important = Dates:
 
Paper Submissions = Due: July 5,=20 2002
Notification of Acceptance: August 8, = 2002
Camera-ready Version Due: August 30,=20 2002
Authors of accepted papers are = expected to=20 present their paper at the workshop.
 
FOR MORE INFORMATION: = Check the=20 workshop website or send  email to Ravi=20 Prakash (ravip@utdallas.edu)
 

Organsing = Commitee
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
General Chair
 
- Andre Schiper, EPFL
 
Technical Program Co-chairs
 
- Roberto Baldoni, University of Rome "La = Sapienza"
 =20 baldoni@dis.uniroma1.it
=
 
- Ravi Prakash, University of Texas at = Dallas
  ravip@utdallas.edu
 
Technical Program Committee
 
- Maurizio Bonuccelli, University of Pisa
  = bonucce@di.unipi.it
 
- Sandeep Gupta, Arizona State University
  = sandeep.gupta@asu.edu
 
- David B. Johnson, Rice University
  dbj@cs.rice.edu
 
- Marc-Olivier Killijian, LAAS-CNRS 
  = marco.killijian@laas.fr =
 
- Amy Murphy, University of Rochester
  murphy@cs.rochester.edu =
 
- Michel Raynal, IRISA 
  michel.raynal@irisa.fr
 
- Mukesh Singhal, University of Kentucky
  = singhal@cs.uky.edu
 
Registration and Finance Chair
 
- Xavier Defago, JAIST
 
Local Arrangements Chair
 
- Marc-Olivier Killijian, LAAS-CNRS 
  = marco.killijian@laas.fr
=
 
Webmaster and Publicity Co-chair
 
- Mansoor Mohsin, University of Texas at = Dallas
  mmohsin@utdallas.edu
 
- Parag Agarwal, University of Texas at = Dallas
  pxa016500@utdallas.edu
 
Steering Committee
 
- Nancy Lynch, MIT
  lynch@theory.lcs.mit.edu =
 
- Andre Schiper, EPFL
 
- Nitin Vaidya, University of Illinois at=20 Urbana-Champaign
  nhv@uiuc.edu
 
- Jennifer Welch, Texas A&M = University 
  welch@cs.tamu.edu

Mansoor=20 Mohsin
------=_NextPart_000_0027_01C1F840.4CAAC560-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sat May 11 22:32:48 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 WAA24814 for ; Sat, 11 May 2002 22:32:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19729; Sat, 11 May 2002 21:49:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19700 for ; Sat, 11 May 2002 21:49:01 -0400 (EDT) Received: from sina.com ([202.106.187.143]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22750 for ; Sat, 11 May 2002 21:48:49 -0400 (EDT) Received: (qmail 6966 invoked by alias); 12 May 2002 01:43:03 -0000 Received: from unknown (HELO datou) (218.2.150.99) by 202.106.187.143 with SMTP; 12 May 2002 01:43:03 -0000 Message-ID: <002501c1f957$1c797f40$0e00a8c0@datou> From: "ywbsina" To: Date: Sun, 12 May 2002 09:48:26 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C1F99A.298F46E0" 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 Subject: [manet] the synchronous communication model 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 This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C1F99A.298F46E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsOg0KICAgSSdtIG5vdCB2ZXJ5IGNsZWFyIGFib3V0IHRoZSBzeW5jaHJvbm91cyBjb21t dW5pY2F0aW9uIG1vZGVsLklmIHRoZSBzeW5jaHJvbml6YXRpb24gcHJvY2VzcyBpcyBzdGlsbCB2 ZXJ5IGNvbXBsZXggaW4gYWQgaG9jIG5ldHdvcmtzLGFuZCBpZiB0aGUgcmVjZW50IGRldmVsb3Bl ZCBNQUMgcHJvdG9jb2xzIGFyZSBhbGwgYXN5bmNocm9ub3VzIG1vZGVsLg0KICANClRoYW5rcyBh IGxvdCENCndlaWJvIHl1DQo= ------=_NextPart_000_0022_01C1F99A.298F46E0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yNzEyLjMwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpIGFsbDo8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDtJJ20gbm90IHZlcnkgY2xl YXIgYWJvdXQgdGhlIHN5bmNocm9ub3VzIA0KY29tbXVuaWNhdGlvbiBtb2RlbC5JZiB0aGUgc3lu Y2hyb25pemF0aW9uIHByb2Nlc3MgaXMgc3RpbGwgdmVyeSBjb21wbGV4IGluIGFkIA0KaG9jIG5l dHdvcmtzLGFuZCBpZiB0aGUgcmVjZW50IGRldmVsb3BlZCBNQUMgcHJvdG9jb2xzIGFyZSBhbGwg YXN5bmNocm9ub3VzIA0KbW9kZWwuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5i c3A7Jm5ic3A7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmtzIGEgbG90ITwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPndlaWJvIHl1PC9GT05UPjwvRElWPjwvQk9E WT48L0hUTUw+DQo= ------=_NextPart_000_0022_01C1F99A.298F46E0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sat May 11 22:32:49 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 WAA24824 for ; Sat, 11 May 2002 22:32:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA21631 for manet-archive@odin.ietf.org; Sat, 11 May 2002 22:32:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19729; Sat, 11 May 2002 21:49:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19700 for ; Sat, 11 May 2002 21:49:01 -0400 (EDT) Received: from sina.com ([202.106.187.143]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22750 for ; Sat, 11 May 2002 21:48:49 -0400 (EDT) Received: (qmail 6966 invoked by alias); 12 May 2002 01:43:03 -0000 Received: from unknown (HELO datou) (218.2.150.99) by 202.106.187.143 with SMTP; 12 May 2002 01:43:03 -0000 Message-ID: <002501c1f957$1c797f40$0e00a8c0@datou> From: "ywbsina" To: Date: Sun, 12 May 2002 09:48:26 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C1F99A.298F46E0" 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 Subject: [manet] the synchronous communication model 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 This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C1F99A.298F46E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsOg0KICAgSSdtIG5vdCB2ZXJ5IGNsZWFyIGFib3V0IHRoZSBzeW5jaHJvbm91cyBjb21t dW5pY2F0aW9uIG1vZGVsLklmIHRoZSBzeW5jaHJvbml6YXRpb24gcHJvY2VzcyBpcyBzdGlsbCB2 ZXJ5IGNvbXBsZXggaW4gYWQgaG9jIG5ldHdvcmtzLGFuZCBpZiB0aGUgcmVjZW50IGRldmVsb3Bl ZCBNQUMgcHJvdG9jb2xzIGFyZSBhbGwgYXN5bmNocm9ub3VzIG1vZGVsLg0KICANClRoYW5rcyBh IGxvdCENCndlaWJvIHl1DQo= ------=_NextPart_000_0022_01C1F99A.298F46E0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yNzEyLjMwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpIGFsbDo8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDtJJ20gbm90IHZlcnkgY2xl YXIgYWJvdXQgdGhlIHN5bmNocm9ub3VzIA0KY29tbXVuaWNhdGlvbiBtb2RlbC5JZiB0aGUgc3lu Y2hyb25pemF0aW9uIHByb2Nlc3MgaXMgc3RpbGwgdmVyeSBjb21wbGV4IGluIGFkIA0KaG9jIG5l dHdvcmtzLGFuZCBpZiB0aGUgcmVjZW50IGRldmVsb3BlZCBNQUMgcHJvdG9jb2xzIGFyZSBhbGwg YXN5bmNocm9ub3VzIA0KbW9kZWwuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5i c3A7Jm5ic3A7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmtzIGEgbG90ITwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPndlaWJvIHl1PC9GT05UPjwvRElWPjwvQk9E WT48L0hUTUw+DQo= ------=_NextPart_000_0022_01C1F99A.298F46E0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sun May 12 14:55:58 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 OAA24969 for ; Sun, 12 May 2002 14:55:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00682; Sun, 12 May 2002 14:31:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00651 for ; Sun, 12 May 2002 14:31:23 -0400 (EDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24155 for ; Sun, 12 May 2002 14:31:10 -0400 (EDT) Received: from frink.ece.udel.edu by mail.eecis.udel.edu id aa16732; 12 May 2002 14:31 EDT Date: Sun, 12 May 2002 14:31:21 -0400 (EDT) From: Liangping Ma To: manet@ietf.org MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] How to add a new type of queue in ns? 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 Hello, everyone, I want to add a new type of queue management, like RED, to the ns. Does anyone know where I should register it in ns source files? Thanks in advance! Sincerely yours, Liangping Ma _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sun May 12 14:55:59 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 OAA24980 for ; Sun, 12 May 2002 14:55:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01362 for manet-archive@odin.ietf.org; Sun, 12 May 2002 14:56:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00682; Sun, 12 May 2002 14:31:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00651 for ; Sun, 12 May 2002 14:31:23 -0400 (EDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24155 for ; Sun, 12 May 2002 14:31:10 -0400 (EDT) Received: from frink.ece.udel.edu by mail.eecis.udel.edu id aa16732; 12 May 2002 14:31 EDT Date: Sun, 12 May 2002 14:31:21 -0400 (EDT) From: Liangping Ma To: manet@ietf.org MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] How to add a new type of queue in ns? 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 Hello, everyone, I want to add a new type of queue management, like RED, to the ns. Does anyone know where I should register it in ns source files? Thanks in advance! Sincerely yours, Liangping Ma _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon May 13 22:12:29 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 WAA15167 for ; Mon, 13 May 2002 22:12:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06530; Mon, 13 May 2002 10:49:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19974 for ; Mon, 13 May 2002 05:23:01 -0400 (EDT) Received: from kuma.upv.es (kuma.cc.upv.es [158.42.4.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01245 for ; Mon, 13 May 2002 05:22:49 -0400 (EDT) Received: from pop.upv.es (maia.cc.upv.es [158.42.4.11]) by kuma.upv.es (8.9.3/8.9.3) with ESMTP id LAA03092; Mon, 13 May 2002 11:22:51 +0200 Received: from smtp2.upv.es (smtp.cc.upv.es [158.42.250.10]) by pop.upv.es (8.11.3/8.11.3) with ESMTP id g4D9MoT13198; Mon, 13 May 2002 11:22:50 +0200 (METDST) Received: from miguelsa (msanchez.disca.upv.es [158.42.53.17]) by smtp2.upv.es (8.11.4/8.11.4) with SMTP id g4D9Mo928162; Mon, 13 May 2002 11:22:50 +0200 Message-ID: <004101c1fa5f$96b3fde0$11352a9e@miguelsa> From: "Miguel Sanchez" To: "Liangping Ma" , References: Subject: Re: [manet] How to add a new type of queue in ns? Date: Mon, 13 May 2002 11:21:39 +0200 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hi Liangping, You may write your new code files to ~/ns-allinone-2.1b9/ns-2.1b9/queue/ (I assume you are using ns-2.1b9). You can use any of the other queue policy files as a sample. Good luck, Miguel Sanchez -- Universidad Politecnica de Valencia Camino de Vera, 14 46022 VALENCIA (Spain) ----- Original Message ----- From: "Liangping Ma" To: Sent: Sunday, May 12, 2002 8:31 PM Subject: [manet] How to add a new type of queue in ns? > Hello, everyone, > I want to add a new type of queue management, like RED, to the ns. > Does anyone know where I should register it in ns source files? > Thanks in advance! > > Sincerely yours, > Ma > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon May 13 22:12:30 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 WAA15177 for ; Mon, 13 May 2002 22:12:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA12661 for manet-archive@odin.ietf.org; Mon, 13 May 2002 22:12:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06530; Mon, 13 May 2002 10:49:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19974 for ; Mon, 13 May 2002 05:23:01 -0400 (EDT) Received: from kuma.upv.es (kuma.cc.upv.es [158.42.4.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01245 for ; Mon, 13 May 2002 05:22:49 -0400 (EDT) Received: from pop.upv.es (maia.cc.upv.es [158.42.4.11]) by kuma.upv.es (8.9.3/8.9.3) with ESMTP id LAA03092; Mon, 13 May 2002 11:22:51 +0200 Received: from smtp2.upv.es (smtp.cc.upv.es [158.42.250.10]) by pop.upv.es (8.11.3/8.11.3) with ESMTP id g4D9MoT13198; Mon, 13 May 2002 11:22:50 +0200 (METDST) Received: from miguelsa (msanchez.disca.upv.es [158.42.53.17]) by smtp2.upv.es (8.11.4/8.11.4) with SMTP id g4D9Mo928162; Mon, 13 May 2002 11:22:50 +0200 Message-ID: <004101c1fa5f$96b3fde0$11352a9e@miguelsa> From: "Miguel Sanchez" To: "Liangping Ma" , References: Subject: Re: [manet] How to add a new type of queue in ns? Date: Mon, 13 May 2002 11:21:39 +0200 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hi Liangping, You may write your new code files to ~/ns-allinone-2.1b9/ns-2.1b9/queue/ (I assume you are using ns-2.1b9). You can use any of the other queue policy files as a sample. Good luck, Miguel Sanchez -- Universidad Politecnica de Valencia Camino de Vera, 14 46022 VALENCIA (Spain) ----- Original Message ----- From: "Liangping Ma" To: Sent: Sunday, May 12, 2002 8:31 PM Subject: [manet] How to add a new type of queue in ns? > Hello, everyone, > I want to add a new type of queue management, like RED, to the ns. > Does anyone know where I should register it in ns source files? > Thanks in advance! > > Sincerely yours, > Ma > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon May 13 22:26:00 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 WAA15670 for ; Mon, 13 May 2002 22:26:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06474; Mon, 13 May 2002 10:49:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19211 for ; Mon, 13 May 2002 05:03:36 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01079 for ; Mon, 13 May 2002 05:03:24 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g4D934902175 for ; Mon, 13 May 2002 11:03:04 +0200 (MET DST) Message-ID: <006501c1fa5f$fd9ac3e0$3ac033c1@inria.fr> From: "Philippe Jacquet" To: References: Subject: Re: [manet] 802.11 Date: Mon, 13 May 2002 11:24:31 +0200 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hi, all, I think the DSSS code is mainly used to fight the interference between the multipath from the same source. Fighting interference from different sources is more the job of the MAC CSMA. Philippe ----- Original Message ----- From: To: Mineo Takai Cc: Sent: Thursday, May 09, 2002 3:16 AM Subject: Re: [manet] 802.11 > Hi Mineo, > > On Wed, 8 May 2002, Mineo Takai wrote: > > The IEEE 802.11 DSSS PHY specifies a single 11-bit spreading code, which > > means that its DSSS does not help reduce interference from other 802.11 > > radios. It should help if the interference source is something else, > > like microwave ovens, hair dryers, or jammers in military scenarios. > > I am not sure that this is correct. Even if there is a *single* spreading > sequence, but the sequence is with low autocorrelation function (for all > time shifts, except at the orgin), then the spreading *does* provide some > degree of interference reduction. The key here is that the transmissions > from different nodes will not be chip-synchronized. Thus, due to the low > autocorrelation, there will be some rejection of the other transmissions. > > Best, > > Zygmunt. > ==--==-=-=== > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > Wireless Networks Laboratory http://wnl.ece.cornell.edu > School of Electrical Engineering > Cornell University tel: +1-607-255-3454 > 323 Frank Rhodes Hall fax: +1-607-255-9072 > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > U.S.A > WNL web page: http://wnl.ece.cornell.edu > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon May 13 22:26:01 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 WAA15680 for ; Mon, 13 May 2002 22:26:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA13862 for manet-archive@odin.ietf.org; Mon, 13 May 2002 22:26:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06474; Mon, 13 May 2002 10:49:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19211 for ; Mon, 13 May 2002 05:03:36 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01079 for ; Mon, 13 May 2002 05:03:24 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g4D934902175 for ; Mon, 13 May 2002 11:03:04 +0200 (MET DST) Message-ID: <006501c1fa5f$fd9ac3e0$3ac033c1@inria.fr> From: "Philippe Jacquet" To: References: Subject: Re: [manet] 802.11 Date: Mon, 13 May 2002 11:24:31 +0200 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hi, all, I think the DSSS code is mainly used to fight the interference between the multipath from the same source. Fighting interference from different sources is more the job of the MAC CSMA. Philippe ----- Original Message ----- From: To: Mineo Takai Cc: Sent: Thursday, May 09, 2002 3:16 AM Subject: Re: [manet] 802.11 > Hi Mineo, > > On Wed, 8 May 2002, Mineo Takai wrote: > > The IEEE 802.11 DSSS PHY specifies a single 11-bit spreading code, which > > means that its DSSS does not help reduce interference from other 802.11 > > radios. It should help if the interference source is something else, > > like microwave ovens, hair dryers, or jammers in military scenarios. > > I am not sure that this is correct. Even if there is a *single* spreading > sequence, but the sequence is with low autocorrelation function (for all > time shifts, except at the orgin), then the spreading *does* provide some > degree of interference reduction. The key here is that the transmissions > from different nodes will not be chip-synchronized. Thus, due to the low > autocorrelation, there will be some rejection of the other transmissions. > > Best, > > Zygmunt. > ==--==-=-=== > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > Wireless Networks Laboratory http://wnl.ece.cornell.edu > School of Electrical Engineering > Cornell University tel: +1-607-255-3454 > 323 Frank Rhodes Hall fax: +1-607-255-9072 > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > U.S.A > WNL web page: http://wnl.ece.cornell.edu > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 14 13:04:33 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 NAA26576 for ; Tue, 14 May 2002 13:04:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29338; Tue, 14 May 2002 12:33:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29305 for ; Tue, 14 May 2002 12:33:10 -0400 (EDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25475 for ; Tue, 14 May 2002 12:32:53 -0400 (EDT) Received: from frink.ece.udel.edu by mail.eecis.udel.edu id aa16460; 14 May 2002 12:32 EDT Date: Tue, 14 May 2002 12:32:41 -0400 (EDT) From: Liangping Ma To: manet@ietf.org MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Questions about INSIGNIA 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 Hello, everyone, I am implementing INSIGNIA in Glomosim and have several questions to ask. First, at what layer the MAX and MIN bandwidth requirement should be specified. Second, how many services are available in INSIGNIA? What is the difference between BQ and BE? It seems to me packets can be delivered as best effort, and reserved, which inturn includes BQ and EQ. Thanks! Sincerely yours, Liangping Ma _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue May 14 13:04:34 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 NAA26589 for ; Tue, 14 May 2002 13:04:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02248 for manet-archive@odin.ietf.org; Tue, 14 May 2002 13:04:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29338; Tue, 14 May 2002 12:33:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29305 for ; Tue, 14 May 2002 12:33:10 -0400 (EDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25475 for ; Tue, 14 May 2002 12:32:53 -0400 (EDT) Received: from frink.ece.udel.edu by mail.eecis.udel.edu id aa16460; 14 May 2002 12:32 EDT Date: Tue, 14 May 2002 12:32:41 -0400 (EDT) From: Liangping Ma To: manet@ietf.org MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Questions about INSIGNIA 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 Hello, everyone, I am implementing INSIGNIA in Glomosim and have several questions to ask. First, at what layer the MAX and MIN bandwidth requirement should be specified. Second, how many services are available in INSIGNIA? What is the difference between BQ and BE? It seems to me packets can be delivered as best effort, and reserved, which inturn includes BQ and EQ. Thanks! Sincerely yours, Liangping Ma _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 14 13:41:44 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 NAA28001 for ; Tue, 14 May 2002 13:41:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02932; Tue, 14 May 2002 13:13:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02637 for ; Tue, 14 May 2002 13:09:43 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26806 for ; Tue, 14 May 2002 13:09:30 -0400 (EDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA03454; Tue, 14 May 2002 10:09:39 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id MAA25477; Tue, 14 May 2002 12:09:38 -0500 (CDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g4EHA6h02866; Tue, 14 May 2002 10:10:06 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 May 2002 10:09:33 -0700 Message-ID: From: "Nast, Douglas P" To: "'Mullen, John P. (Contractor)'" Cc: manet@ietf.org Subject: RE: [manet] Dumb Question? Date: Tue, 14 May 2002 10:09:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 John, You sent a reply saying you understood that layer 3 routing was going on but wondered what this other process was. Thanks for the clarification. Note that in your question you say that "such a thing is not possible. Instead, each node that receives a packet decides to..." and then you give 3 possible behaviors, consume, re-broadcast, or discard. By what process do the nodes come to understand which of these behaviors is appropriate for them? Who/What is doing the teaching and to what purpose? Are the decisions you describe being made on the basis of MAC layer addresses or IP? The first thing that occurs to me is that this behavior was learned via a route discovery process, sort of like source route bridging in 802 LANs. This approach to routing in Manets was proposed a while back by David B. Johnson, and is, I think, the basis of the reactive approach to manet routing. If that's the case, then you can call it routing or you can call it switching, but it is not worthy of a new name. Based on Perkins and Ram responses, I guess I am missing something, though. Do you think your question has been resolved? If so how? Doug Nast, Boeing -----Original Message----- From: Mullen, John P. (Contractor) [mailto:mullenjp.contractor@trac.wsmr.army.mil] Sent: Monday, May 06, 2002 2:08 PM To: manet@ietf.org Subject: [manet] Dumb Question? Hello, I am looking for a term, but have had no luck. In wired nets, a packet is routed through the network from node to node, say by routing tables. However, in MANETs, in which packets are broadcast via omnidirectional antennae on a shared channel, such a thing is not possible. Instead, each node that receives a packet decides to: 1. Discard the packet, 2. "Read" the packet, since it is addressed to the node, and/or 3. Rebroadcast the packet. If the node is not to be an intermediary node in the end-to-end path between the source and the destination, or if the node is receiving a copy of a packet it had previously broadcast, it will not broadcast the packet. This is necessary to avoid overutilizing the channel. If the node is an intermediary node on the path, then it must rebroadcast the packet. I've got this much figured out, but what I do not know is what this process is called. It is the MANET equivalent to "routing," but is not really routing, since the sending node has no way of directing the packet. I've tried a number of searches and read a few glossaries, but have not been able to find this term. I'd appreciate any help. Thanks, John P. Mullen _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue May 14 13:41:50 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 NAA28018 for ; Tue, 14 May 2002 13:41:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05203 for manet-archive@odin.ietf.org; Tue, 14 May 2002 13:41:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02932; Tue, 14 May 2002 13:13:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02637 for ; Tue, 14 May 2002 13:09:43 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26806 for ; Tue, 14 May 2002 13:09:30 -0400 (EDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA03454; Tue, 14 May 2002 10:09:39 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id MAA25477; Tue, 14 May 2002 12:09:38 -0500 (CDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g4EHA6h02866; Tue, 14 May 2002 10:10:06 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 May 2002 10:09:33 -0700 Message-ID: From: "Nast, Douglas P" To: "'Mullen, John P. (Contractor)'" Cc: manet@ietf.org Subject: RE: [manet] Dumb Question? Date: Tue, 14 May 2002 10:09:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 John, You sent a reply saying you understood that layer 3 routing was going on but wondered what this other process was. Thanks for the clarification. Note that in your question you say that "such a thing is not possible. Instead, each node that receives a packet decides to..." and then you give 3 possible behaviors, consume, re-broadcast, or discard. By what process do the nodes come to understand which of these behaviors is appropriate for them? Who/What is doing the teaching and to what purpose? Are the decisions you describe being made on the basis of MAC layer addresses or IP? The first thing that occurs to me is that this behavior was learned via a route discovery process, sort of like source route bridging in 802 LANs. This approach to routing in Manets was proposed a while back by David B. Johnson, and is, I think, the basis of the reactive approach to manet routing. If that's the case, then you can call it routing or you can call it switching, but it is not worthy of a new name. Based on Perkins and Ram responses, I guess I am missing something, though. Do you think your question has been resolved? If so how? Doug Nast, Boeing -----Original Message----- From: Mullen, John P. (Contractor) [mailto:mullenjp.contractor@trac.wsmr.army.mil] Sent: Monday, May 06, 2002 2:08 PM To: manet@ietf.org Subject: [manet] Dumb Question? Hello, I am looking for a term, but have had no luck. In wired nets, a packet is routed through the network from node to node, say by routing tables. However, in MANETs, in which packets are broadcast via omnidirectional antennae on a shared channel, such a thing is not possible. Instead, each node that receives a packet decides to: 1. Discard the packet, 2. "Read" the packet, since it is addressed to the node, and/or 3. Rebroadcast the packet. If the node is not to be an intermediary node in the end-to-end path between the source and the destination, or if the node is receiving a copy of a packet it had previously broadcast, it will not broadcast the packet. This is necessary to avoid overutilizing the channel. If the node is an intermediary node on the path, then it must rebroadcast the packet. I've got this much figured out, but what I do not know is what this process is called. It is the MANET equivalent to "routing," but is not really routing, since the sending node has no way of directing the packet. I've tried a number of searches and read a few glossaries, but have not been able to find this term. I'd appreciate any help. Thanks, John P. Mullen _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 14 14:45:09 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 OAA00099 for ; Tue, 14 May 2002 14:45:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07957; Tue, 14 May 2002 14:16:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07849 for ; Tue, 14 May 2002 14:16:45 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29013 for ; Tue, 14 May 2002 14:16:31 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Tue, 14 May 2002 12:16:35 -0600 Message-Id: <02May14.121635mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Nast, Douglas P" Cc: manet@ietf.org Subject: RE: [manet] Dumb Question? Date: Tue, 14 May 2002 12:16:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 Hi Doug, My concern was that the forwarding process might be called something else in a MANET, since it functions differently from the analogous process in wired networks. However, the consensus seems to be that the same term is used. I think I've gotten my answer on that. The process would be the consequence of the chosen protocol. As I understand it, the process by which a node obtains link information is called "routing" and the process by which a node decides which of the three things to do is called either "forwarding" or "switching," depending on who you talk to. The details of the processes would be limited by operational and hardware constraints and defined in the protocols. The scheme used to assign node addresses is a key issue in military MANETs. At the upper levels, one wants a scheme that reflects the hierarchical military organization. This facilitates the proper routing of orders, partial orders, etc. However, at the lower levels, one would want an addressing scheme that reflects the actual network topology. This would allow clustering, which would make route determination and forwarding simpler. One solution is to do both, coordinating the system via the interface. However, the nodes are in constant motion, so the interface would need to update its information on the fly. Offsetting the higher efficiency of the clusterable scheme at the lower levels is a more complicated interface and more difficulty enforcing security. I don't think this issue has been resolved yet, so, of course, the protocols are also up in the air. I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser speculates on p. 33 that it is unlikely a single protocol will be able to operate efficiently over the full range of conditions under which a military MANET must operate. If he is correct, the issue may never be fully resolved. But, there is always hope, And, graduate students. :-) John Mullen -----Original Message----- From: Nast, Douglas P [mailto:douglas.p.nast@boeing.com] Sent: Tuesday, May 14, 2002 11:10 AM To: 'Mullen, John P. (Contractor)' Cc: manet@ietf.org Subject: RE: [manet] Dumb Question? John, You sent a reply saying you understood that layer 3 routing was going on but wondered what this other process was. Thanks for the clarification. Note that in your question you say that "such a thing is not possible. Instead, each node that receives a packet decides to..." and then you give 3 possible behaviors, consume, re-broadcast, or discard. By what process do the nodes come to understand which of these behaviors is appropriate for them? Who/What is doing the teaching and to what purpose? Are the decisions you describe being made on the basis of MAC layer addresses or IP? The first thing that occurs to me is that this behavior was learned via a route discovery process, sort of like source route bridging in 802 LANs. This approach to routing in Manets was proposed a while back by David B. Johnson, and is, I think, the basis of the reactive approach to manet routing. If that's the case, then you can call it routing or you can call it switching, but it is not worthy of a new name. Based on Perkins and Ram responses, I guess I am missing something, though. Do you think your question has been resolved? If so how? Doug Nast, Boeing -----Original Message----- From: Mullen, John P. (Contractor) [mailto:mullenjp.contractor@trac.wsmr.army.mil] Sent: Monday, May 06, 2002 2:08 PM To: manet@ietf.org Subject: [manet] Dumb Question? Hello, I am looking for a term, but have had no luck. In wired nets, a packet is routed through the network from node to node, say by routing tables. However, in MANETs, in which packets are broadcast via omnidirectional antennae on a shared channel, such a thing is not possible. Instead, each node that receives a packet decides to: 1. Discard the packet, 2. "Read" the packet, since it is addressed to the node, and/or 3. Rebroadcast the packet. If the node is not to be an intermediary node in the end-to-end path between the source and the destination, or if the node is receiving a copy of a packet it had previously broadcast, it will not broadcast the packet. This is necessary to avoid overutilizing the channel. If the node is an intermediary node on the path, then it must rebroadcast the packet. I've got this much figured out, but what I do not know is what this process is called. It is the MANET equivalent to "routing," but is not really routing, since the sending node has no way of directing the packet. I've tried a number of searches and read a few glossaries, but have not been able to find this term. I'd appreciate any help. Thanks, John P. Mullen _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue May 14 14:45:09 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 OAA00109 for ; Tue, 14 May 2002 14:45:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA10199 for manet-archive@odin.ietf.org; Tue, 14 May 2002 14:45:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07957; Tue, 14 May 2002 14:16:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07849 for ; Tue, 14 May 2002 14:16:45 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29013 for ; Tue, 14 May 2002 14:16:31 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Tue, 14 May 2002 12:16:35 -0600 Message-Id: <02May14.121635mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Nast, Douglas P" Cc: manet@ietf.org Subject: RE: [manet] Dumb Question? Date: Tue, 14 May 2002 12:16:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 Hi Doug, My concern was that the forwarding process might be called something else in a MANET, since it functions differently from the analogous process in wired networks. However, the consensus seems to be that the same term is used. I think I've gotten my answer on that. The process would be the consequence of the chosen protocol. As I understand it, the process by which a node obtains link information is called "routing" and the process by which a node decides which of the three things to do is called either "forwarding" or "switching," depending on who you talk to. The details of the processes would be limited by operational and hardware constraints and defined in the protocols. The scheme used to assign node addresses is a key issue in military MANETs. At the upper levels, one wants a scheme that reflects the hierarchical military organization. This facilitates the proper routing of orders, partial orders, etc. However, at the lower levels, one would want an addressing scheme that reflects the actual network topology. This would allow clustering, which would make route determination and forwarding simpler. One solution is to do both, coordinating the system via the interface. However, the nodes are in constant motion, so the interface would need to update its information on the fly. Offsetting the higher efficiency of the clusterable scheme at the lower levels is a more complicated interface and more difficulty enforcing security. I don't think this issue has been resolved yet, so, of course, the protocols are also up in the air. I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser speculates on p. 33 that it is unlikely a single protocol will be able to operate efficiently over the full range of conditions under which a military MANET must operate. If he is correct, the issue may never be fully resolved. But, there is always hope, And, graduate students. :-) John Mullen -----Original Message----- From: Nast, Douglas P [mailto:douglas.p.nast@boeing.com] Sent: Tuesday, May 14, 2002 11:10 AM To: 'Mullen, John P. (Contractor)' Cc: manet@ietf.org Subject: RE: [manet] Dumb Question? John, You sent a reply saying you understood that layer 3 routing was going on but wondered what this other process was. Thanks for the clarification. Note that in your question you say that "such a thing is not possible. Instead, each node that receives a packet decides to..." and then you give 3 possible behaviors, consume, re-broadcast, or discard. By what process do the nodes come to understand which of these behaviors is appropriate for them? Who/What is doing the teaching and to what purpose? Are the decisions you describe being made on the basis of MAC layer addresses or IP? The first thing that occurs to me is that this behavior was learned via a route discovery process, sort of like source route bridging in 802 LANs. This approach to routing in Manets was proposed a while back by David B. Johnson, and is, I think, the basis of the reactive approach to manet routing. If that's the case, then you can call it routing or you can call it switching, but it is not worthy of a new name. Based on Perkins and Ram responses, I guess I am missing something, though. Do you think your question has been resolved? If so how? Doug Nast, Boeing -----Original Message----- From: Mullen, John P. (Contractor) [mailto:mullenjp.contractor@trac.wsmr.army.mil] Sent: Monday, May 06, 2002 2:08 PM To: manet@ietf.org Subject: [manet] Dumb Question? Hello, I am looking for a term, but have had no luck. In wired nets, a packet is routed through the network from node to node, say by routing tables. However, in MANETs, in which packets are broadcast via omnidirectional antennae on a shared channel, such a thing is not possible. Instead, each node that receives a packet decides to: 1. Discard the packet, 2. "Read" the packet, since it is addressed to the node, and/or 3. Rebroadcast the packet. If the node is not to be an intermediary node in the end-to-end path between the source and the destination, or if the node is receiving a copy of a packet it had previously broadcast, it will not broadcast the packet. This is necessary to avoid overutilizing the channel. If the node is an intermediary node on the path, then it must rebroadcast the packet. I've got this much figured out, but what I do not know is what this process is called. It is the MANET equivalent to "routing," but is not really routing, since the sending node has no way of directing the packet. I've tried a number of searches and read a few glossaries, but have not been able to find this term. I'd appreciate any help. Thanks, John P. Mullen _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 14 15:22:28 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 PAA01831 for ; Tue, 14 May 2002 15:22:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10882; Tue, 14 May 2002 14:55:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10856 for ; Tue, 14 May 2002 14:55:46 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00602 for ; Tue, 14 May 2002 14:55:32 -0400 (EDT) From: haas@ece.cornell.edu Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g4EIth122025; Tue, 14 May 2002 14:55:43 -0400 Date: Tue, 14 May 2002 14:55:37 -0400 (EDT) X-Sender: haas@verdi.ee.cornell.edu To: "Mullen, John P. (Contractor)" cc: manet@ietf.org Subject: RE: [manet] Dumb Question? In-Reply-To: <02May14.121635mdt.117121@gw.trac.wsmr.army.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hi John, > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser speculates > on p. 33 that it is unlikely a single protocol will be able to operate > efficiently over the full range of conditions under which a military MANET > must operate. If he is correct, the issue may never be fully resolved. Yes, I read this book too (:-) ... I hate to bring this point over again ... and self-promote our work ... but the issue of "efficient operation over a wide range of conditions" can and should be addressed by a *hybrid* routing scheme, where the "proactive" and "reactive" behavior are "mixed" in the amounts that match these operational conditions. In other words, *adaptivity* is the key issue here. One such an example of a hybrid scheme is (of course, you have guessed) the ZRP protocol, in which the amount of proactive vs reactive behavior is *dynamically* adjusted through a single parameter - the zone radius. Now imagine this - one could use the AODV (or DSR, or your favorite reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or your favorite proactive protocol) as the proactive protocol in ZRP (I tried to offend the smallest number of people here (;-)). This is why ZRP is a framework for ... for exactly this - for "efficient operation over a wide range of conditions". So, maybe, there is a hope to resolve this issue after all. Zygmunt. ==-=-===== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue May 14 15:22:29 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 PAA01841 for ; Tue, 14 May 2002 15:22:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13445 for manet-archive@odin.ietf.org; Tue, 14 May 2002 15:22:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10882; Tue, 14 May 2002 14:55:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10856 for ; Tue, 14 May 2002 14:55:46 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00602 for ; Tue, 14 May 2002 14:55:32 -0400 (EDT) From: haas@ece.cornell.edu Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g4EIth122025; Tue, 14 May 2002 14:55:43 -0400 Date: Tue, 14 May 2002 14:55:37 -0400 (EDT) X-Sender: haas@verdi.ee.cornell.edu To: "Mullen, John P. (Contractor)" cc: manet@ietf.org Subject: RE: [manet] Dumb Question? In-Reply-To: <02May14.121635mdt.117121@gw.trac.wsmr.army.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hi John, > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser speculates > on p. 33 that it is unlikely a single protocol will be able to operate > efficiently over the full range of conditions under which a military MANET > must operate. If he is correct, the issue may never be fully resolved. Yes, I read this book too (:-) ... I hate to bring this point over again ... and self-promote our work ... but the issue of "efficient operation over a wide range of conditions" can and should be addressed by a *hybrid* routing scheme, where the "proactive" and "reactive" behavior are "mixed" in the amounts that match these operational conditions. In other words, *adaptivity* is the key issue here. One such an example of a hybrid scheme is (of course, you have guessed) the ZRP protocol, in which the amount of proactive vs reactive behavior is *dynamically* adjusted through a single parameter - the zone radius. Now imagine this - one could use the AODV (or DSR, or your favorite reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or your favorite proactive protocol) as the proactive protocol in ZRP (I tried to offend the smallest number of people here (;-)). This is why ZRP is a framework for ... for exactly this - for "efficient operation over a wide range of conditions". So, maybe, there is a hope to resolve this issue after all. Zygmunt. ==-=-===== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 14 15:47:59 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 PAA03079 for ; Tue, 14 May 2002 15:47:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12945; Tue, 14 May 2002 15:18:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12918 for ; Tue, 14 May 2002 15:18:40 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01652 for ; Tue, 14 May 2002 15:18:25 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Tue, 14 May 2002 13:18:33 -0600 Message-Id: <02May14.131833mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: haas@ece.cornell.edu Cc: manet@ietf.org Subject: RE: [manet] Dumb Question? Date: Tue, 14 May 2002 13:18:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 Hi Zygmunt, Well, I hadn't gotten that far yet, but certainly some sort of adaptive protocol would be in order. Thanks for the links. I will check it out. Of course, I should mention that one characteristic of military MANETs is that it is highly probable that someone will be trying to break your system. For this reason, military commanders are skeptical of fully automatic systems. A system that is fully automated is also fully predictable to anyone who knows the protocols and is susceptible to a focused attack. On the other hand, one that is at least partially under human control is more difficult to disable. The problem is, of course, training the human to manage that level of control, making the necessary information available to the decision maker, and instilling the discipline to make appropriate selections under the immediate threats of war. Of course, with all the hackers about, this may become a problem for all MANETs. :-) John Mullen -----Original Message----- From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] Sent: Tuesday, May 14, 2002 12:56 PM To: Mullen, John P. (Contractor) Cc: manet@ietf.org Subject: RE: [manet] Dumb Question? Hi John, > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser speculates > on p. 33 that it is unlikely a single protocol will be able to operate > efficiently over the full range of conditions under which a military MANET > must operate. If he is correct, the issue may never be fully resolved. Yes, I read this book too (:-) ... I hate to bring this point over again ... and self-promote our work ... but the issue of "efficient operation over a wide range of conditions" can and should be addressed by a *hybrid* routing scheme, where the "proactive" and "reactive" behavior are "mixed" in the amounts that match these operational conditions. In other words, *adaptivity* is the key issue here. One such an example of a hybrid scheme is (of course, you have guessed) the ZRP protocol, in which the amount of proactive vs reactive behavior is *dynamically* adjusted through a single parameter - the zone radius. Now imagine this - one could use the AODV (or DSR, or your favorite reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or your favorite proactive protocol) as the proactive protocol in ZRP (I tried to offend the smallest number of people here (;-)). This is why ZRP is a framework for ... for exactly this - for "efficient operation over a wide range of conditions". So, maybe, there is a hope to resolve this issue after all. Zygmunt. ==-=-===== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue May 14 15:47:59 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 PAA03088 for ; Tue, 14 May 2002 15:47:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15838 for manet-archive@odin.ietf.org; Tue, 14 May 2002 15:48:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12945; Tue, 14 May 2002 15:18:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12918 for ; Tue, 14 May 2002 15:18:40 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01652 for ; Tue, 14 May 2002 15:18:25 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Tue, 14 May 2002 13:18:33 -0600 Message-Id: <02May14.131833mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: haas@ece.cornell.edu Cc: manet@ietf.org Subject: RE: [manet] Dumb Question? Date: Tue, 14 May 2002 13:18:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 Hi Zygmunt, Well, I hadn't gotten that far yet, but certainly some sort of adaptive protocol would be in order. Thanks for the links. I will check it out. Of course, I should mention that one characteristic of military MANETs is that it is highly probable that someone will be trying to break your system. For this reason, military commanders are skeptical of fully automatic systems. A system that is fully automated is also fully predictable to anyone who knows the protocols and is susceptible to a focused attack. On the other hand, one that is at least partially under human control is more difficult to disable. The problem is, of course, training the human to manage that level of control, making the necessary information available to the decision maker, and instilling the discipline to make appropriate selections under the immediate threats of war. Of course, with all the hackers about, this may become a problem for all MANETs. :-) John Mullen -----Original Message----- From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] Sent: Tuesday, May 14, 2002 12:56 PM To: Mullen, John P. (Contractor) Cc: manet@ietf.org Subject: RE: [manet] Dumb Question? Hi John, > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser speculates > on p. 33 that it is unlikely a single protocol will be able to operate > efficiently over the full range of conditions under which a military MANET > must operate. If he is correct, the issue may never be fully resolved. Yes, I read this book too (:-) ... I hate to bring this point over again ... and self-promote our work ... but the issue of "efficient operation over a wide range of conditions" can and should be addressed by a *hybrid* routing scheme, where the "proactive" and "reactive" behavior are "mixed" in the amounts that match these operational conditions. In other words, *adaptivity* is the key issue here. One such an example of a hybrid scheme is (of course, you have guessed) the ZRP protocol, in which the amount of proactive vs reactive behavior is *dynamically* adjusted through a single parameter - the zone radius. Now imagine this - one could use the AODV (or DSR, or your favorite reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or your favorite proactive protocol) as the proactive protocol in ZRP (I tried to offend the smallest number of people here (;-)). This is why ZRP is a framework for ... for exactly this - for "efficient operation over a wide range of conditions". So, maybe, there is a hope to resolve this issue after all. Zygmunt. ==-=-===== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 14 16:06:05 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 QAA03999 for ; Tue, 14 May 2002 16:06:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15032; Tue, 14 May 2002 15:37:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14992 for ; Tue, 14 May 2002 15:37:24 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02522 for ; Tue, 14 May 2002 15:37:10 -0400 (EDT) From: haas@ece.cornell.edu Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g4EJbM123680; Tue, 14 May 2002 15:37:22 -0400 Date: Tue, 14 May 2002 15:37:15 -0400 (EDT) X-Sender: haas@verdi.ee.cornell.edu To: "Mullen, John P. (Contractor)" cc: manet@ietf.org Subject: RE: [manet] Dumb Question? In-Reply-To: <02May14.131833mdt.117121@gw.trac.wsmr.army.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hi John, There is a difference between an "adaptive" system and "automatically configured" system. Adaptivity is nearly a prerequisite for any system that needs to operate in different, and, more importantly, differing, conditions. This does not preclude that the configuration of the system be done manually, ... although I would suggest to leave as little to humans as possible ... only high level decisions. Humans are good at high level decisions, but terribe at detailed configurations. Zygmunt. ==--==-== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- On Tue, 14 May 2002, Mullen, John P. (Contractor) wrote: > Hi Zygmunt, > > Well, I hadn't gotten that far yet, but certainly some sort of adaptive > protocol would be in order. Thanks for the links. I will check it out. > > Of course, I should mention that one characteristic of military MANETs is > that it is highly probable that someone will be trying to break your system. > For this reason, military commanders are skeptical of fully automatic > systems. A system that is fully automated is also fully predictable to > anyone who knows the protocols and is susceptible to a focused attack. On > the other hand, one that is at least partially under human control is more > difficult to disable. The problem is, of course, training the human to > manage that level of control, making the necessary information available to > the decision maker, and instilling the discipline to make appropriate > selections under the immediate threats of war. > > Of course, with all the hackers about, this may become a problem for all > MANETs. > > :-) > > John Mullen > > -----Original Message----- > From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] > Sent: Tuesday, May 14, 2002 12:56 PM > To: Mullen, John P. (Contractor) > Cc: manet@ietf.org > Subject: RE: [manet] Dumb Question? > > > Hi John, > > > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser > speculates > > on p. 33 that it is unlikely a single protocol will be able to operate > > efficiently over the full range of conditions under which a military MANET > > must operate. If he is correct, the issue may never be fully resolved. > > Yes, I read this book too (:-) ... > > I hate to bring this point over again ... and self-promote our work ... > but the issue of "efficient operation over a wide range of conditions" can > and should be addressed by a *hybrid* routing scheme, where the "proactive" > and "reactive" behavior are "mixed" in the amounts that match these > operational conditions. In other words, *adaptivity* is the key issue > here. > > One such an example of a hybrid scheme is (of course, you have guessed) > the ZRP protocol, in which the amount of proactive vs reactive behavior is > *dynamically* adjusted through a single parameter - the zone radius. > > Now imagine this - one could use the AODV (or DSR, or your favorite > reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or > your favorite proactive protocol) as the proactive protocol in ZRP (I > tried to offend the smallest number of people here (;-)). This is why ZRP > is a framework for ... for exactly this - for "efficient operation over a > wide range of conditions". So, maybe, there is a hope to resolve this > issue after all. > > Zygmunt. > ==-=-===== > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > Wireless Networks Laboratory http://wnl.ece.cornell.edu > School of Electrical Engineering > Cornell University tel: +1-607-255-3454 > 323 Frank Rhodes Hall fax: +1-607-255-9072 > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > U.S.A > WNL web page: http://wnl.ece.cornell.edu > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue May 14 16:06:06 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 QAA04013 for ; Tue, 14 May 2002 16:06:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA18976 for manet-archive@odin.ietf.org; Tue, 14 May 2002 16:06:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15032; Tue, 14 May 2002 15:37:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14992 for ; Tue, 14 May 2002 15:37:24 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02522 for ; Tue, 14 May 2002 15:37:10 -0400 (EDT) From: haas@ece.cornell.edu Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g4EJbM123680; Tue, 14 May 2002 15:37:22 -0400 Date: Tue, 14 May 2002 15:37:15 -0400 (EDT) X-Sender: haas@verdi.ee.cornell.edu To: "Mullen, John P. (Contractor)" cc: manet@ietf.org Subject: RE: [manet] Dumb Question? In-Reply-To: <02May14.131833mdt.117121@gw.trac.wsmr.army.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hi John, There is a difference between an "adaptive" system and "automatically configured" system. Adaptivity is nearly a prerequisite for any system that needs to operate in different, and, more importantly, differing, conditions. This does not preclude that the configuration of the system be done manually, ... although I would suggest to leave as little to humans as possible ... only high level decisions. Humans are good at high level decisions, but terribe at detailed configurations. Zygmunt. ==--==-== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- On Tue, 14 May 2002, Mullen, John P. (Contractor) wrote: > Hi Zygmunt, > > Well, I hadn't gotten that far yet, but certainly some sort of adaptive > protocol would be in order. Thanks for the links. I will check it out. > > Of course, I should mention that one characteristic of military MANETs is > that it is highly probable that someone will be trying to break your system. > For this reason, military commanders are skeptical of fully automatic > systems. A system that is fully automated is also fully predictable to > anyone who knows the protocols and is susceptible to a focused attack. On > the other hand, one that is at least partially under human control is more > difficult to disable. The problem is, of course, training the human to > manage that level of control, making the necessary information available to > the decision maker, and instilling the discipline to make appropriate > selections under the immediate threats of war. > > Of course, with all the hackers about, this may become a problem for all > MANETs. > > :-) > > John Mullen > > -----Original Message----- > From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] > Sent: Tuesday, May 14, 2002 12:56 PM > To: Mullen, John P. (Contractor) > Cc: manet@ietf.org > Subject: RE: [manet] Dumb Question? > > > Hi John, > > > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser > speculates > > on p. 33 that it is unlikely a single protocol will be able to operate > > efficiently over the full range of conditions under which a military MANET > > must operate. If he is correct, the issue may never be fully resolved. > > Yes, I read this book too (:-) ... > > I hate to bring this point over again ... and self-promote our work ... > but the issue of "efficient operation over a wide range of conditions" can > and should be addressed by a *hybrid* routing scheme, where the "proactive" > and "reactive" behavior are "mixed" in the amounts that match these > operational conditions. In other words, *adaptivity* is the key issue > here. > > One such an example of a hybrid scheme is (of course, you have guessed) > the ZRP protocol, in which the amount of proactive vs reactive behavior is > *dynamically* adjusted through a single parameter - the zone radius. > > Now imagine this - one could use the AODV (or DSR, or your favorite > reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or > your favorite proactive protocol) as the proactive protocol in ZRP (I > tried to offend the smallest number of people here (;-)). This is why ZRP > is a framework for ... for exactly this - for "efficient operation over a > wide range of conditions". So, maybe, there is a hope to resolve this > issue after all. > > Zygmunt. > ==-=-===== > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > Wireless Networks Laboratory http://wnl.ece.cornell.edu > School of Electrical Engineering > Cornell University tel: +1-607-255-3454 > 323 Frank Rhodes Hall fax: +1-607-255-9072 > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > U.S.A > WNL web page: http://wnl.ece.cornell.edu > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 14 16:41:53 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 QAA05867 for ; Tue, 14 May 2002 16:41:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18385; Tue, 14 May 2002 16:02:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18360 for ; Tue, 14 May 2002 16:02:36 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03761 for ; Tue, 14 May 2002 16:02:21 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA04202; Tue, 14 May 2002 13:02:33 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id NAA18379; Tue, 14 May 2002 13:02:32 -0700 (PDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g4EK2xh26744; Tue, 14 May 2002 13:02:59 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 May 2002 13:02:18 -0700 Message-ID: From: "Nast, Douglas P" To: "'haas@ece.cornell.edu'" Cc: manet@ietf.org Subject: RE: [manet] Dumb Question? Date: Tue, 14 May 2002 13:02:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 Zygmunt, I think your idea is very interesting, as it addresses the latency issue for routes in your zone (which is important in military apps), and offers the promise of scalability: The reactive inter-zone idea is reminiscent of the hierarchical architecture of OSPF, which essentially operates LS intra-area and DV inter-area. How would you contrast your zone idea to OSPF areas? Doug Nast, Boeing -----Original Message----- From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] Sent: Tuesday, May 14, 2002 11:56 AM To: Mullen, John P. (Contractor) Cc: manet@ietf.org Subject: RE: [manet] Dumb Question? Hi John, > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser speculates > on p. 33 that it is unlikely a single protocol will be able to operate > efficiently over the full range of conditions under which a military MANET > must operate. If he is correct, the issue may never be fully resolved. Yes, I read this book too (:-) ... I hate to bring this point over again ... and self-promote our work ... but the issue of "efficient operation over a wide range of conditions" can and should be addressed by a *hybrid* routing scheme, where the "proactive" and "reactive" behavior are "mixed" in the amounts that match these operational conditions. In other words, *adaptivity* is the key issue here. One such an example of a hybrid scheme is (of course, you have guessed) the ZRP protocol, in which the amount of proactive vs reactive behavior is *dynamically* adjusted through a single parameter - the zone radius. Now imagine this - one could use the AODV (or DSR, or your favorite reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or your favorite proactive protocol) as the proactive protocol in ZRP (I tried to offend the smallest number of people here (;-)). This is why ZRP is a framework for ... for exactly this - for "efficient operation over a wide range of conditions". So, maybe, there is a hope to resolve this issue after all. Zygmunt. ==-=-===== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue May 14 16:41:54 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 QAA05881 for ; Tue, 14 May 2002 16:41:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA22648 for manet-archive@odin.ietf.org; Tue, 14 May 2002 16:42:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18385; Tue, 14 May 2002 16:02:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18360 for ; Tue, 14 May 2002 16:02:36 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03761 for ; Tue, 14 May 2002 16:02:21 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA04202; Tue, 14 May 2002 13:02:33 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id NAA18379; Tue, 14 May 2002 13:02:32 -0700 (PDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g4EK2xh26744; Tue, 14 May 2002 13:02:59 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 May 2002 13:02:18 -0700 Message-ID: From: "Nast, Douglas P" To: "'haas@ece.cornell.edu'" Cc: manet@ietf.org Subject: RE: [manet] Dumb Question? Date: Tue, 14 May 2002 13:02:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 Zygmunt, I think your idea is very interesting, as it addresses the latency issue for routes in your zone (which is important in military apps), and offers the promise of scalability: The reactive inter-zone idea is reminiscent of the hierarchical architecture of OSPF, which essentially operates LS intra-area and DV inter-area. How would you contrast your zone idea to OSPF areas? Doug Nast, Boeing -----Original Message----- From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] Sent: Tuesday, May 14, 2002 11:56 AM To: Mullen, John P. (Contractor) Cc: manet@ietf.org Subject: RE: [manet] Dumb Question? Hi John, > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser speculates > on p. 33 that it is unlikely a single protocol will be able to operate > efficiently over the full range of conditions under which a military MANET > must operate. If he is correct, the issue may never be fully resolved. Yes, I read this book too (:-) ... I hate to bring this point over again ... and self-promote our work ... but the issue of "efficient operation over a wide range of conditions" can and should be addressed by a *hybrid* routing scheme, where the "proactive" and "reactive" behavior are "mixed" in the amounts that match these operational conditions. In other words, *adaptivity* is the key issue here. One such an example of a hybrid scheme is (of course, you have guessed) the ZRP protocol, in which the amount of proactive vs reactive behavior is *dynamically* adjusted through a single parameter - the zone radius. Now imagine this - one could use the AODV (or DSR, or your favorite reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or your favorite proactive protocol) as the proactive protocol in ZRP (I tried to offend the smallest number of people here (;-)). This is why ZRP is a framework for ... for exactly this - for "efficient operation over a wide range of conditions". So, maybe, there is a hope to resolve this issue after all. Zygmunt. ==-=-===== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 08:07:34 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 IAA27988 for ; Wed, 15 May 2002 08:07:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06205; Wed, 15 May 2002 07:20:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06170 for ; Wed, 15 May 2002 07:20:09 -0400 (EDT) Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26072 for ; Wed, 15 May 2002 07:19:55 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id B41F6C69C2 for ; Wed, 15 May 2002 07:19:37 -0400 (EDT) Received: from doldham.lerc.nasa.gov (doldham.lerc.nasa.gov [139.88.102.106]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id HAA09501; Wed, 15 May 2002 07:19:34 -0400 (EDT) From: Daniel Oldham Date: Wed, 15 May 2002 11:19:38 GMT Message-ID: <20020515.11193800@doldham.lerc.nasa.gov> Subject: RE: [manet] Dumber Question? To: "Mullen, John P. (Contractor)" Cc: "Nast, Douglas P" , manet@ietf.org In-Reply-To: <02May14.121635mdt.117121@gw.trac.wsmr.army.mil> References: <02May14.121635mdt.117121@gw.trac.wsmr.army.mil> X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.2;Linux) X-Priority: 3 (Normal) 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 optimus.ietf.org id HAA06175 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 Content-Transfer-Encoding: 8bit Hello Everyone: Good point, on the Internet IP addresses are regulated and assigned to provide a hierarchical structure to allow for proper routing. For an ad-hoc network what controls the assignment of IP addresses? What happens if there are duplicate IP addresses in an ad-hoc network? How is an ad-hoc network connected to the Internet? How do packets from the Internet get an IP address in an ad-hoc network? -- Daniel R. Oldham Ph.D. Computer Engineer Satellite Networks and Architectures Branch NASA Glenn Research Center 21000 Brookpark Road (MS 54-5) Cleveland OH 44135 216.433.6307 - voice 216.433.8705 - fax oldham@grc.nasa.gov >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 5/14/02, 2:16:26 PM, "Mullen, John P. (Contractor)" wrote regarding RE: [manet] Dumb Question?: > Hi Doug, > My concern was that the forwarding process might be called something else in > a MANET, since it functions differently from the analogous process in wired > networks. However, the consensus seems to be that the same term is used. I > think I've gotten my answer on that. > The process would be the consequence of the chosen protocol. As I > understand it, the process by which a node obtains link information is > called "routing" and the process by which a node decides which of the three > things to do is called either "forwarding" or "switching," depending on who > you talk to. The details of the processes would be limited by operational > and hardware constraints and defined in the protocols. > The scheme used to assign node addresses is a key issue in military MANETs. > At the upper levels, one wants a scheme that reflects the hierarchical > military organization. This facilitates the proper routing of orders, > partial orders, etc. However, at the lower levels, one would want an > addressing scheme that reflects the actual network topology. This would > allow clustering, which would make route determination and forwarding > simpler. One solution is to do both, coordinating the system via the > interface. However, the nodes are in constant motion, so the interface > would need to update its information on the fly. Offsetting the higher > efficiency of the clusterable scheme at the lower levels is a more > complicated interface and more difficulty enforcing security. I don't think > this issue has been resolved yet, so, of course, the protocols are also up > in the air. > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser speculates > on p. 33 that it is unlikely a single protocol will be able to operate > efficiently over the full range of conditions under which a military MANET > must operate. If he is correct, the issue may never be fully resolved. > But, there is always hope, > And, graduate students. > :-) > John Mullen > -----Original Message----- > From: Nast, Douglas P [mailto:douglas.p.nast@boeing.com] > Sent: Tuesday, May 14, 2002 11:10 AM > To: 'Mullen, John P. (Contractor)' > Cc: manet@ietf.org > Subject: RE: [manet] Dumb Question? > John, > You sent a reply saying you understood that layer 3 routing was going on but > wondered what this other process was. Thanks for the clarification. > Note that in your question you say that "such a thing is not possible. > Instead, each node that receives a packet decides to..." and then you give > 3 possible behaviors, consume, re-broadcast, or discard. > By what process do the nodes come to understand which of these behaviors is > appropriate for them? Who/What is doing the teaching and to what purpose? > Are the decisions you describe being made on the basis of MAC layer > addresses or IP? > The first thing that occurs to me is that this behavior was learned via a > route discovery process, sort of like source route bridging in 802 LANs. > This approach to routing in Manets was proposed a while back by David B. > Johnson, and is, I think, the basis of the reactive approach to manet > routing. If that's the case, then you can call it routing or you can call > it switching, but it is not worthy of a new name. > Based on Perkins and Ram responses, I guess I am missing something, though. > Do you think your question has been resolved? If so how? > Doug Nast, Boeing > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Monday, May 06, 2002 2:08 PM > To: manet@ietf.org > Subject: [manet] Dumb Question? > Hello, > I am looking for a term, but have had no luck. > In wired nets, a packet is routed through the network from node to node, say > by routing tables. However, in MANETs, in which packets are broadcast via > omnidirectional antennae on a shared channel, such a thing is not possible. > Instead, each node that receives a packet decides to: > 1. Discard the packet, > 2. "Read" the packet, since it is addressed to the node, and/or > 3. Rebroadcast the packet. > If the node is not to be an intermediary node in the end-to-end path between > the source and the destination, or if the node is receiving a copy of a > packet it had previously broadcast, it will not broadcast the packet. This > is necessary to avoid overutilizing the channel. > If the node is an intermediary node on the path, then it must rebroadcast > the packet. > I've got this much figured out, but what I do not know is what this process > is called. It is the MANET equivalent to "routing," but is not really > routing, since the sending node has no way of directing the packet. > I've tried a number of searches and read a few glossaries, but have not been > able to find this term. > I'd appreciate any help. > Thanks, > John P. Mullen > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed May 15 08:07:35 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 IAA28001 for ; Wed, 15 May 2002 08:07:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA08913 for manet-archive@odin.ietf.org; Wed, 15 May 2002 08:07:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06205; Wed, 15 May 2002 07:20:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06170 for ; Wed, 15 May 2002 07:20:09 -0400 (EDT) Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26072 for ; Wed, 15 May 2002 07:19:55 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id B41F6C69C2 for ; Wed, 15 May 2002 07:19:37 -0400 (EDT) Received: from doldham.lerc.nasa.gov (doldham.lerc.nasa.gov [139.88.102.106]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id HAA09501; Wed, 15 May 2002 07:19:34 -0400 (EDT) From: Daniel Oldham Date: Wed, 15 May 2002 11:19:38 GMT Message-ID: <20020515.11193800@doldham.lerc.nasa.gov> Subject: RE: [manet] Dumber Question? To: "Mullen, John P. (Contractor)" Cc: "Nast, Douglas P" , manet@ietf.org In-Reply-To: <02May14.121635mdt.117121@gw.trac.wsmr.army.mil> References: <02May14.121635mdt.117121@gw.trac.wsmr.army.mil> X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.2;Linux) X-Priority: 3 (Normal) 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 optimus.ietf.org id HAA06175 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 Content-Transfer-Encoding: 8bit Hello Everyone: Good point, on the Internet IP addresses are regulated and assigned to provide a hierarchical structure to allow for proper routing. For an ad-hoc network what controls the assignment of IP addresses? What happens if there are duplicate IP addresses in an ad-hoc network? How is an ad-hoc network connected to the Internet? How do packets from the Internet get an IP address in an ad-hoc network? -- Daniel R. Oldham Ph.D. Computer Engineer Satellite Networks and Architectures Branch NASA Glenn Research Center 21000 Brookpark Road (MS 54-5) Cleveland OH 44135 216.433.6307 - voice 216.433.8705 - fax oldham@grc.nasa.gov >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 5/14/02, 2:16:26 PM, "Mullen, John P. (Contractor)" wrote regarding RE: [manet] Dumb Question?: > Hi Doug, > My concern was that the forwarding process might be called something else in > a MANET, since it functions differently from the analogous process in wired > networks. However, the consensus seems to be that the same term is used. I > think I've gotten my answer on that. > The process would be the consequence of the chosen protocol. As I > understand it, the process by which a node obtains link information is > called "routing" and the process by which a node decides which of the three > things to do is called either "forwarding" or "switching," depending on who > you talk to. The details of the processes would be limited by operational > and hardware constraints and defined in the protocols. > The scheme used to assign node addresses is a key issue in military MANETs. > At the upper levels, one wants a scheme that reflects the hierarchical > military organization. This facilitates the proper routing of orders, > partial orders, etc. However, at the lower levels, one would want an > addressing scheme that reflects the actual network topology. This would > allow clustering, which would make route determination and forwarding > simpler. One solution is to do both, coordinating the system via the > interface. However, the nodes are in constant motion, so the interface > would need to update its information on the fly. Offsetting the higher > efficiency of the clusterable scheme at the lower levels is a more > complicated interface and more difficulty enforcing security. I don't think > this issue has been resolved yet, so, of course, the protocols are also up > in the air. > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser speculates > on p. 33 that it is unlikely a single protocol will be able to operate > efficiently over the full range of conditions under which a military MANET > must operate. If he is correct, the issue may never be fully resolved. > But, there is always hope, > And, graduate students. > :-) > John Mullen > -----Original Message----- > From: Nast, Douglas P [mailto:douglas.p.nast@boeing.com] > Sent: Tuesday, May 14, 2002 11:10 AM > To: 'Mullen, John P. (Contractor)' > Cc: manet@ietf.org > Subject: RE: [manet] Dumb Question? > John, > You sent a reply saying you understood that layer 3 routing was going on but > wondered what this other process was. Thanks for the clarification. > Note that in your question you say that "such a thing is not possible. > Instead, each node that receives a packet decides to..." and then you give > 3 possible behaviors, consume, re-broadcast, or discard. > By what process do the nodes come to understand which of these behaviors is > appropriate for them? Who/What is doing the teaching and to what purpose? > Are the decisions you describe being made on the basis of MAC layer > addresses or IP? > The first thing that occurs to me is that this behavior was learned via a > route discovery process, sort of like source route bridging in 802 LANs. > This approach to routing in Manets was proposed a while back by David B. > Johnson, and is, I think, the basis of the reactive approach to manet > routing. If that's the case, then you can call it routing or you can call > it switching, but it is not worthy of a new name. > Based on Perkins and Ram responses, I guess I am missing something, though. > Do you think your question has been resolved? If so how? > Doug Nast, Boeing > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Monday, May 06, 2002 2:08 PM > To: manet@ietf.org > Subject: [manet] Dumb Question? > Hello, > I am looking for a term, but have had no luck. > In wired nets, a packet is routed through the network from node to node, say > by routing tables. However, in MANETs, in which packets are broadcast via > omnidirectional antennae on a shared channel, such a thing is not possible. > Instead, each node that receives a packet decides to: > 1. Discard the packet, > 2. "Read" the packet, since it is addressed to the node, and/or > 3. Rebroadcast the packet. > If the node is not to be an intermediary node in the end-to-end path between > the source and the destination, or if the node is receiving a copy of a > packet it had previously broadcast, it will not broadcast the packet. This > is necessary to avoid overutilizing the channel. > If the node is an intermediary node on the path, then it must rebroadcast > the packet. > I've got this much figured out, but what I do not know is what this process > is called. It is the MANET equivalent to "routing," but is not really > routing, since the sending node has no way of directing the packet. > I've tried a number of searches and read a few glossaries, but have not been > able to find this term. > I'd appreciate any help. > Thanks, > John P. Mullen > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 09:40:36 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 JAA04007 for ; Wed, 15 May 2002 09:40:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16251; Wed, 15 May 2002 09:12:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16218 for ; Wed, 15 May 2002 09:12:15 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02127 for ; Wed, 15 May 2002 09:12:00 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117126>; Wed, 15 May 2002 07:12:02 -0600 Message-Id: <02May15.071202mdt.117126@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Daniel Oldham Cc: manet@ietf.org Subject: RE: [manet] Dumber Question? Date: Wed, 15 May 2002 07:11:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 Hi Daniel, I cannot answer your question in general, but in the military, the method of IP address assignment is specified. Field Manual 11-71 is an unrestricted document that explains the general ideas used in Army tactical systems. Since each military unit has a unique designator, it is unlikely that there would be duplicate IP addresses when assigned by functional unit. Appendix A of FM 11-71 explains how the Army system is connected to all external systems. The traffic on Army tactical systems is classified. There is an interface to SIPRNET (which is rated for information up to secret), but access to and from the Global Internet is blocked. In general, packets formulated for wireless links are not efficient for wired links and vice versa. Data and bit error rates differ by one or more orders of magnitude. Interconnections to external systems are by means of special gateway nodes that recode and reformat data to be compatible with the target system. John Mullen -----Original Message----- From: Daniel Oldham [mailto:oldham@grc.nasa.gov] Sent: Wednesday, May 15, 2002 5:20 AM To: Mullen, John P. (Contractor) Cc: Nast, Douglas P; manet@ietf.org Subject: RE: [manet] Dumber Question? Hello Everyone: Good point, on the Internet IP addresses are regulated and assigned to provide a hierarchical structure to allow for proper routing. For an ad-hoc network what controls the assignment of IP addresses? What happens if there are duplicate IP addresses in an ad-hoc network? How is an ad-hoc network connected to the Internet? How do packets from the Internet get an IP address in an ad-hoc network? -- Daniel R. Oldham Ph.D. Computer Engineer Satellite Networks and Architectures Branch NASA Glenn Research Center 21000 Brookpark Road (MS 54-5) Cleveland OH 44135 216.433.6307 - voice 216.433.8705 - fax oldham@grc.nasa.gov >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 5/14/02, 2:16:26 PM, "Mullen, John P. (Contractor)" wrote regarding RE: [manet] Dumb Question?: > Hi Doug, > My concern was that the forwarding process might be called something else in > a MANET, since it functions differently from the analogous process in wired > networks. However, the consensus seems to be that the same term is used. I > think I've gotten my answer on that. > The process would be the consequence of the chosen protocol. As I > understand it, the process by which a node obtains link information is > called "routing" and the process by which a node decides which of the three > things to do is called either "forwarding" or "switching," depending on who > you talk to. The details of the processes would be limited by operational > and hardware constraints and defined in the protocols. > The scheme used to assign node addresses is a key issue in military MANETs. > At the upper levels, one wants a scheme that reflects the hierarchical > military organization. This facilitates the proper routing of orders, > partial orders, etc. However, at the lower levels, one would want an > addressing scheme that reflects the actual network topology. This would > allow clustering, which would make route determination and forwarding > simpler. One solution is to do both, coordinating the system via the > interface. However, the nodes are in constant motion, so the interface > would need to update its information on the fly. Offsetting the higher > efficiency of the clusterable scheme at the lower levels is a more > complicated interface and more difficulty enforcing security. I don't think > this issue has been resolved yet, so, of course, the protocols are also up > in the air. > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser speculates > on p. 33 that it is unlikely a single protocol will be able to operate > efficiently over the full range of conditions under which a military MANET > must operate. If he is correct, the issue may never be fully resolved. > But, there is always hope, > And, graduate students. > :-) > John Mullen > -----Original Message----- > From: Nast, Douglas P [mailto:douglas.p.nast@boeing.com] > Sent: Tuesday, May 14, 2002 11:10 AM > To: 'Mullen, John P. (Contractor)' > Cc: manet@ietf.org > Subject: RE: [manet] Dumb Question? > John, > You sent a reply saying you understood that layer 3 routing was going on but > wondered what this other process was. Thanks for the clarification. > Note that in your question you say that "such a thing is not possible. > Instead, each node that receives a packet decides to..." and then you give > 3 possible behaviors, consume, re-broadcast, or discard. > By what process do the nodes come to understand which of these behaviors is > appropriate for them? Who/What is doing the teaching and to what purpose? > Are the decisions you describe being made on the basis of MAC layer > addresses or IP? > The first thing that occurs to me is that this behavior was learned via a > route discovery process, sort of like source route bridging in 802 LANs. > This approach to routing in Manets was proposed a while back by David B. > Johnson, and is, I think, the basis of the reactive approach to manet > routing. If that's the case, then you can call it routing or you can call > it switching, but it is not worthy of a new name. > Based on Perkins and Ram responses, I guess I am missing something, though. > Do you think your question has been resolved? If so how? > Doug Nast, Boeing > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Monday, May 06, 2002 2:08 PM > To: manet@ietf.org > Subject: [manet] Dumb Question? > Hello, > I am looking for a term, but have had no luck. > In wired nets, a packet is routed through the network from node to node, say > by routing tables. However, in MANETs, in which packets are broadcast via > omnidirectional antennae on a shared channel, such a thing is not possible. > Instead, each node that receives a packet decides to: > 1. Discard the packet, > 2. "Read" the packet, since it is addressed to the node, and/or > 3. Rebroadcast the packet. > If the node is not to be an intermediary node in the end-to-end path between > the source and the destination, or if the node is receiving a copy of a > packet it had previously broadcast, it will not broadcast the packet. This > is necessary to avoid overutilizing the channel. > If the node is an intermediary node on the path, then it must rebroadcast > the packet. > I've got this much figured out, but what I do not know is what this process > is called. It is the MANET equivalent to "routing," but is not really > routing, since the sending node has no way of directing the packet. > I've tried a number of searches and read a few glossaries, but have not been > able to find this term. > I'd appreciate any help. > Thanks, > John P. Mullen > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 15 09:40:41 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 JAA04016 for ; Wed, 15 May 2002 09:40:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA20245 for manet-archive@odin.ietf.org; Wed, 15 May 2002 09:40:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16251; Wed, 15 May 2002 09:12:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16218 for ; Wed, 15 May 2002 09:12:15 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02127 for ; Wed, 15 May 2002 09:12:00 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117126>; Wed, 15 May 2002 07:12:02 -0600 Message-Id: <02May15.071202mdt.117126@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Daniel Oldham Cc: manet@ietf.org Subject: RE: [manet] Dumber Question? Date: Wed, 15 May 2002 07:11:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 Hi Daniel, I cannot answer your question in general, but in the military, the method of IP address assignment is specified. Field Manual 11-71 is an unrestricted document that explains the general ideas used in Army tactical systems. Since each military unit has a unique designator, it is unlikely that there would be duplicate IP addresses when assigned by functional unit. Appendix A of FM 11-71 explains how the Army system is connected to all external systems. The traffic on Army tactical systems is classified. There is an interface to SIPRNET (which is rated for information up to secret), but access to and from the Global Internet is blocked. In general, packets formulated for wireless links are not efficient for wired links and vice versa. Data and bit error rates differ by one or more orders of magnitude. Interconnections to external systems are by means of special gateway nodes that recode and reformat data to be compatible with the target system. John Mullen -----Original Message----- From: Daniel Oldham [mailto:oldham@grc.nasa.gov] Sent: Wednesday, May 15, 2002 5:20 AM To: Mullen, John P. (Contractor) Cc: Nast, Douglas P; manet@ietf.org Subject: RE: [manet] Dumber Question? Hello Everyone: Good point, on the Internet IP addresses are regulated and assigned to provide a hierarchical structure to allow for proper routing. For an ad-hoc network what controls the assignment of IP addresses? What happens if there are duplicate IP addresses in an ad-hoc network? How is an ad-hoc network connected to the Internet? How do packets from the Internet get an IP address in an ad-hoc network? -- Daniel R. Oldham Ph.D. Computer Engineer Satellite Networks and Architectures Branch NASA Glenn Research Center 21000 Brookpark Road (MS 54-5) Cleveland OH 44135 216.433.6307 - voice 216.433.8705 - fax oldham@grc.nasa.gov >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 5/14/02, 2:16:26 PM, "Mullen, John P. (Contractor)" wrote regarding RE: [manet] Dumb Question?: > Hi Doug, > My concern was that the forwarding process might be called something else in > a MANET, since it functions differently from the analogous process in wired > networks. However, the consensus seems to be that the same term is used. I > think I've gotten my answer on that. > The process would be the consequence of the chosen protocol. As I > understand it, the process by which a node obtains link information is > called "routing" and the process by which a node decides which of the three > things to do is called either "forwarding" or "switching," depending on who > you talk to. The details of the processes would be limited by operational > and hardware constraints and defined in the protocols. > The scheme used to assign node addresses is a key issue in military MANETs. > At the upper levels, one wants a scheme that reflects the hierarchical > military organization. This facilitates the proper routing of orders, > partial orders, etc. However, at the lower levels, one would want an > addressing scheme that reflects the actual network topology. This would > allow clustering, which would make route determination and forwarding > simpler. One solution is to do both, coordinating the system via the > interface. However, the nodes are in constant motion, so the interface > would need to update its information on the fly. Offsetting the higher > efficiency of the clusterable scheme at the lower levels is a more > complicated interface and more difficulty enforcing security. I don't think > this issue has been resolved yet, so, of course, the protocols are also up > in the air. > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser speculates > on p. 33 that it is unlikely a single protocol will be able to operate > efficiently over the full range of conditions under which a military MANET > must operate. If he is correct, the issue may never be fully resolved. > But, there is always hope, > And, graduate students. > :-) > John Mullen > -----Original Message----- > From: Nast, Douglas P [mailto:douglas.p.nast@boeing.com] > Sent: Tuesday, May 14, 2002 11:10 AM > To: 'Mullen, John P. (Contractor)' > Cc: manet@ietf.org > Subject: RE: [manet] Dumb Question? > John, > You sent a reply saying you understood that layer 3 routing was going on but > wondered what this other process was. Thanks for the clarification. > Note that in your question you say that "such a thing is not possible. > Instead, each node that receives a packet decides to..." and then you give > 3 possible behaviors, consume, re-broadcast, or discard. > By what process do the nodes come to understand which of these behaviors is > appropriate for them? Who/What is doing the teaching and to what purpose? > Are the decisions you describe being made on the basis of MAC layer > addresses or IP? > The first thing that occurs to me is that this behavior was learned via a > route discovery process, sort of like source route bridging in 802 LANs. > This approach to routing in Manets was proposed a while back by David B. > Johnson, and is, I think, the basis of the reactive approach to manet > routing. If that's the case, then you can call it routing or you can call > it switching, but it is not worthy of a new name. > Based on Perkins and Ram responses, I guess I am missing something, though. > Do you think your question has been resolved? If so how? > Doug Nast, Boeing > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Monday, May 06, 2002 2:08 PM > To: manet@ietf.org > Subject: [manet] Dumb Question? > Hello, > I am looking for a term, but have had no luck. > In wired nets, a packet is routed through the network from node to node, say > by routing tables. However, in MANETs, in which packets are broadcast via > omnidirectional antennae on a shared channel, such a thing is not possible. > Instead, each node that receives a packet decides to: > 1. Discard the packet, > 2. "Read" the packet, since it is addressed to the node, and/or > 3. Rebroadcast the packet. > If the node is not to be an intermediary node in the end-to-end path between > the source and the destination, or if the node is receiving a copy of a > packet it had previously broadcast, it will not broadcast the packet. This > is necessary to avoid overutilizing the channel. > If the node is an intermediary node on the path, then it must rebroadcast > the packet. > I've got this much figured out, but what I do not know is what this process > is called. It is the MANET equivalent to "routing," but is not really > routing, since the sending node has no way of directing the packet. > I've tried a number of searches and read a few glossaries, but have not been > able to find this term. > I'd appreciate any help. > Thanks, > John P. Mullen > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 09:42:35 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 JAA04171 for ; Wed, 15 May 2002 09:42:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17287; Wed, 15 May 2002 09:18:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17144 for ; Wed, 15 May 2002 09:18:04 -0400 (EDT) Received: from imc21.ex.nus.edu.sg (imc21.ex.nus.edu.sg [137.132.14.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02542; Wed, 15 May 2002 09:17:47 -0400 (EDT) Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 21:18:00 +0800 Message-ID: <6330DC96389A924A804F52FA3848930E703C57@MBXSRV26.stu.nus.edu.sg> From: Marwaha Shivanajay To: "'manet@ietf.org'" , "'oldham@grc.nasa.gov'" , rpsec@ietf.org Subject: RE: [manet] Dumber Question? Date: Wed, 15 May 2002 21:17:54 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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 Hi, Assignment of IP adresses is done using "autoconfiguration" in ad hoc networks. The draft that deals with this can be found here http://www.cs.ucsb.edu/~eroyer/txt/autoconf.txt To summarize it in short: If a mobile node wants to have an IP address it broadcasting a RREQ kind of message destined to that IP address. If there exists a mobile device with the same address it gets a RREP back from it and reinitiates the process by choosing a new IP address, otherwise (if it aint get any RREP) it assumes that IP address. The IP address seeking node keeps a temporary address for receiving RREP back to it. It does deal with avoiding duplicacy of IP addresses in one disconnected set of mobiles. But there isn't any central mechanism to allot the same. Nor does it guarentee uniqueness in disconnected networks. Regards, Shivanajay Marwaha -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ Research Scholar Electrical and Computer Engg. Dept. National University of Singapore. 10 Kent Ridge Crescent, Singapore 119260. Ph. +65-68742136 -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ -----Original Message----- From: Daniel Oldham [mailto:oldham@grc.nasa.gov] Sent: Wednesday, May 15, 2002 7:20 PM To: Mullen, John P. (Contractor) Cc: Nast, Douglas P; manet@ietf.org Subject: RE: [manet] Dumber Question? Hello Everyone: Good point, on the Internet IP addresses are regulated and assigned to provide a hierarchical structure to allow for proper routing. For an ad-hoc network what controls the assignment of IP addresses? What happens if there are duplicate IP addresses in an ad-hoc network? How is an ad-hoc network connected to the Internet? How do packets from the Internet get an IP address in an ad-hoc network? -- Daniel R. Oldham Ph.D. Computer Engineer Satellite Networks and Architectures Branch NASA Glenn Research Center 21000 Brookpark Road (MS 54-5) Cleveland OH 44135 216.433.6307 - voice 216.433.8705 - fax oldham@grc.nasa.gov >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 5/14/02, 2:16:26 PM, "Mullen, John P. (Contractor)" wrote regarding RE: [manet] Dumb Question?: > Hi Doug, > My concern was that the forwarding process might be called something > else in > a MANET, since it functions differently from the analogous process in wired > networks. However, the consensus seems to be that the same term is > used. I > think I've gotten my answer on that. > The process would be the consequence of the chosen protocol. As I > understand it, the process by which a node obtains link information is > called "routing" and the process by which a node decides which of the three > things to do is called either "forwarding" or "switching," depending > on who > you talk to. The details of the processes would be limited by operational > and hardware constraints and defined in the protocols. > The scheme used to assign node addresses is a key issue in military MANETs. > At the upper levels, one wants a scheme that reflects the hierarchical > military organization. This facilitates the proper routing of orders, > partial orders, etc. However, at the lower levels, one would want an > addressing scheme that reflects the actual network topology. This > would allow clustering, which would make route determination and > forwarding simpler. One solution is to do both, coordinating the > system via the interface. However, the nodes are in constant motion, > so the interface would need to update its information on the fly. > Offsetting the higher efficiency of the clusterable scheme at the > lower levels is a more complicated interface and more difficulty > enforcing security. I don't think > this issue has been resolved yet, so, of course, the protocols are > also up > in the air. > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser speculates > on p. 33 that it is unlikely a single protocol will be able to operate > efficiently over the full range of conditions under which a military MANET > must operate. If he is correct, the issue may never be fully > resolved. > But, there is always hope, > And, graduate students. > :-) > John Mullen > -----Original Message----- > From: Nast, Douglas P [mailto:douglas.p.nast@boeing.com] > Sent: Tuesday, May 14, 2002 11:10 AM > To: 'Mullen, John P. (Contractor)' > Cc: manet@ietf.org > Subject: RE: [manet] Dumb Question? > John, > You sent a reply saying you understood that layer 3 routing was going > on but > wondered what this other process was. Thanks for the clarification. > Note that in your question you say that "such a thing is not possible. > Instead, each node that receives a packet decides to..." and then you give > 3 possible behaviors, consume, re-broadcast, or discard. > By what process do the nodes come to understand which of these > behaviors is > appropriate for them? Who/What is doing the teaching and to what > purpose? Are the decisions you describe being made on the basis of MAC > layer addresses or IP? > The first thing that occurs to me is that this behavior was learned > via a route discovery process, sort of like source route bridging in > 802 LANs. This approach to routing in Manets was proposed a while back > by David B. Johnson, and is, I think, the basis of the reactive > approach to manet routing. If that's the case, then you can call it > routing or you can call > it switching, but it is not worthy of a new name. > Based on Perkins and Ram responses, I guess I am missing something, though. > Do you think your question has been resolved? If so how? > Doug Nast, Boeing > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Monday, May 06, 2002 2:08 PM > To: manet@ietf.org > Subject: [manet] Dumb Question? > Hello, > I am looking for a term, but have had no luck. > In wired nets, a packet is routed through the network from node to > node, say > by routing tables. However, in MANETs, in which packets are broadcast via > omnidirectional antennae on a shared channel, such a thing is not possible. > Instead, each node that receives a packet decides to: > 1. Discard the packet, > 2. "Read" the packet, since it is addressed to the node, and/or > 3. Rebroadcast the packet. > If the node is not to be an intermediary node in the end-to-end path between > the source and the destination, or if the node is receiving a copy of > a packet it had previously broadcast, it will not broadcast the packet. This > is necessary to avoid overutilizing the channel. > If the node is an intermediary node on the path, then it must > rebroadcast the packet. > I've got this much figured out, but what I do not know is what this process > is called. It is the MANET equivalent to "routing," but is not really > routing, since the sending node has no way of directing the packet. > I've tried a number of searches and read a few glossaries, but have > not been > able to find this term. > I'd appreciate any help. > Thanks, > John P. Mullen > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 15 09:42:36 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 JAA04181 for ; Wed, 15 May 2002 09:42:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA20539 for manet-archive@odin.ietf.org; Wed, 15 May 2002 09:42:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17287; Wed, 15 May 2002 09:18:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17144 for ; Wed, 15 May 2002 09:18:04 -0400 (EDT) Received: from imc21.ex.nus.edu.sg (imc21.ex.nus.edu.sg [137.132.14.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02542; Wed, 15 May 2002 09:17:47 -0400 (EDT) Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 21:18:00 +0800 Message-ID: <6330DC96389A924A804F52FA3848930E703C57@MBXSRV26.stu.nus.edu.sg> From: Marwaha Shivanajay To: "'manet@ietf.org'" , "'oldham@grc.nasa.gov'" , rpsec@ietf.org Subject: RE: [manet] Dumber Question? Date: Wed, 15 May 2002 21:17:54 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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 Hi, Assignment of IP adresses is done using "autoconfiguration" in ad hoc networks. The draft that deals with this can be found here http://www.cs.ucsb.edu/~eroyer/txt/autoconf.txt To summarize it in short: If a mobile node wants to have an IP address it broadcasting a RREQ kind of message destined to that IP address. If there exists a mobile device with the same address it gets a RREP back from it and reinitiates the process by choosing a new IP address, otherwise (if it aint get any RREP) it assumes that IP address. The IP address seeking node keeps a temporary address for receiving RREP back to it. It does deal with avoiding duplicacy of IP addresses in one disconnected set of mobiles. But there isn't any central mechanism to allot the same. Nor does it guarentee uniqueness in disconnected networks. Regards, Shivanajay Marwaha -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ Research Scholar Electrical and Computer Engg. Dept. National University of Singapore. 10 Kent Ridge Crescent, Singapore 119260. Ph. +65-68742136 -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ -----Original Message----- From: Daniel Oldham [mailto:oldham@grc.nasa.gov] Sent: Wednesday, May 15, 2002 7:20 PM To: Mullen, John P. (Contractor) Cc: Nast, Douglas P; manet@ietf.org Subject: RE: [manet] Dumber Question? Hello Everyone: Good point, on the Internet IP addresses are regulated and assigned to provide a hierarchical structure to allow for proper routing. For an ad-hoc network what controls the assignment of IP addresses? What happens if there are duplicate IP addresses in an ad-hoc network? How is an ad-hoc network connected to the Internet? How do packets from the Internet get an IP address in an ad-hoc network? -- Daniel R. Oldham Ph.D. Computer Engineer Satellite Networks and Architectures Branch NASA Glenn Research Center 21000 Brookpark Road (MS 54-5) Cleveland OH 44135 216.433.6307 - voice 216.433.8705 - fax oldham@grc.nasa.gov >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 5/14/02, 2:16:26 PM, "Mullen, John P. (Contractor)" wrote regarding RE: [manet] Dumb Question?: > Hi Doug, > My concern was that the forwarding process might be called something > else in > a MANET, since it functions differently from the analogous process in wired > networks. However, the consensus seems to be that the same term is > used. I > think I've gotten my answer on that. > The process would be the consequence of the chosen protocol. As I > understand it, the process by which a node obtains link information is > called "routing" and the process by which a node decides which of the three > things to do is called either "forwarding" or "switching," depending > on who > you talk to. The details of the processes would be limited by operational > and hardware constraints and defined in the protocols. > The scheme used to assign node addresses is a key issue in military MANETs. > At the upper levels, one wants a scheme that reflects the hierarchical > military organization. This facilitates the proper routing of orders, > partial orders, etc. However, at the lower levels, one would want an > addressing scheme that reflects the actual network topology. This > would allow clustering, which would make route determination and > forwarding simpler. One solution is to do both, coordinating the > system via the interface. However, the nodes are in constant motion, > so the interface would need to update its information on the fly. > Offsetting the higher efficiency of the clusterable scheme at the > lower levels is a more complicated interface and more difficulty > enforcing security. I don't think > this issue has been resolved yet, so, of course, the protocols are > also up > in the air. > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser speculates > on p. 33 that it is unlikely a single protocol will be able to operate > efficiently over the full range of conditions under which a military MANET > must operate. If he is correct, the issue may never be fully > resolved. > But, there is always hope, > And, graduate students. > :-) > John Mullen > -----Original Message----- > From: Nast, Douglas P [mailto:douglas.p.nast@boeing.com] > Sent: Tuesday, May 14, 2002 11:10 AM > To: 'Mullen, John P. (Contractor)' > Cc: manet@ietf.org > Subject: RE: [manet] Dumb Question? > John, > You sent a reply saying you understood that layer 3 routing was going > on but > wondered what this other process was. Thanks for the clarification. > Note that in your question you say that "such a thing is not possible. > Instead, each node that receives a packet decides to..." and then you give > 3 possible behaviors, consume, re-broadcast, or discard. > By what process do the nodes come to understand which of these > behaviors is > appropriate for them? Who/What is doing the teaching and to what > purpose? Are the decisions you describe being made on the basis of MAC > layer addresses or IP? > The first thing that occurs to me is that this behavior was learned > via a route discovery process, sort of like source route bridging in > 802 LANs. This approach to routing in Manets was proposed a while back > by David B. Johnson, and is, I think, the basis of the reactive > approach to manet routing. If that's the case, then you can call it > routing or you can call > it switching, but it is not worthy of a new name. > Based on Perkins and Ram responses, I guess I am missing something, though. > Do you think your question has been resolved? If so how? > Doug Nast, Boeing > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Monday, May 06, 2002 2:08 PM > To: manet@ietf.org > Subject: [manet] Dumb Question? > Hello, > I am looking for a term, but have had no luck. > In wired nets, a packet is routed through the network from node to > node, say > by routing tables. However, in MANETs, in which packets are broadcast via > omnidirectional antennae on a shared channel, such a thing is not possible. > Instead, each node that receives a packet decides to: > 1. Discard the packet, > 2. "Read" the packet, since it is addressed to the node, and/or > 3. Rebroadcast the packet. > If the node is not to be an intermediary node in the end-to-end path between > the source and the destination, or if the node is receiving a copy of > a packet it had previously broadcast, it will not broadcast the packet. This > is necessary to avoid overutilizing the channel. > If the node is an intermediary node on the path, then it must > rebroadcast the packet. > I've got this much figured out, but what I do not know is what this process > is called. It is the MANET equivalent to "routing," but is not really > routing, since the sending node has no way of directing the packet. > I've tried a number of searches and read a few glossaries, but have > not been > able to find this term. > I'd appreciate any help. > Thanks, > John P. Mullen > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 10:51:36 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 KAA08570 for ; Wed, 15 May 2002 10:51:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24643; Wed, 15 May 2002 10:26:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24617 for ; Wed, 15 May 2002 10:26:56 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06862 for ; Wed, 15 May 2002 10:26:41 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA24339; Wed, 15 May 2002 07:26:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4FEQMG04468; Wed, 15 May 2002 07:26:22 -0700 X-mProtect: <200205151426> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.194.82, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdz6ueBz; Wed, 15 May 2002 07:26:19 PDT Message-ID: <3CE26FFC.D79D0B54@iprg.nokia.com> Date: Wed, 15 May 2002 07:26:04 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Nast, Douglas P" CC: "'haas@ece.cornell.edu'" , manet@ietf.org Subject: Re: [manet] Dumb Question? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hello Douglas, We have results for scaling AODV up to 10,000 nodes. We know that we can do better by improving the packet delivery ratio. In a few weeks, I reckon we'll have some specific directions for algorithm improvement. ZDP is theoretically able to do better, simply because it admits as special cases all on-demand protocols. However, I have never seen any results showing ZDP on a network of 10,000 nodes (simulated). Regards, Charlie P. "Nast, Douglas P" wrote: > Zygmunt, > > I think your idea is very interesting, as it addresses the latency issue for > routes in your zone (which is important in military apps), and offers the > promise of scalability: The reactive inter-zone idea is reminiscent of the > hierarchical architecture of OSPF, which essentially operates LS intra-area > and DV inter-area. How would you contrast your zone idea to OSPF areas? > > Doug Nast, Boeing > > -----Original Message----- > From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] > Sent: Tuesday, May 14, 2002 11:56 AM > To: Mullen, John P. (Contractor) > Cc: manet@ietf.org > Subject: RE: [manet] Dumb Question? > > Hi John, > > > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser > speculates > > on p. 33 that it is unlikely a single protocol will be able to operate > > efficiently over the full range of conditions under which a military MANET > > must operate. If he is correct, the issue may never be fully resolved. > > Yes, I read this book too (:-) ... > > I hate to bring this point over again ... and self-promote our work ... > but the issue of "efficient operation over a wide range of conditions" can > and should be addressed by a *hybrid* routing scheme, where the "proactive" > and "reactive" behavior are "mixed" in the amounts that match these > operational conditions. In other words, *adaptivity* is the key issue > here. > > One such an example of a hybrid scheme is (of course, you have guessed) > the ZRP protocol, in which the amount of proactive vs reactive behavior is > *dynamically* adjusted through a single parameter - the zone radius. > > Now imagine this - one could use the AODV (or DSR, or your favorite > reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or > your favorite proactive protocol) as the proactive protocol in ZRP (I > tried to offend the smallest number of people here (;-)). This is why ZRP > is a framework for ... for exactly this - for "efficient operation over a > wide range of conditions". So, maybe, there is a hope to resolve this > issue after all. > > Zygmunt. > ==-=-===== > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > Wireless Networks Laboratory http://wnl.ece.cornell.edu > School of Electrical Engineering > Cornell University tel: +1-607-255-3454 > 323 Frank Rhodes Hall fax: +1-607-255-9072 > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > U.S.A > WNL web page: http://wnl.ece.cornell.edu > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 15 10:51:36 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 KAA08578 for ; Wed, 15 May 2002 10:51:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28969 for manet-archive@odin.ietf.org; Wed, 15 May 2002 10:51:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24643; Wed, 15 May 2002 10:26:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24617 for ; Wed, 15 May 2002 10:26:56 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06862 for ; Wed, 15 May 2002 10:26:41 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA24339; Wed, 15 May 2002 07:26:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4FEQMG04468; Wed, 15 May 2002 07:26:22 -0700 X-mProtect: <200205151426> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.194.82, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdz6ueBz; Wed, 15 May 2002 07:26:19 PDT Message-ID: <3CE26FFC.D79D0B54@iprg.nokia.com> Date: Wed, 15 May 2002 07:26:04 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Nast, Douglas P" CC: "'haas@ece.cornell.edu'" , manet@ietf.org Subject: Re: [manet] Dumb Question? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hello Douglas, We have results for scaling AODV up to 10,000 nodes. We know that we can do better by improving the packet delivery ratio. In a few weeks, I reckon we'll have some specific directions for algorithm improvement. ZDP is theoretically able to do better, simply because it admits as special cases all on-demand protocols. However, I have never seen any results showing ZDP on a network of 10,000 nodes (simulated). Regards, Charlie P. "Nast, Douglas P" wrote: > Zygmunt, > > I think your idea is very interesting, as it addresses the latency issue for > routes in your zone (which is important in military apps), and offers the > promise of scalability: The reactive inter-zone idea is reminiscent of the > hierarchical architecture of OSPF, which essentially operates LS intra-area > and DV inter-area. How would you contrast your zone idea to OSPF areas? > > Doug Nast, Boeing > > -----Original Message----- > From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] > Sent: Tuesday, May 14, 2002 11:56 AM > To: Mullen, John P. (Contractor) > Cc: manet@ietf.org > Subject: RE: [manet] Dumb Question? > > Hi John, > > > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser > speculates > > on p. 33 that it is unlikely a single protocol will be able to operate > > efficiently over the full range of conditions under which a military MANET > > must operate. If he is correct, the issue may never be fully resolved. > > Yes, I read this book too (:-) ... > > I hate to bring this point over again ... and self-promote our work ... > but the issue of "efficient operation over a wide range of conditions" can > and should be addressed by a *hybrid* routing scheme, where the "proactive" > and "reactive" behavior are "mixed" in the amounts that match these > operational conditions. In other words, *adaptivity* is the key issue > here. > > One such an example of a hybrid scheme is (of course, you have guessed) > the ZRP protocol, in which the amount of proactive vs reactive behavior is > *dynamically* adjusted through a single parameter - the zone radius. > > Now imagine this - one could use the AODV (or DSR, or your favorite > reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or > your favorite proactive protocol) as the proactive protocol in ZRP (I > tried to offend the smallest number of people here (;-)). This is why ZRP > is a framework for ... for exactly this - for "efficient operation over a > wide range of conditions". So, maybe, there is a hope to resolve this > issue after all. > > Zygmunt. > ==-=-===== > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > Wireless Networks Laboratory http://wnl.ece.cornell.edu > School of Electrical Engineering > Cornell University tel: +1-607-255-3454 > 323 Frank Rhodes Hall fax: +1-607-255-9072 > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > U.S.A > WNL web page: http://wnl.ece.cornell.edu > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 10:56:33 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 KAA08779 for ; Wed, 15 May 2002 10:56:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25914; Wed, 15 May 2002 10:33:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25884 for ; Wed, 15 May 2002 10:33:48 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07251 for ; Wed, 15 May 2002 10:33:32 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA24511; Wed, 15 May 2002 07:33:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4FEWvI11188; Wed, 15 May 2002 07:32:57 -0700 X-mProtect: <200205151432> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.194.82, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9ruzuL; Wed, 15 May 2002 07:32:53 PDT Message-ID: <3CE27186.8AA51649@iprg.nokia.com> Date: Wed, 15 May 2002 07:32:38 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Oldham CC: "Mullen, John P. (Contractor)" , "Nast, Douglas P" , manet@ietf.org Subject: Re: [manet] Dumber Question? References: <02May14.121635mdt.117121@gw.trac.wsmr.army.mil> <20020515.11193800@doldham.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hello Daniel, These are not dumb questions, or dumber questions... Daniel Oldham wrote: > For an ad-hoc network what controls the assignment of IP addresses? I guess it depends on which ad-hoc network you're working on. There is no single answer that applies to every ad-hoc network. > What happens if there are duplicate IP addresses in an ad-hoc network? Lose, lose. > How is an ad-hoc network connected to the Internet? I would like it if our techniques were found useful. We have drafts for both IPv4 and IPv6 connectivity, along with implementations and instructions for address autoconfiguratoin and operation with Mobile IP. > How do packets from the Internet get an IP address in an ad-hoc network? What does it mean for a packet to get an address? If the question is, how a packet gets from the Internet to an address in an ad-hoc network, then it would be because the ad hoc node has a connection (perhaps through one of our Internet gateways) to the Internet, and the gateway advertises reachability to the address of the ad hoc node. The gateway should advertise its routing prefix (RFC 1256 or RFC 2461) for use by the ad hoc nodes. If the ad hoc node is running Mobile IP, then the advertised address can be used for formulating a care-of address. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 15 10:56:38 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 KAA08787 for ; Wed, 15 May 2002 10:56:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29482 for manet-archive@odin.ietf.org; Wed, 15 May 2002 10:56:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25914; Wed, 15 May 2002 10:33:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25884 for ; Wed, 15 May 2002 10:33:48 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07251 for ; Wed, 15 May 2002 10:33:32 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA24511; Wed, 15 May 2002 07:33:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4FEWvI11188; Wed, 15 May 2002 07:32:57 -0700 X-mProtect: <200205151432> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.194.82, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9ruzuL; Wed, 15 May 2002 07:32:53 PDT Message-ID: <3CE27186.8AA51649@iprg.nokia.com> Date: Wed, 15 May 2002 07:32:38 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Oldham CC: "Mullen, John P. (Contractor)" , "Nast, Douglas P" , manet@ietf.org Subject: Re: [manet] Dumber Question? References: <02May14.121635mdt.117121@gw.trac.wsmr.army.mil> <20020515.11193800@doldham.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hello Daniel, These are not dumb questions, or dumber questions... Daniel Oldham wrote: > For an ad-hoc network what controls the assignment of IP addresses? I guess it depends on which ad-hoc network you're working on. There is no single answer that applies to every ad-hoc network. > What happens if there are duplicate IP addresses in an ad-hoc network? Lose, lose. > How is an ad-hoc network connected to the Internet? I would like it if our techniques were found useful. We have drafts for both IPv4 and IPv6 connectivity, along with implementations and instructions for address autoconfiguratoin and operation with Mobile IP. > How do packets from the Internet get an IP address in an ad-hoc network? What does it mean for a packet to get an address? If the question is, how a packet gets from the Internet to an address in an ad-hoc network, then it would be because the ad hoc node has a connection (perhaps through one of our Internet gateways) to the Internet, and the gateway advertises reachability to the address of the ad hoc node. The gateway should advertise its routing prefix (RFC 1256 or RFC 2461) for use by the ad hoc nodes. If the ad hoc node is running Mobile IP, then the advertised address can be used for formulating a care-of address. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 11:34:23 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 LAA09982 for ; Wed, 15 May 2002 11:34:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01050; Wed, 15 May 2002 11:13:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01018 for ; Wed, 15 May 2002 11:13:09 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09447 for ; Wed, 15 May 2002 11:12:53 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA06702; Wed, 15 May 2002 10:08:21 -0500 (CDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id IAA14542; Wed, 15 May 2002 08:12:59 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g4FFDRh20254; Wed, 15 May 2002 08:13:27 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 May 2002 11:12:57 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A390F@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Charlie Perkins'" Cc: manet@ietf.org Subject: RE: [manet] Dumber Question? Date: Wed, 15 May 2002 11:12:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > > How do packets from the Internet get an IP address in an > ad-hoc network? > > What does it mean for a packet to get an address? > > If the question is, how a packet gets from the Internet to an address > in an ad-hoc network, then it would be because the ad hoc node > has a connection (perhaps through one of our Internet gateways) > to the Internet, and the gateway advertises reachability to > the address > of the ad hoc node. The gateway should advertise its routing > prefix (RFC 1256 or RFC 2461) for use by the ad hoc nodes. Hmmm. This is something that has puzzled me too. The only way the wired Internet can route packets reasonably, i.e. without building exhaustive tables with individual host addresses, is to use the IP address prefix. If a MANET node is not provided with a dynamic address somehow, an address with the proper prefix for its current location, _and_ if that address is not changed as the MANET node moves geographically, then I don't see how the wired Internet can continue to find the MANET node. Not unless there is a single, fixed connection point between the wired Internet and the MANET. (If there is that fixed border router, then the answer is pretty straightforward.) > If the ad hoc node is running Mobile IP, then the advertised > address can be used for formulating a care-of address. Mobile IP either has the home server forward everything to the current location of the mobile host, or it can set up a shortcut to that remote location after the current address of the mobile host is provided. But for this to work, the location of the mobile must remain constant for the duration of the session. I'm not sure how use of the Mobile IP care-of address can be a solution to the MANET scenario. I can understand the chaotic "routing" environment related to MANET, and the tradeoffs between proactive and reactive so-called "routing" protocols. But so far, I only understand these discussions if they are limited to the ad-hoc environment. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 15 11:34:28 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 LAA09991 for ; Wed, 15 May 2002 11:34:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA03129 for manet-archive@odin.ietf.org; Wed, 15 May 2002 11:34:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01050; Wed, 15 May 2002 11:13:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01018 for ; Wed, 15 May 2002 11:13:09 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09447 for ; Wed, 15 May 2002 11:12:53 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA06702; Wed, 15 May 2002 10:08:21 -0500 (CDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id IAA14542; Wed, 15 May 2002 08:12:59 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g4FFDRh20254; Wed, 15 May 2002 08:13:27 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 May 2002 11:12:57 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A390F@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Charlie Perkins'" Cc: manet@ietf.org Subject: RE: [manet] Dumber Question? Date: Wed, 15 May 2002 11:12:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > > How do packets from the Internet get an IP address in an > ad-hoc network? > > What does it mean for a packet to get an address? > > If the question is, how a packet gets from the Internet to an address > in an ad-hoc network, then it would be because the ad hoc node > has a connection (perhaps through one of our Internet gateways) > to the Internet, and the gateway advertises reachability to > the address > of the ad hoc node. The gateway should advertise its routing > prefix (RFC 1256 or RFC 2461) for use by the ad hoc nodes. Hmmm. This is something that has puzzled me too. The only way the wired Internet can route packets reasonably, i.e. without building exhaustive tables with individual host addresses, is to use the IP address prefix. If a MANET node is not provided with a dynamic address somehow, an address with the proper prefix for its current location, _and_ if that address is not changed as the MANET node moves geographically, then I don't see how the wired Internet can continue to find the MANET node. Not unless there is a single, fixed connection point between the wired Internet and the MANET. (If there is that fixed border router, then the answer is pretty straightforward.) > If the ad hoc node is running Mobile IP, then the advertised > address can be used for formulating a care-of address. Mobile IP either has the home server forward everything to the current location of the mobile host, or it can set up a shortcut to that remote location after the current address of the mobile host is provided. But for this to work, the location of the mobile must remain constant for the duration of the session. I'm not sure how use of the Mobile IP care-of address can be a solution to the MANET scenario. I can understand the chaotic "routing" environment related to MANET, and the tradeoffs between proactive and reactive so-called "routing" protocols. But so far, I only understand these discussions if they are limited to the ad-hoc environment. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 12:15:38 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 MAA11631 for ; Wed, 15 May 2002 12:15:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04397; Wed, 15 May 2002 11:49:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04367 for ; Wed, 15 May 2002 11:49:24 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10519 for ; Wed, 15 May 2002 11:49:09 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g4FFm9b13407; Wed, 15 May 2002 17:48:09 +0200 (MET DST) Message-ID: <004d01c1fc2a$ea807e40$3ac033c1@inria.fr> From: "Philippe Jacquet" To: "Charlie Perkins" , "Daniel Oldham" Cc: "Mullen, John P. (Contractor)" , "Nast, Douglas P" , References: <02May14.121635mdt.117121@gw.trac.wsmr.army.mil> <20020515.11193800@doldham.lerc.nasa.gov> <3CE27186.8AA51649@iprg.nokia.com> Subject: Re: [manet] Dumber Question? Date: Wed, 15 May 2002 18:09:38 +0200 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Charlie Perkins To: Daniel Oldham Cc: Mullen, John P. (Contractor) ; Nast, Douglas P ; Sent: Wednesday, May 15, 2002 4:32 PM Subject: Re: [manet] Dumber Question? > > > What happens if there are duplicate IP addresses in an ad-hoc network? > > Lose, lose. > Not a very funny situation. I think proactive protocols have more means to detect such events (e.g. when non-common neighbors are advertized) and to trigger appropriate action (e.g. address reconfiguration). Philippe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 15 12:15:39 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 MAA11642 for ; Wed, 15 May 2002 12:15:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA08311 for manet-archive@odin.ietf.org; Wed, 15 May 2002 12:15:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04397; Wed, 15 May 2002 11:49:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04367 for ; Wed, 15 May 2002 11:49:24 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10519 for ; Wed, 15 May 2002 11:49:09 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g4FFm9b13407; Wed, 15 May 2002 17:48:09 +0200 (MET DST) Message-ID: <004d01c1fc2a$ea807e40$3ac033c1@inria.fr> From: "Philippe Jacquet" To: "Charlie Perkins" , "Daniel Oldham" Cc: "Mullen, John P. (Contractor)" , "Nast, Douglas P" , References: <02May14.121635mdt.117121@gw.trac.wsmr.army.mil> <20020515.11193800@doldham.lerc.nasa.gov> <3CE27186.8AA51649@iprg.nokia.com> Subject: Re: [manet] Dumber Question? Date: Wed, 15 May 2002 18:09:38 +0200 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Charlie Perkins To: Daniel Oldham Cc: Mullen, John P. (Contractor) ; Nast, Douglas P ; Sent: Wednesday, May 15, 2002 4:32 PM Subject: Re: [manet] Dumber Question? > > > What happens if there are duplicate IP addresses in an ad-hoc network? > > Lose, lose. > Not a very funny situation. I think proactive protocols have more means to detect such events (e.g. when non-common neighbors are advertized) and to trigger appropriate action (e.g. address reconfiguration). Philippe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 12:23:54 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 MAA11962 for ; Wed, 15 May 2002 12:23:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04857; Wed, 15 May 2002 11:56:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04832 for ; Wed, 15 May 2002 11:56:21 -0400 (EDT) Received: from mail.ececs.uc.edu (ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10770 for ; Wed, 15 May 2002 11:56:05 -0400 (EDT) Received: from capricorn.rhod.uc.edu (capricorn.rhod.uc.edu [10.63.7.117]) by mail.ececs.uc.edu (8.12.2/8.12.2) with ESMTP id g4FFtjxH005793 for ; Wed, 15 May 2002 11:55:45 -0400 (EDT) Received: from localhost (luyy@localhost) by capricorn.rhod.uc.edu (8.9.3/8.9.1) with ESMTP id LAA13135 for ; Wed, 15 May 2002 11:55:44 -0400 X-Authentication-Warning: capricorn.rhod.uc.edu: luyy owned process doing -bs Date: Wed, 15 May 2002 11:55:44 -0400 (EDT) From: Yi Lv X-Sender: luyy@capricorn.rhod.uc.edu To: manet@ietf.org In-Reply-To: <006501c1fa5f$fd9ac3e0$3ac033c1@inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] OLSR script 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 Hi, folks: Because i am not familiar with the OLSR configuration, does anyone send me a sample tcl script to support the running of OLSR? Thank you very much! BR/yi lu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 15 12:23:56 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 MAA11979 for ; Wed, 15 May 2002 12:23:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09038 for manet-archive@odin.ietf.org; Wed, 15 May 2002 12:24:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04857; Wed, 15 May 2002 11:56:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04832 for ; Wed, 15 May 2002 11:56:21 -0400 (EDT) Received: from mail.ececs.uc.edu (ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10770 for ; Wed, 15 May 2002 11:56:05 -0400 (EDT) Received: from capricorn.rhod.uc.edu (capricorn.rhod.uc.edu [10.63.7.117]) by mail.ececs.uc.edu (8.12.2/8.12.2) with ESMTP id g4FFtjxH005793 for ; Wed, 15 May 2002 11:55:45 -0400 (EDT) Received: from localhost (luyy@localhost) by capricorn.rhod.uc.edu (8.9.3/8.9.1) with ESMTP id LAA13135 for ; Wed, 15 May 2002 11:55:44 -0400 X-Authentication-Warning: capricorn.rhod.uc.edu: luyy owned process doing -bs Date: Wed, 15 May 2002 11:55:44 -0400 (EDT) From: Yi Lv X-Sender: luyy@capricorn.rhod.uc.edu To: manet@ietf.org In-Reply-To: <006501c1fa5f$fd9ac3e0$3ac033c1@inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] OLSR script 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 Hi, folks: Because i am not familiar with the OLSR configuration, does anyone send me a sample tcl script to support the running of OLSR? Thank you very much! BR/yi lu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 12:28:53 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 MAA12111 for ; Wed, 15 May 2002 12:28:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07447; Wed, 15 May 2002 12:05:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07400 for ; Wed, 15 May 2002 12:05:40 -0400 (EDT) Received: from amber.crhc.uiuc.edu (amber.crhc.uiuc.edu [130.126.143.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11209 for ; Wed, 15 May 2002 12:05:24 -0400 (EDT) Received: from nhv (dhcp67.crhc.uiuc.edu [130.126.140.67]) by amber.crhc.uiuc.edu (8.9.3/8.9.3) with SMTP id LAA05891; Wed, 15 May 2002 11:05:37 -0500 (CDT) From: "Nitin Vaidya" To: "Charlie Perkins" Cc: Subject: RE: [manet] Dumber Question? Date: Wed, 15 May 2002 11:09:28 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit >>From: manet-admin@ietf.org [mailto:manet-admin@ietf.org]On Behalf Of >>Charlie Perkins >>> What happens if there are duplicate IP addresses in an ad-hoc network? >> >>Lose, lose. Are you sure? What if the packets reach their intended destinations despite address duplication? In that case, duplicate addresses may not be so bad. See www.crhc.uiuc.edu/~nhv/publications.html for a MobiHoc 2002 paper based on this theme. The above paper essentially uses IP address as "labels" which are used for routing, and some other unique string as "key" which is used to set up routes. The "key" can be made unique with adequately low probability simply by choosing a sufficiently long string of bits randomly. IP address duplicate is detected when two different "keys" are assigned the same label (i.e., same IP address). (By the way, the paper does not describe the scheme this way, since I did not see the analogy with labels until recently.) Trivial idea, but can use some improvements (as elaborated in the paper). - nitin _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 15 12:28:58 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 MAA12123 for ; Wed, 15 May 2002 12:28:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09475 for manet-archive@odin.ietf.org; Wed, 15 May 2002 12:29:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07447; Wed, 15 May 2002 12:05:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07400 for ; Wed, 15 May 2002 12:05:40 -0400 (EDT) Received: from amber.crhc.uiuc.edu (amber.crhc.uiuc.edu [130.126.143.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11209 for ; Wed, 15 May 2002 12:05:24 -0400 (EDT) Received: from nhv (dhcp67.crhc.uiuc.edu [130.126.140.67]) by amber.crhc.uiuc.edu (8.9.3/8.9.3) with SMTP id LAA05891; Wed, 15 May 2002 11:05:37 -0500 (CDT) From: "Nitin Vaidya" To: "Charlie Perkins" Cc: Subject: RE: [manet] Dumber Question? Date: Wed, 15 May 2002 11:09:28 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit >>From: manet-admin@ietf.org [mailto:manet-admin@ietf.org]On Behalf Of >>Charlie Perkins >>> What happens if there are duplicate IP addresses in an ad-hoc network? >> >>Lose, lose. Are you sure? What if the packets reach their intended destinations despite address duplication? In that case, duplicate addresses may not be so bad. See www.crhc.uiuc.edu/~nhv/publications.html for a MobiHoc 2002 paper based on this theme. The above paper essentially uses IP address as "labels" which are used for routing, and some other unique string as "key" which is used to set up routes. The "key" can be made unique with adequately low probability simply by choosing a sufficiently long string of bits randomly. IP address duplicate is detected when two different "keys" are assigned the same label (i.e., same IP address). (By the way, the paper does not describe the scheme this way, since I did not see the analogy with labels until recently.) Trivial idea, but can use some improvements (as elaborated in the paper). - nitin _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 12:49:36 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 MAA12942 for ; Wed, 15 May 2002 12:49:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09233; Wed, 15 May 2002 12:27:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09201 for ; Wed, 15 May 2002 12:27:26 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12054 for ; Wed, 15 May 2002 12:27:12 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA29968; Wed, 15 May 2002 09:26:54 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4FGQr332415; Wed, 15 May 2002 09:26:53 -0700 X-mProtect: <200205151626> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.194.82, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8Ambdp; Wed, 15 May 2002 09:26:49 PDT Message-ID: <3CE28C3A.77D756F6@iprg.nokia.com> Date: Wed, 15 May 2002 09:26:34 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Philippe Jacquet CC: manet@ietf.org Subject: Re: [manet] Dumber Question? References: <02May14.121635mdt.117121@gw.trac.wsmr.army.mil> <20020515.11193800@doldham.lerc.nasa.gov> <3CE27186.8AA51649@iprg.nokia.com> <004d01c1fc2a$ea807e40$3ac033c1@inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hello Philippe, Philippe Jacquet wrote: > > > What happens if there are duplicate IP addresses in an ad-hoc network? > > > > Lose, lose. > > > Not a very funny situation. I think proactive protocols have more means to > detect such events (e.g. when non-common neighbors are advertized) and to > trigger appropriate action (e.g. address reconfiguration). I reckon you are right, that being in this losing situation isn't funny. But I wouldn't jump right away to a 100% proactive solution... Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 15 12:49:37 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 MAA12952 for ; Wed, 15 May 2002 12:49:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11672 for manet-archive@odin.ietf.org; Wed, 15 May 2002 12:49:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09233; Wed, 15 May 2002 12:27:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09201 for ; Wed, 15 May 2002 12:27:26 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12054 for ; Wed, 15 May 2002 12:27:12 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA29968; Wed, 15 May 2002 09:26:54 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4FGQr332415; Wed, 15 May 2002 09:26:53 -0700 X-mProtect: <200205151626> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.194.82, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8Ambdp; Wed, 15 May 2002 09:26:49 PDT Message-ID: <3CE28C3A.77D756F6@iprg.nokia.com> Date: Wed, 15 May 2002 09:26:34 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Philippe Jacquet CC: manet@ietf.org Subject: Re: [manet] Dumber Question? References: <02May14.121635mdt.117121@gw.trac.wsmr.army.mil> <20020515.11193800@doldham.lerc.nasa.gov> <3CE27186.8AA51649@iprg.nokia.com> <004d01c1fc2a$ea807e40$3ac033c1@inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hello Philippe, Philippe Jacquet wrote: > > > What happens if there are duplicate IP addresses in an ad-hoc network? > > > > Lose, lose. > > > Not a very funny situation. I think proactive protocols have more means to > detect such events (e.g. when non-common neighbors are advertized) and to > trigger appropriate action (e.g. address reconfiguration). I reckon you are right, that being in this losing situation isn't funny. But I wouldn't jump right away to a 100% proactive solution... Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 13:04:28 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 NAA13483 for ; Wed, 15 May 2002 13:04:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10670; Wed, 15 May 2002 12:39:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10644 for ; Wed, 15 May 2002 12:39:19 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12522 for ; Wed, 15 May 2002 12:39:05 -0400 (EDT) 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 JAA01007; Wed, 15 May 2002 09:36:45 -0700 (PDT) Message-Id: <200205151636.JAA01007@pit.erg.sri.com> To: Charlie Perkins cc: manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Dumb Question? In-reply-to: Your message of "Wed, 15 May 2002 07:26:04 PDT." <3CE26FFC.D79D0B54@iprg.nokia.com> Date: Wed, 15 May 2002 09:36:45 -0700 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 Charlie, You results sound impressive. I assume you are using plain AODV (without any hierarchical extension). I would like to know more details about your results, e.g., how many nodes are traffic sources, what is the average number of neighbors, node speed, and session duration. Richard > > Hello Douglas, > > We have results for scaling AODV up to 10,000 nodes. > We know that we can do better by improving the packet > delivery ratio. In a few weeks, I reckon we'll have some > specific directions for algorithm improvement. > > ZDP is theoretically able to do better, simply because it > admits as special cases all on-demand protocols. However, > I have never seen any results showing ZDP on a network > of 10,000 nodes (simulated). > > Regards, > Charlie P. > > > "Nast, Douglas P" wrote: > > > Zygmunt, > > > > I think your idea is very interesting, as it addresses the latency issue fo r > > routes in your zone (which is important in military apps), and offers the > > promise of scalability: The reactive inter-zone idea is reminiscent of the > > hierarchical architecture of OSPF, which essentially operates LS intra-area > > and DV inter-area. How would you contrast your zone idea to OSPF areas? > > > > Doug Nast, Boeing > > > > -----Original Message----- > > From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] > > Sent: Tuesday, May 14, 2002 11:56 AM > > To: Mullen, John P. (Contractor) > > Cc: manet@ietf.org > > Subject: RE: [manet] Dumb Question? > > > > Hi John, > > > > > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. I n > > > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser > > speculates > > > on p. 33 that it is unlikely a single protocol will be able to operate > > > efficiently over the full range of conditions under which a military MANE T > > > must operate. If he is correct, the issue may never be fully resolved. > > > > Yes, I read this book too (:-) ... > > > > I hate to bring this point over again ... and self-promote our work ... > > but the issue of "efficient operation over a wide range of conditions" can > > and should be addressed by a *hybrid* routing scheme, where the "proactive" > > and "reactive" behavior are "mixed" in the amounts that match these > > operational conditions. In other words, *adaptivity* is the key issue > > here. > > > > One such an example of a hybrid scheme is (of course, you have guessed) > > the ZRP protocol, in which the amount of proactive vs reactive behavior is > > *dynamically* adjusted through a single parameter - the zone radius. > > > > Now imagine this - one could use the AODV (or DSR, or your favorite > > reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or > > your favorite proactive protocol) as the proactive protocol in ZRP (I > > tried to offend the smallest number of people here (;-)). This is why ZRP > > is a framework for ... for exactly this - for "efficient operation over a > > wide range of conditions". So, maybe, there is a hope to resolve this > > issue after all. > > > > Zygmunt. > > ==-=-===== > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > > Wireless Networks Laboratory http://wnl.ece.cornell.edu > > School of Electrical Engineering > > Cornell University tel: +1-607-255-3454 > > 323 Frank Rhodes Hall fax: +1-607-255-9072 > > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > > U.S.A > > WNL web page: http://wnl.ece.cornell.edu > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 15 13:04:29 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 NAA13494 for ; Wed, 15 May 2002 13:04:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13167 for manet-archive@odin.ietf.org; Wed, 15 May 2002 13:04:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10670; Wed, 15 May 2002 12:39:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10644 for ; Wed, 15 May 2002 12:39:19 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12522 for ; Wed, 15 May 2002 12:39:05 -0400 (EDT) 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 JAA01007; Wed, 15 May 2002 09:36:45 -0700 (PDT) Message-Id: <200205151636.JAA01007@pit.erg.sri.com> To: Charlie Perkins cc: manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Dumb Question? In-reply-to: Your message of "Wed, 15 May 2002 07:26:04 PDT." <3CE26FFC.D79D0B54@iprg.nokia.com> Date: Wed, 15 May 2002 09:36:45 -0700 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 Charlie, You results sound impressive. I assume you are using plain AODV (without any hierarchical extension). I would like to know more details about your results, e.g., how many nodes are traffic sources, what is the average number of neighbors, node speed, and session duration. Richard > > Hello Douglas, > > We have results for scaling AODV up to 10,000 nodes. > We know that we can do better by improving the packet > delivery ratio. In a few weeks, I reckon we'll have some > specific directions for algorithm improvement. > > ZDP is theoretically able to do better, simply because it > admits as special cases all on-demand protocols. However, > I have never seen any results showing ZDP on a network > of 10,000 nodes (simulated). > > Regards, > Charlie P. > > > "Nast, Douglas P" wrote: > > > Zygmunt, > > > > I think your idea is very interesting, as it addresses the latency issue fo r > > routes in your zone (which is important in military apps), and offers the > > promise of scalability: The reactive inter-zone idea is reminiscent of the > > hierarchical architecture of OSPF, which essentially operates LS intra-area > > and DV inter-area. How would you contrast your zone idea to OSPF areas? > > > > Doug Nast, Boeing > > > > -----Original Message----- > > From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] > > Sent: Tuesday, May 14, 2002 11:56 AM > > To: Mullen, John P. (Contractor) > > Cc: manet@ietf.org > > Subject: RE: [manet] Dumb Question? > > > > Hi John, > > > > > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. I n > > > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser > > speculates > > > on p. 33 that it is unlikely a single protocol will be able to operate > > > efficiently over the full range of conditions under which a military MANE T > > > must operate. If he is correct, the issue may never be fully resolved. > > > > Yes, I read this book too (:-) ... > > > > I hate to bring this point over again ... and self-promote our work ... > > but the issue of "efficient operation over a wide range of conditions" can > > and should be addressed by a *hybrid* routing scheme, where the "proactive" > > and "reactive" behavior are "mixed" in the amounts that match these > > operational conditions. In other words, *adaptivity* is the key issue > > here. > > > > One such an example of a hybrid scheme is (of course, you have guessed) > > the ZRP protocol, in which the amount of proactive vs reactive behavior is > > *dynamically* adjusted through a single parameter - the zone radius. > > > > Now imagine this - one could use the AODV (or DSR, or your favorite > > reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or > > your favorite proactive protocol) as the proactive protocol in ZRP (I > > tried to offend the smallest number of people here (;-)). This is why ZRP > > is a framework for ... for exactly this - for "efficient operation over a > > wide range of conditions". So, maybe, there is a hope to resolve this > > issue after all. > > > > Zygmunt. > > ==-=-===== > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > > Wireless Networks Laboratory http://wnl.ece.cornell.edu > > School of Electrical Engineering > > Cornell University tel: +1-607-255-3454 > > 323 Frank Rhodes Hall fax: +1-607-255-9072 > > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > > U.S.A > > WNL web page: http://wnl.ece.cornell.edu > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 14:40:01 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 OAA17208 for ; Wed, 15 May 2002 14:40:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18585; Wed, 15 May 2002 14:18:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18554 for ; Wed, 15 May 2002 14:18:07 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16443 for ; Wed, 15 May 2002 14:17:52 -0400 (EDT) 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 LAA01629; Wed, 15 May 2002 11:15:44 -0700 (PDT) Message-Id: <200205151815.LAA01629@pit.erg.sri.com> To: manet@ietf.org cc: ogier@erg.sri.com Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Dumber Question? In-reply-to: Your message of "Wed, 15 May 2002 18:09:38 +0200." <004d01c1fc2a$ea807e40$3ac033c1@inria.fr> Date: Wed, 15 May 2002 11:15:44 -0700 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 > > ----- Original Message ----- > From: Charlie Perkins > To: Daniel Oldham > Cc: Mullen, John P. (Contractor) ; > Nast, Douglas P ; > Sent: Wednesday, May 15, 2002 4:32 PM > Subject: Re: [manet] Dumber Question? > > > > > > > What happens if there are duplicate IP addresses in an ad-hoc network? > > > > Lose, lose. > > > Not a very funny situation. I think proactive protocols have more means to > detect such events (e.g. when non-common neighbors are advertized) and to > trigger appropriate action (e.g. address reconfiguration). > > Philippe Yes, proactive protocols have a lot of advantages over on-demand protocols that have not been discussed much. For example, if one node wants to send a message to another node that is currently unreachable, an on-demand protocol will try to discover a route a few times and then give up (and then perhaps try periodically). If proactive routing is used, the sending node will be informed as soon as the unreachable node becomes reachable. Another advantage of proactive protocols is that more efficient flooding is possible at no extra cost, using the topology information provided by the proactive protocol (e.g., parents in TBRPF or MPRs in OLSR.) Of course there are other advantages (e.g., proactive protocols are more efficient when the number of sources is large, proactive protocols can ensure that an alternate route is always maintained, etc.). Richard > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 15 14:40:02 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 OAA17217 for ; Wed, 15 May 2002 14:40:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20233 for manet-archive@odin.ietf.org; Wed, 15 May 2002 14:40:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18585; Wed, 15 May 2002 14:18:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18554 for ; Wed, 15 May 2002 14:18:07 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16443 for ; Wed, 15 May 2002 14:17:52 -0400 (EDT) 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 LAA01629; Wed, 15 May 2002 11:15:44 -0700 (PDT) Message-Id: <200205151815.LAA01629@pit.erg.sri.com> To: manet@ietf.org cc: ogier@erg.sri.com Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Dumber Question? In-reply-to: Your message of "Wed, 15 May 2002 18:09:38 +0200." <004d01c1fc2a$ea807e40$3ac033c1@inria.fr> Date: Wed, 15 May 2002 11:15:44 -0700 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 > > ----- Original Message ----- > From: Charlie Perkins > To: Daniel Oldham > Cc: Mullen, John P. (Contractor) ; > Nast, Douglas P ; > Sent: Wednesday, May 15, 2002 4:32 PM > Subject: Re: [manet] Dumber Question? > > > > > > > What happens if there are duplicate IP addresses in an ad-hoc network? > > > > Lose, lose. > > > Not a very funny situation. I think proactive protocols have more means to > detect such events (e.g. when non-common neighbors are advertized) and to > trigger appropriate action (e.g. address reconfiguration). > > Philippe Yes, proactive protocols have a lot of advantages over on-demand protocols that have not been discussed much. For example, if one node wants to send a message to another node that is currently unreachable, an on-demand protocol will try to discover a route a few times and then give up (and then perhaps try periodically). If proactive routing is used, the sending node will be informed as soon as the unreachable node becomes reachable. Another advantage of proactive protocols is that more efficient flooding is possible at no extra cost, using the topology information provided by the proactive protocol (e.g., parents in TBRPF or MPRs in OLSR.) Of course there are other advantages (e.g., proactive protocols are more efficient when the number of sources is large, proactive protocols can ensure that an alternate route is always maintained, etc.). Richard > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 15:19:16 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 PAA18709 for ; Wed, 15 May 2002 15:19:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21055; Wed, 15 May 2002 14:59:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21024 for ; Wed, 15 May 2002 14:59:00 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17923 for ; Wed, 15 May 2002 14:58:45 -0400 (EDT) From: haas@ece.cornell.edu Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g4FIwu127296; Wed, 15 May 2002 14:58:56 -0400 Date: Wed, 15 May 2002 14:58:48 -0400 (EDT) X-Sender: haas@verdi.ee.cornell.edu To: Charlie Perkins cc: "Nast, Douglas P" , manet@ietf.org Subject: Re: [manet] Dumb Question? In-Reply-To: <3CE26FFC.D79D0B54@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hi Charlie, Well, I agree with you that since pure on-demand protocol is a special case of a hybrid scheme, such as ZRP, a hybrid scheme performance is bound to produce at least as good results as any of the two extremes - purely proactive and purely proactive schemes. In fact, our study (for example, the paper in your book) shows that it can reduce the control traffic to a small fraction of those two extremes. These results have been confirmed both analytically and through simulation. Your point regarding scalability is a very valid point. We are currently evaluating the scalability of the hybrid (ZRP) approach for thousands to tens of thousands of nodes. This is not a trivial task, taking into the account the simulation runtime duration. But the preliminary results are *very* encouraging, to say the least. Stay tuned .... Zygmunt. ==-=-===== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- On Wed, 15 May 2002, Charlie Perkins wrote: > > Hello Douglas, > > We have results for scaling AODV up to 10,000 nodes. > We know that we can do better by improving the packet > delivery ratio. In a few weeks, I reckon we'll have some > specific directions for algorithm improvement. > > ZDP is theoretically able to do better, simply because it > admits as special cases all on-demand protocols. However, > I have never seen any results showing ZDP on a network > of 10,000 nodes (simulated). > > Regards, > Charlie P. > > > "Nast, Douglas P" wrote: > > > Zygmunt, > > > > I think your idea is very interesting, as it addresses the latency issue for > > routes in your zone (which is important in military apps), and offers the > > promise of scalability: The reactive inter-zone idea is reminiscent of the > > hierarchical architecture of OSPF, which essentially operates LS intra-area > > and DV inter-area. How would you contrast your zone idea to OSPF areas? > > > > Doug Nast, Boeing > > > > -----Original Message----- > > From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] > > Sent: Tuesday, May 14, 2002 11:56 AM > > To: Mullen, John P. (Contractor) > > Cc: manet@ietf.org > > Subject: RE: [manet] Dumb Question? > > > > Hi John, > > > > > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > > > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser > > speculates > > > on p. 33 that it is unlikely a single protocol will be able to operate > > > efficiently over the full range of conditions under which a military MANET > > > must operate. If he is correct, the issue may never be fully resolved. > > > > Yes, I read this book too (:-) ... > > > > I hate to bring this point over again ... and self-promote our work ... > > but the issue of "efficient operation over a wide range of conditions" can > > and should be addressed by a *hybrid* routing scheme, where the "proactive" > > and "reactive" behavior are "mixed" in the amounts that match these > > operational conditions. In other words, *adaptivity* is the key issue > > here. > > > > One such an example of a hybrid scheme is (of course, you have guessed) > > the ZRP protocol, in which the amount of proactive vs reactive behavior is > > *dynamically* adjusted through a single parameter - the zone radius. > > > > Now imagine this - one could use the AODV (or DSR, or your favorite > > reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or > > your favorite proactive protocol) as the proactive protocol in ZRP (I > > tried to offend the smallest number of people here (;-)). This is why ZRP > > is a framework for ... for exactly this - for "efficient operation over a > > wide range of conditions". So, maybe, there is a hope to resolve this > > issue after all. > > > > Zygmunt. > > ==-=-===== > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > > Wireless Networks Laboratory http://wnl.ece.cornell.edu > > School of Electrical Engineering > > Cornell University tel: +1-607-255-3454 > > 323 Frank Rhodes Hall fax: +1-607-255-9072 > > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > > U.S.A > > WNL web page: http://wnl.ece.cornell.edu > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 15 15:19:21 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 PAA18719 for ; Wed, 15 May 2002 15:19:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA23158 for manet-archive@odin.ietf.org; Wed, 15 May 2002 15:19:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21055; Wed, 15 May 2002 14:59:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21024 for ; Wed, 15 May 2002 14:59:00 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17923 for ; Wed, 15 May 2002 14:58:45 -0400 (EDT) From: haas@ece.cornell.edu Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g4FIwu127296; Wed, 15 May 2002 14:58:56 -0400 Date: Wed, 15 May 2002 14:58:48 -0400 (EDT) X-Sender: haas@verdi.ee.cornell.edu To: Charlie Perkins cc: "Nast, Douglas P" , manet@ietf.org Subject: Re: [manet] Dumb Question? In-Reply-To: <3CE26FFC.D79D0B54@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hi Charlie, Well, I agree with you that since pure on-demand protocol is a special case of a hybrid scheme, such as ZRP, a hybrid scheme performance is bound to produce at least as good results as any of the two extremes - purely proactive and purely proactive schemes. In fact, our study (for example, the paper in your book) shows that it can reduce the control traffic to a small fraction of those two extremes. These results have been confirmed both analytically and through simulation. Your point regarding scalability is a very valid point. We are currently evaluating the scalability of the hybrid (ZRP) approach for thousands to tens of thousands of nodes. This is not a trivial task, taking into the account the simulation runtime duration. But the preliminary results are *very* encouraging, to say the least. Stay tuned .... Zygmunt. ==-=-===== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- On Wed, 15 May 2002, Charlie Perkins wrote: > > Hello Douglas, > > We have results for scaling AODV up to 10,000 nodes. > We know that we can do better by improving the packet > delivery ratio. In a few weeks, I reckon we'll have some > specific directions for algorithm improvement. > > ZDP is theoretically able to do better, simply because it > admits as special cases all on-demand protocols. However, > I have never seen any results showing ZDP on a network > of 10,000 nodes (simulated). > > Regards, > Charlie P. > > > "Nast, Douglas P" wrote: > > > Zygmunt, > > > > I think your idea is very interesting, as it addresses the latency issue for > > routes in your zone (which is important in military apps), and offers the > > promise of scalability: The reactive inter-zone idea is reminiscent of the > > hierarchical architecture of OSPF, which essentially operates LS intra-area > > and DV inter-area. How would you contrast your zone idea to OSPF areas? > > > > Doug Nast, Boeing > > > > -----Original Message----- > > From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] > > Sent: Tuesday, May 14, 2002 11:56 AM > > To: Mullen, John P. (Contractor) > > Cc: manet@ietf.org > > Subject: RE: [manet] Dumb Question? > > > > Hi John, > > > > > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > > > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser > > speculates > > > on p. 33 that it is unlikely a single protocol will be able to operate > > > efficiently over the full range of conditions under which a military MANET > > > must operate. If he is correct, the issue may never be fully resolved. > > > > Yes, I read this book too (:-) ... > > > > I hate to bring this point over again ... and self-promote our work ... > > but the issue of "efficient operation over a wide range of conditions" can > > and should be addressed by a *hybrid* routing scheme, where the "proactive" > > and "reactive" behavior are "mixed" in the amounts that match these > > operational conditions. In other words, *adaptivity* is the key issue > > here. > > > > One such an example of a hybrid scheme is (of course, you have guessed) > > the ZRP protocol, in which the amount of proactive vs reactive behavior is > > *dynamically* adjusted through a single parameter - the zone radius. > > > > Now imagine this - one could use the AODV (or DSR, or your favorite > > reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or > > your favorite proactive protocol) as the proactive protocol in ZRP (I > > tried to offend the smallest number of people here (;-)). This is why ZRP > > is a framework for ... for exactly this - for "efficient operation over a > > wide range of conditions". So, maybe, there is a hope to resolve this > > issue after all. > > > > Zygmunt. > > ==-=-===== > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > > Wireless Networks Laboratory http://wnl.ece.cornell.edu > > School of Electrical Engineering > > Cornell University tel: +1-607-255-3454 > > 323 Frank Rhodes Hall fax: +1-607-255-9072 > > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > > U.S.A > > WNL web page: http://wnl.ece.cornell.edu > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 16:03:46 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 QAA20675 for ; Wed, 15 May 2002 16:03:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25871; Wed, 15 May 2002 15:44:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25843 for ; Wed, 15 May 2002 15:44:01 -0400 (EDT) Received: from Eng.Auburn.EDU (dns.eng.auburn.edu [131.204.10.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19985 for ; Wed, 15 May 2002 15:43:46 -0400 (EDT) Received: from chadia.eng.auburn.edu (IDENT:31366@chadia.eng.auburn.edu [131.204.19.11]) by Eng.Auburn.EDU (8.11.6/8.11.6) with ESMTP id g4FJhtc19997; Wed, 15 May 2002 14:43:55 -0500 (CDT) Received: from localhost (sbiaz@localhost) by chadia.eng.auburn.edu (8.10.2+Sun/8.6.4) with ESMTP id g4FJhvv05368; Wed, 15 May 2002 14:43:57 -0500 (CDT) X-Authentication-Warning: chadia.eng.auburn.edu: sbiaz owned process doing -bs Date: Wed, 15 May 2002 14:43:57 -0500 (CDT) From: Saad Biaz To: ogier@erg.sri.com cc: manet@ietf.org Subject: Re: [manet] Dumber Question? In-Reply-To: <200205151815.LAA01629@pit.erg.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 > Yes, proactive protocols have a lot of advantages over on-demand > protocols that have not been discussed much. > For example, if one node wants to send a message to another > node that is currently unreachable, an on-demand protocol will > try to discover a route a few times and then give up (and then perhaps > try periodically). If proactive routing is used, the sending node > will be informed as soon as the unreachable node becomes reachable. Maybe I am missing something of your reasoning. But, this is not not an argument in favor of proactive routing algorithms. What is the interest of being informed that the unreachable node is now reachable? There is no interest if upper layers (transport and up) gave up. We do not keep (for a long time) packets to route until a route is found. In other words, what is the point of being informed that a node is reachable if I do not have packets to send to it? For the case where the upper layers did not give up, the reactive algorithm will keep trying too..... _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 15 16:03:51 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 QAA20684 for ; Wed, 15 May 2002 16:03:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27644 for manet-archive@odin.ietf.org; Wed, 15 May 2002 16:04:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25871; Wed, 15 May 2002 15:44:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25843 for ; Wed, 15 May 2002 15:44:01 -0400 (EDT) Received: from Eng.Auburn.EDU (dns.eng.auburn.edu [131.204.10.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19985 for ; Wed, 15 May 2002 15:43:46 -0400 (EDT) Received: from chadia.eng.auburn.edu (IDENT:31366@chadia.eng.auburn.edu [131.204.19.11]) by Eng.Auburn.EDU (8.11.6/8.11.6) with ESMTP id g4FJhtc19997; Wed, 15 May 2002 14:43:55 -0500 (CDT) Received: from localhost (sbiaz@localhost) by chadia.eng.auburn.edu (8.10.2+Sun/8.6.4) with ESMTP id g4FJhvv05368; Wed, 15 May 2002 14:43:57 -0500 (CDT) X-Authentication-Warning: chadia.eng.auburn.edu: sbiaz owned process doing -bs Date: Wed, 15 May 2002 14:43:57 -0500 (CDT) From: Saad Biaz To: ogier@erg.sri.com cc: manet@ietf.org Subject: Re: [manet] Dumber Question? In-Reply-To: <200205151815.LAA01629@pit.erg.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 > Yes, proactive protocols have a lot of advantages over on-demand > protocols that have not been discussed much. > For example, if one node wants to send a message to another > node that is currently unreachable, an on-demand protocol will > try to discover a route a few times and then give up (and then perhaps > try periodically). If proactive routing is used, the sending node > will be informed as soon as the unreachable node becomes reachable. Maybe I am missing something of your reasoning. But, this is not not an argument in favor of proactive routing algorithms. What is the interest of being informed that the unreachable node is now reachable? There is no interest if upper layers (transport and up) gave up. We do not keep (for a long time) packets to route until a route is found. In other words, what is the point of being informed that a node is reachable if I do not have packets to send to it? For the case where the upper layers did not give up, the reactive algorithm will keep trying too..... _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 17:01:59 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 RAA22133 for ; Wed, 15 May 2002 17:01:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00209; Wed, 15 May 2002 16:43:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00172 for ; Wed, 15 May 2002 16:43:09 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21771 for ; Wed, 15 May 2002 16:42:52 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117129>; Wed, 15 May 2002 14:43:00 -0600 Message-Id: <02May15.144300mdt.117129@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: manet@ietf.org Subject: RE: [manet] Dumber Question? Date: Wed, 15 May 2002 14:42:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 Hi Richard, I'm not so sure this is a clear advantage, at least not in highly dynamic MANETs. If link status changes rapidly, say every minute or so, a proactive protocol would have to have nodes advertise about twice a minute in order to have routing tables that are reasonably accurate. Because of the possibility of data collisions, this will tie up the MANET, at least locally, for a sizable chunk of the available time, leading to significantly less bandwidth available for the transmission of data. Also, if the MANET is sizable, not only will there be more bandwidth lost to advertisements, but the propagation the advertisements to all nodes in the net will take a considerable amount of additional time. This may be long enough that at no time do all nodes have an accurate picture of the network. Another complication arises in the case of asymmetric links. In this case, the fact that Node A can hear B does not mean Node B can hear Node A. So, if Node A receives an advertisement from Node B, it is not assurance that Node B is reachable directly from Node A. Node A must respond to Node B's advertisement, in which case both A and B will know they can reach each other. This means we need about twice as many packets to establish the proactive routing. Of course, both problems become worse rapidly with the size of the net, so one might be able to have a proactive protocol locally (involving just a few nodes), but a reactive protocol globally. John Mullen -----Original Message----- From: ogier@erg.sri.com [mailto:ogier@erg.sri.com] Sent: Wednesday, May 15, 2002 12:16 PM To: manet@ietf.org Cc: ogier@erg.sri.com Subject: Re: [manet] Dumber Question? > Yes, proactive protocols have a lot of advantages over on-demand protocols that have not been discussed much. For example, if one node wants to send a message to another node that is currently unreachable, an on-demand protocol will try to discover a route a few times and then give up (and then perhaps try periodically). If proactive routing is used, the sending node will be informed as soon as the unreachable node becomes reachable. Another advantage of proactive protocols is that more efficient flooding is possible at no extra cost, using the topology information provided by the proactive protocol (e.g., parents in TBRPF or MPRs in OLSR.) Of course there are other advantages (e.g., proactive protocols are more efficient when the number of sources is large, proactive protocols can ensure that an alternate route is always maintained, etc.). Richard > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 15 17:01:59 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 RAA22144 for ; Wed, 15 May 2002 17:01:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02402 for manet-archive@odin.ietf.org; Wed, 15 May 2002 17:02:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00209; Wed, 15 May 2002 16:43:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00172 for ; Wed, 15 May 2002 16:43:09 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21771 for ; Wed, 15 May 2002 16:42:52 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117129>; Wed, 15 May 2002 14:43:00 -0600 Message-Id: <02May15.144300mdt.117129@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: manet@ietf.org Subject: RE: [manet] Dumber Question? Date: Wed, 15 May 2002 14:42:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 Hi Richard, I'm not so sure this is a clear advantage, at least not in highly dynamic MANETs. If link status changes rapidly, say every minute or so, a proactive protocol would have to have nodes advertise about twice a minute in order to have routing tables that are reasonably accurate. Because of the possibility of data collisions, this will tie up the MANET, at least locally, for a sizable chunk of the available time, leading to significantly less bandwidth available for the transmission of data. Also, if the MANET is sizable, not only will there be more bandwidth lost to advertisements, but the propagation the advertisements to all nodes in the net will take a considerable amount of additional time. This may be long enough that at no time do all nodes have an accurate picture of the network. Another complication arises in the case of asymmetric links. In this case, the fact that Node A can hear B does not mean Node B can hear Node A. So, if Node A receives an advertisement from Node B, it is not assurance that Node B is reachable directly from Node A. Node A must respond to Node B's advertisement, in which case both A and B will know they can reach each other. This means we need about twice as many packets to establish the proactive routing. Of course, both problems become worse rapidly with the size of the net, so one might be able to have a proactive protocol locally (involving just a few nodes), but a reactive protocol globally. John Mullen -----Original Message----- From: ogier@erg.sri.com [mailto:ogier@erg.sri.com] Sent: Wednesday, May 15, 2002 12:16 PM To: manet@ietf.org Cc: ogier@erg.sri.com Subject: Re: [manet] Dumber Question? > Yes, proactive protocols have a lot of advantages over on-demand protocols that have not been discussed much. For example, if one node wants to send a message to another node that is currently unreachable, an on-demand protocol will try to discover a route a few times and then give up (and then perhaps try periodically). If proactive routing is used, the sending node will be informed as soon as the unreachable node becomes reachable. Another advantage of proactive protocols is that more efficient flooding is possible at no extra cost, using the topology information provided by the proactive protocol (e.g., parents in TBRPF or MPRs in OLSR.) Of course there are other advantages (e.g., proactive protocols are more efficient when the number of sources is large, proactive protocols can ensure that an alternate route is always maintained, etc.). Richard > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 17:14:27 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 RAA22451 for ; Wed, 15 May 2002 17:14:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00741; Wed, 15 May 2002 16:54:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00716 for ; Wed, 15 May 2002 16:54:56 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21951 for ; Wed, 15 May 2002 16:54:40 -0400 (EDT) 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 NAA02701; Wed, 15 May 2002 13:52:33 -0700 (PDT) Message-Id: <200205152052.NAA02701@pit.erg.sri.com> To: Saad Biaz cc: ogier@erg.sri.com, manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Dumber Question? In-reply-to: Your message of "Wed, 15 May 2002 14:43:57 CDT." Date: Wed, 15 May 2002 13:52:33 -0700 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 > > Yes, proactive protocols have a lot of advantages over on-demand > > protocols that have not been discussed much. > > For example, if one node wants to send a message to another > > node that is currently unreachable, an on-demand protocol will > > try to discover a route a few times and then give up (and then perhaps > > try periodically). If proactive routing is used, the sending node > > will be informed as soon as the unreachable node becomes reachable. > > Maybe I am missing something of your reasoning. > But, this is not not an argument in favor of proactive routing algorithms. > What is the interest of being informed that the unreachable node is now > reachable? There is no interest if upper layers (transport and up) gave > up. We do not keep (for a long time) packets to route until a route is > found. Suppose there was an urgent need for you to send a message to someone. Would you give up after a few tries? Instead of trying periodically (thus consuming bandwidth with RREQs), wouldn't it be nice if the network would inform you when the person becomes reachable? Richard > In other words, what is the point of being informed that a node is > reachable if I do not have packets to send to it? > > For the case where the upper layers did not give up, the reactive > algorithm will keep trying too..... > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 15 17:14:28 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 RAA22462 for ; Wed, 15 May 2002 17:14:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02953 for manet-archive@odin.ietf.org; Wed, 15 May 2002 17:14:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00741; Wed, 15 May 2002 16:54:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00716 for ; Wed, 15 May 2002 16:54:56 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21951 for ; Wed, 15 May 2002 16:54:40 -0400 (EDT) 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 NAA02701; Wed, 15 May 2002 13:52:33 -0700 (PDT) Message-Id: <200205152052.NAA02701@pit.erg.sri.com> To: Saad Biaz cc: ogier@erg.sri.com, manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Dumber Question? In-reply-to: Your message of "Wed, 15 May 2002 14:43:57 CDT." Date: Wed, 15 May 2002 13:52:33 -0700 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 > > Yes, proactive protocols have a lot of advantages over on-demand > > protocols that have not been discussed much. > > For example, if one node wants to send a message to another > > node that is currently unreachable, an on-demand protocol will > > try to discover a route a few times and then give up (and then perhaps > > try periodically). If proactive routing is used, the sending node > > will be informed as soon as the unreachable node becomes reachable. > > Maybe I am missing something of your reasoning. > But, this is not not an argument in favor of proactive routing algorithms. > What is the interest of being informed that the unreachable node is now > reachable? There is no interest if upper layers (transport and up) gave > up. We do not keep (for a long time) packets to route until a route is > found. Suppose there was an urgent need for you to send a message to someone. Would you give up after a few tries? Instead of trying periodically (thus consuming bandwidth with RREQs), wouldn't it be nice if the network would inform you when the person becomes reachable? Richard > In other words, what is the point of being informed that a node is > reachable if I do not have packets to send to it? > > For the case where the upper layers did not give up, the reactive > algorithm will keep trying too..... > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 18:04:51 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 SAA23694 for ; Wed, 15 May 2002 18:04:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04432; Wed, 15 May 2002 17:45:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04401 for ; Wed, 15 May 2002 17:45:10 -0400 (EDT) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23223 for ; Wed, 15 May 2002 17:44:52 -0400 (EDT) Received: from dagger.cc.vt.edu (IDENT:mirapoint@dagger-lb.cc.vt.edu [10.1.1.11]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id g4FLj6e294034; Wed, 15 May 2002 17:45:06 -0400 (EDT) Received: from TNT (h80ad3776.dhcp.vt.edu [128.173.55.118]) by dagger.cc.vt.edu (Mirapoint Messaging Server MOS 3.1.0.54-GA) with SMTP id AKP17565; Wed, 15 May 2002 17:28:42 -0400 (EDT) Message-ID: <009e01c1fc59$ba65b0c0$7637ad80@workgroup> From: "Tao Lin" To: "Mullen, John P. \(Contractor\)" Cc: References: <02May15.144300mdt.117129@gw.trac.wsmr.army.mil> Subject: Re: [manet] Dumber Question? Date: Wed, 15 May 2002 17:44:44 -0400 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 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit I agree that proactive protocols may have higher overhead if a topology change does not affect a in-use route. We have to admit that this is a disadvantage for proactive protocols in MANET. However, proactive protocols have many advantages, e.g. they can respond to route changes faster, they provide immediate notification of reachable or unreachable destinations (reactive protocols can not decide whether the destination is unreachable or not because there could be packet collisions when broadcasting route requests or destination unreachable.), in general they build shorter paths, and an overhead with proactive protocols is independent of traffic profiles. If we use a mixed protocol, we may suffer both disadvanatges. So my point is that proactive protocols are good approaches for MANET routing, especially with a low mobility MANET. When the network mobility increases, (AND with certain traffic profiles), we should introduce some reactive features. We are looking into the performance (in term of overhead) of MANET routing protocols given several network and traffic profiles. Hopefully these results will be available soon. ----- Original Message ----- From: "Mullen, John P. (Contractor)" To: Sent: Wednesday, May 15, 2002 4:42 PM Subject: RE: [manet] Dumber Question? > Hi Richard, > > I'm not so sure this is a clear advantage, at least not in highly dynamic > MANETs. > > If link status changes rapidly, say every minute or so, a proactive protocol > would have to have nodes advertise about twice a minute in order to have > routing tables that are reasonably accurate. Because of the possibility of > data collisions, this will tie up the MANET, at least locally, for a sizable > chunk of the available time, leading to significantly less bandwidth > available for the transmission of data. > > Also, if the MANET is sizable, not only will there be more bandwidth lost to > advertisements, but the propagation the advertisements to all nodes in the > net will take a considerable amount of additional time. This may be long > enough that at no time do all nodes have an accurate picture of the network. > > Another complication arises in the case of asymmetric links. In this case, > the fact that Node A can hear B does not mean Node B can hear Node A. So, > if Node A receives an advertisement from Node B, it is not assurance that > Node B is reachable directly from Node A. Node A must respond to Node B's > advertisement, in which case both A and B will know they can reach each > other. This means we need about twice as many packets to establish the > proactive routing. > > Of course, both problems become worse rapidly with the size of the net, so > one might be able to have a proactive protocol locally (involving just a few > nodes), but a reactive protocol globally. > > John Mullen > -----Original Message----- > From: ogier@erg.sri.com [mailto:ogier@erg.sri.com] > Sent: Wednesday, May 15, 2002 12:16 PM > To: manet@ietf.org > Cc: ogier@erg.sri.com > Subject: Re: [manet] Dumber Question? > > > > > > Yes, proactive protocols have a lot of advantages over on-demand > protocols that have not been discussed much. > For example, if one node wants to send a message to another > node that is currently unreachable, an on-demand protocol will > try to discover a route a few times and then give up (and then perhaps > try periodically). If proactive routing is used, the sending node > will be informed as soon as the unreachable node becomes reachable. > > Another advantage of proactive protocols is that more efficient flooding > is possible at no extra cost, using the topology information provided > by the proactive protocol (e.g., parents in TBRPF or MPRs in OLSR.) > > Of course there are other advantages (e.g., proactive protocols are > more efficient when the number of sources is large, proactive protocols > can ensure that an alternate route is always maintained, etc.). > > Richard > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 18:32:56 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 SAA24220 for ; Wed, 15 May 2002 18:32:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06047; Wed, 15 May 2002 18:08:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06014 for ; Wed, 15 May 2002 18:08:29 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23756 for ; Wed, 15 May 2002 18:08:11 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117131>; Wed, 15 May 2002 16:08:19 -0600 Message-Id: <02May15.160819mdt.117131@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Tao Lin Cc: manet@ietf.org Subject: RE: [manet] Dumber Question? Date: Wed, 15 May 2002 16:08:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 Hello Lin, Perhaps, we are not discussing the same sorts of MANETs. In general, Node A does not know it is reachable from Node B until it receives a packet from Node B. Node B does not know that it can reach Node A until it receives an ACK from Node A, indicating that it received the packet from Node B. Whether the protocol is proactive or not, data collisions, etc. can cause the impression that a node is not reachable. If Node A's status changes from reachable to unreachable from Node B, it will not know, unless it is expecting a packet from Node B, that such a thing has happened. Node B, however, will know, since its packet was not ACKed, that either Node A did not get the packet or Node B could not hear Node A's reply. If Node A later becomes reachable, it will still not know until Node B sends it a packet. These control packets are as likely to suffer a data collision or be damaged by temporary interference as those of a reactive protocol, so I see no inherent advantage. The only difference I see in the protocols is their impact on overhead. This would include the re-transmission of packets directed onto obsolete paths, those lost in data collisions, and those lost in buffer overflows, as well as the packets needed to inform each node about the others. Since these would depend on the traffic load, network density, propagation conditions, and operational factors, it would seem that an adaptive hybrid protocol would be best. However, I would have to say that giving the protocol more degrees of freedom also introduces the problem of how to control those settings and admits the possibility of instability. John Mullen -----Original Message----- From: Tao Lin [mailto:taolin@vt.edu] Sent: Wednesday, May 15, 2002 3:45 PM To: Mullen, John P. (Contractor) Cc: manet@ietf.org Subject: Re: [manet] Dumber Question? I agree that proactive protocols may have higher overhead if a topology change does not affect a in-use route. We have to admit that this is a disadvantage for proactive protocols in MANET. However, proactive protocols have many advantages, e.g. they can respond to route changes faster, they provide immediate notification of reachable or unreachable destinations (reactive protocols can not decide whether the destination is unreachable or not because there could be packet collisions when broadcasting route requests or destination unreachable.), in general they build shorter paths, and an overhead with proactive protocols is independent of traffic profiles. If we use a mixed protocol, we may suffer both disadvanatges. So my point is that proactive protocols are good approaches for MANET routing, especially with a low mobility MANET. When the network mobility increases, (AND with certain traffic profiles), we should introduce some reactive features. We are looking into the performance (in term of overhead) of MANET routing protocols given several network and traffic profiles. Hopefully these results will be available soon. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 15 18:32:57 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 SAA24229 for ; Wed, 15 May 2002 18:32:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA07710 for manet-archive@odin.ietf.org; Wed, 15 May 2002 18:33:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06047; Wed, 15 May 2002 18:08:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06014 for ; Wed, 15 May 2002 18:08:29 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23756 for ; Wed, 15 May 2002 18:08:11 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117131>; Wed, 15 May 2002 16:08:19 -0600 Message-Id: <02May15.160819mdt.117131@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Tao Lin Cc: manet@ietf.org Subject: RE: [manet] Dumber Question? Date: Wed, 15 May 2002 16:08:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 Hello Lin, Perhaps, we are not discussing the same sorts of MANETs. In general, Node A does not know it is reachable from Node B until it receives a packet from Node B. Node B does not know that it can reach Node A until it receives an ACK from Node A, indicating that it received the packet from Node B. Whether the protocol is proactive or not, data collisions, etc. can cause the impression that a node is not reachable. If Node A's status changes from reachable to unreachable from Node B, it will not know, unless it is expecting a packet from Node B, that such a thing has happened. Node B, however, will know, since its packet was not ACKed, that either Node A did not get the packet or Node B could not hear Node A's reply. If Node A later becomes reachable, it will still not know until Node B sends it a packet. These control packets are as likely to suffer a data collision or be damaged by temporary interference as those of a reactive protocol, so I see no inherent advantage. The only difference I see in the protocols is their impact on overhead. This would include the re-transmission of packets directed onto obsolete paths, those lost in data collisions, and those lost in buffer overflows, as well as the packets needed to inform each node about the others. Since these would depend on the traffic load, network density, propagation conditions, and operational factors, it would seem that an adaptive hybrid protocol would be best. However, I would have to say that giving the protocol more degrees of freedom also introduces the problem of how to control those settings and admits the possibility of instability. John Mullen -----Original Message----- From: Tao Lin [mailto:taolin@vt.edu] Sent: Wednesday, May 15, 2002 3:45 PM To: Mullen, John P. (Contractor) Cc: manet@ietf.org Subject: Re: [manet] Dumber Question? I agree that proactive protocols may have higher overhead if a topology change does not affect a in-use route. We have to admit that this is a disadvantage for proactive protocols in MANET. However, proactive protocols have many advantages, e.g. they can respond to route changes faster, they provide immediate notification of reachable or unreachable destinations (reactive protocols can not decide whether the destination is unreachable or not because there could be packet collisions when broadcasting route requests or destination unreachable.), in general they build shorter paths, and an overhead with proactive protocols is independent of traffic profiles. If we use a mixed protocol, we may suffer both disadvanatges. So my point is that proactive protocols are good approaches for MANET routing, especially with a low mobility MANET. When the network mobility increases, (AND with certain traffic profiles), we should introduce some reactive features. We are looking into the performance (in term of overhead) of MANET routing protocols given several network and traffic profiles. Hopefully these results will be available soon. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 15 18:57:28 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 SAA23703 for ; Wed, 15 May 2002 18:04:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA05965 for manet-archive@odin.ietf.org; Wed, 15 May 2002 18:05:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04432; Wed, 15 May 2002 17:45:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04401 for ; Wed, 15 May 2002 17:45:10 -0400 (EDT) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23223 for ; Wed, 15 May 2002 17:44:52 -0400 (EDT) Received: from dagger.cc.vt.edu (IDENT:mirapoint@dagger-lb.cc.vt.edu [10.1.1.11]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id g4FLj6e294034; Wed, 15 May 2002 17:45:06 -0400 (EDT) Received: from TNT (h80ad3776.dhcp.vt.edu [128.173.55.118]) by dagger.cc.vt.edu (Mirapoint Messaging Server MOS 3.1.0.54-GA) with SMTP id AKP17565; Wed, 15 May 2002 17:28:42 -0400 (EDT) Message-ID: <009e01c1fc59$ba65b0c0$7637ad80@workgroup> From: "Tao Lin" To: "Mullen, John P. \(Contractor\)" Cc: References: <02May15.144300mdt.117129@gw.trac.wsmr.army.mil> Subject: Re: [manet] Dumber Question? Date: Wed, 15 May 2002 17:44:44 -0400 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 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit I agree that proactive protocols may have higher overhead if a topology change does not affect a in-use route. We have to admit that this is a disadvantage for proactive protocols in MANET. However, proactive protocols have many advantages, e.g. they can respond to route changes faster, they provide immediate notification of reachable or unreachable destinations (reactive protocols can not decide whether the destination is unreachable or not because there could be packet collisions when broadcasting route requests or destination unreachable.), in general they build shorter paths, and an overhead with proactive protocols is independent of traffic profiles. If we use a mixed protocol, we may suffer both disadvanatges. So my point is that proactive protocols are good approaches for MANET routing, especially with a low mobility MANET. When the network mobility increases, (AND with certain traffic profiles), we should introduce some reactive features. We are looking into the performance (in term of overhead) of MANET routing protocols given several network and traffic profiles. Hopefully these results will be available soon. ----- Original Message ----- From: "Mullen, John P. (Contractor)" To: Sent: Wednesday, May 15, 2002 4:42 PM Subject: RE: [manet] Dumber Question? > Hi Richard, > > I'm not so sure this is a clear advantage, at least not in highly dynamic > MANETs. > > If link status changes rapidly, say every minute or so, a proactive protocol > would have to have nodes advertise about twice a minute in order to have > routing tables that are reasonably accurate. Because of the possibility of > data collisions, this will tie up the MANET, at least locally, for a sizable > chunk of the available time, leading to significantly less bandwidth > available for the transmission of data. > > Also, if the MANET is sizable, not only will there be more bandwidth lost to > advertisements, but the propagation the advertisements to all nodes in the > net will take a considerable amount of additional time. This may be long > enough that at no time do all nodes have an accurate picture of the network. > > Another complication arises in the case of asymmetric links. In this case, > the fact that Node A can hear B does not mean Node B can hear Node A. So, > if Node A receives an advertisement from Node B, it is not assurance that > Node B is reachable directly from Node A. Node A must respond to Node B's > advertisement, in which case both A and B will know they can reach each > other. This means we need about twice as many packets to establish the > proactive routing. > > Of course, both problems become worse rapidly with the size of the net, so > one might be able to have a proactive protocol locally (involving just a few > nodes), but a reactive protocol globally. > > John Mullen > -----Original Message----- > From: ogier@erg.sri.com [mailto:ogier@erg.sri.com] > Sent: Wednesday, May 15, 2002 12:16 PM > To: manet@ietf.org > Cc: ogier@erg.sri.com > Subject: Re: [manet] Dumber Question? > > > > > > Yes, proactive protocols have a lot of advantages over on-demand > protocols that have not been discussed much. > For example, if one node wants to send a message to another > node that is currently unreachable, an on-demand protocol will > try to discover a route a few times and then give up (and then perhaps > try periodically). If proactive routing is used, the sending node > will be informed as soon as the unreachable node becomes reachable. > > Another advantage of proactive protocols is that more efficient flooding > is possible at no extra cost, using the topology information provided > by the proactive protocol (e.g., parents in TBRPF or MPRs in OLSR.) > > Of course there are other advantages (e.g., proactive protocols are > more efficient when the number of sources is large, proactive protocols > can ensure that an alternate route is always maintained, etc.). > > Richard > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 15 23:58:04 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 XAA03145 for ; Wed, 15 May 2002 23:58:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27870; Wed, 15 May 2002 23:32:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27814 for ; Wed, 15 May 2002 23:32:47 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02502; Wed, 15 May 2002 23:32:30 -0400 (EDT) Received: from FRED-W2K6.cisco.com (sjc-vpn3-161.cisco.com [10.21.64.161]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4G3VuPJ015082; Wed, 15 May 2002 20:32:01 -0700 (PDT) Message-Id: <5.1.0.14.2.20020515103000.04c9fd98@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 May 2002 10:31:07 -0700 To: Marwaha Shivanajay From: Fred Baker Subject: RE: [manet] Dumber Question? Cc: "'manet@ietf.org'" , "'oldham@grc.nasa.gov'" , rpsec@ietf.org In-Reply-To: <6330DC96389A924A804F52FA3848930E703C57@MBXSRV26.stu.nus.ed u.sg> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 At 09:17 PM 5/15/2002 +0800, Marwaha Shivanajay wrote: >Assignment of IP adresses is done using "autoconfiguration" in ad hoc >networks. ahem; one mechanism for address assignment is autoconfiguration. Never tell your customer that he's not allowed to type it in :^) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed May 15 23:58:05 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 XAA03156 for ; Wed, 15 May 2002 23:58:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA28970 for manet-archive@odin.ietf.org; Wed, 15 May 2002 23:58:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27870; Wed, 15 May 2002 23:32:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27814 for ; Wed, 15 May 2002 23:32:47 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02502; Wed, 15 May 2002 23:32:30 -0400 (EDT) Received: from FRED-W2K6.cisco.com (sjc-vpn3-161.cisco.com [10.21.64.161]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4G3VuPJ015082; Wed, 15 May 2002 20:32:01 -0700 (PDT) Message-Id: <5.1.0.14.2.20020515103000.04c9fd98@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 May 2002 10:31:07 -0700 To: Marwaha Shivanajay From: Fred Baker Subject: RE: [manet] Dumber Question? Cc: "'manet@ietf.org'" , "'oldham@grc.nasa.gov'" , rpsec@ietf.org In-Reply-To: <6330DC96389A924A804F52FA3848930E703C57@MBXSRV26.stu.nus.ed u.sg> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 At 09:17 PM 5/15/2002 +0800, Marwaha Shivanajay wrote: >Assignment of IP adresses is done using "autoconfiguration" in ad hoc >networks. ahem; one mechanism for address assignment is autoconfiguration. Never tell your customer that he's not allowed to type it in :^) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 16 11:00:50 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 LAA27245 for ; Thu, 16 May 2002 11:00:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15281; Thu, 16 May 2002 10:23:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15189 for ; Thu, 16 May 2002 10:23:53 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25871 for ; Thu, 16 May 2002 10:23:35 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117134>; Thu, 16 May 2002 08:23:41 -0600 Message-Id: <02May16.082341mdt.117134@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Mike Christman Cc: manet@ietf.org Subject: RE: [manet] Dumber Question? Date: Thu, 16 May 2002 08:23:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 Hi Mike, By "packet," I meant any packet, data or control. All I know about OLSR is what I've read at: http://menetou.inria.fr/olsr/draft-ietf-manet-olsr-04.txt >From that, I gather that the primary advantage of OLSR is that it reduces the number of nodes retransmitting packets to a subset, called Multipoint Relays. In a sense, the protocol defines a subset of nodes to be routers according to the conditions in effect. This is, of course, most useful when the net is both large and dense. At times, this is true of the nets I work with, so this could be a useful strategy. The problem is that since the links are not symmetric, it is often true that Node A receiving a HELLO from Node B does not mean Node B can receive a packet from Node A. If the HELLO message does not contain A's address, Node A knows that it can receive packets from B, but it is probable that it cannot send packets directly to B. It can send B's address in its own HELLO, but, as I read the protocol, unless B is a two-hop neighbor, Node B will never know that Node A can receive its packets. Of course, this would also be a problem for a reactive protocol. The point is that one may more HELLO packets per unit time to maintain the routing tables in the presence of asymmetric links than with symmetric ones. If the bandwidth is limited, this can lead to very high overhead. In general, the nets I work with are uneven in density. For example, if a company is attempting to cross a minefield using a cleared path, its units will be near each other and the net will be locally dense. However, if the same company is involved in scouting, the net is liable to be sparse. The OLSR might be advantageous in the first case, but in the second, the added overhead, together with the reduced link capacity (capacity is a decreasing function of the distance between nodes), might make it a liability. An adaptive protocol could switch to OLSR when and where the net is dense and switch to a different protocol when and where it is not. John Mullen -----Original Message----- From: Mike Christman [mailto:mchristm@vt.edu] Sent: Wednesday, May 15, 2002 5:47 PM To: Mullen, John P. (Contractor) Cc: Tao Lin; manet@ietf.org Subject: RE: [manet] Dumber Question? Mr. Mullen, Perhaps I am not understanding your point of view here or I have not read the earlier threads closely enough. It would seem like a proactive algorithm, like OLSR, would not have the problem that you described. When you say that "Node A does not know it is reachable from Node B until it receives a packet from Node B." I assume that you mean a data packet. However, it would seem as if using periodic "hello" messages, as OLSR does, would avoid this problem. If a collisions can prevent "hello" messages from being received, but I believe that OLSR allows for 3 missed messages before timing out. In this case Nodes A and B are ALWAYS expecting a packet from other nodes. But, as we all know by know, this consumes more bandwidth. I hope that this comment is relevant! :) On Wed, 15 May 2002, Mullen, John P. (Contractor) wrote: > Hello Lin, > > Perhaps, we are not discussing the same sorts of MANETs. > > In general, Node A does not know it is reachable from Node B until it > receives a packet from Node B. Node B does not know that it can reach Node > A until it receives an ACK from Node A, indicating that it received the > packet from Node B. Whether the protocol is proactive or not, data > collisions, etc. can cause the impression that a node is not reachable. > > If Node A's status changes from reachable to unreachable from Node B, it > will not know, unless it is expecting a packet from Node B, that such a > thing has happened. Node B, however, will know, since its packet was not > ACKed, that either Node A did not get the packet or Node B could not hear > Node A's reply. > > If Node A later becomes reachable, it will still not know until Node B sends > it a packet. These control packets are as likely to suffer a data collision > or be damaged by temporary interference as those of a reactive protocol, so > I see no inherent advantage. > > > The only difference I see in the protocols is their impact on overhead. > This would include the re-transmission of packets directed onto obsolete > paths, those lost in data collisions, and those lost in buffer overflows, as > well as the packets needed to inform each node about the others. Since > these would depend on the traffic load, network density, propagation > conditions, and operational factors, it would seem that an adaptive hybrid > protocol would be best. > > However, I would have to say that giving the protocol more degrees of > freedom also introduces the problem of how to control those settings and > admits the possibility of instability. > > John Mullen > > -----Original Message----- > From: Tao Lin [mailto:taolin@vt.edu] > Sent: Wednesday, May 15, 2002 3:45 PM > To: Mullen, John P. (Contractor) > Cc: manet@ietf.org > Subject: Re: [manet] Dumber Question? > > > I agree that proactive protocols may have higher overhead if a topology > change does not affect a in-use route. We have to admit that this is a > disadvantage for proactive protocols in MANET. However, proactive protocols > have many advantages, e.g. they can respond to route changes faster, they > provide immediate notification of reachable or unreachable destinations > (reactive protocols can not decide whether the destination is unreachable or > not because there could be packet collisions when broadcasting route > requests or destination unreachable.), in general they build shorter paths, > and an overhead with proactive protocols is independent of traffic profiles. > If we use a mixed protocol, we may suffer both disadvanatges. So my point is > that proactive protocols are good approaches for MANET routing, especially > with a low mobility MANET. When the network mobility increases, (AND with > certain traffic profiles), we should introduce some reactive features. We > are looking into the performance (in term of overhead) of MANET routing > protocols given several network and traffic profiles. Hopefully these > results will be available soon. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu May 16 11:00:51 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 LAA27254 for ; Thu, 16 May 2002 11:00:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18454 for manet-archive@odin.ietf.org; Thu, 16 May 2002 11:01:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15281; Thu, 16 May 2002 10:23:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15189 for ; Thu, 16 May 2002 10:23:53 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25871 for ; Thu, 16 May 2002 10:23:35 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117134>; Thu, 16 May 2002 08:23:41 -0600 Message-Id: <02May16.082341mdt.117134@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Mike Christman Cc: manet@ietf.org Subject: RE: [manet] Dumber Question? Date: Thu, 16 May 2002 08:23:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 Hi Mike, By "packet," I meant any packet, data or control. All I know about OLSR is what I've read at: http://menetou.inria.fr/olsr/draft-ietf-manet-olsr-04.txt >From that, I gather that the primary advantage of OLSR is that it reduces the number of nodes retransmitting packets to a subset, called Multipoint Relays. In a sense, the protocol defines a subset of nodes to be routers according to the conditions in effect. This is, of course, most useful when the net is both large and dense. At times, this is true of the nets I work with, so this could be a useful strategy. The problem is that since the links are not symmetric, it is often true that Node A receiving a HELLO from Node B does not mean Node B can receive a packet from Node A. If the HELLO message does not contain A's address, Node A knows that it can receive packets from B, but it is probable that it cannot send packets directly to B. It can send B's address in its own HELLO, but, as I read the protocol, unless B is a two-hop neighbor, Node B will never know that Node A can receive its packets. Of course, this would also be a problem for a reactive protocol. The point is that one may more HELLO packets per unit time to maintain the routing tables in the presence of asymmetric links than with symmetric ones. If the bandwidth is limited, this can lead to very high overhead. In general, the nets I work with are uneven in density. For example, if a company is attempting to cross a minefield using a cleared path, its units will be near each other and the net will be locally dense. However, if the same company is involved in scouting, the net is liable to be sparse. The OLSR might be advantageous in the first case, but in the second, the added overhead, together with the reduced link capacity (capacity is a decreasing function of the distance between nodes), might make it a liability. An adaptive protocol could switch to OLSR when and where the net is dense and switch to a different protocol when and where it is not. John Mullen -----Original Message----- From: Mike Christman [mailto:mchristm@vt.edu] Sent: Wednesday, May 15, 2002 5:47 PM To: Mullen, John P. (Contractor) Cc: Tao Lin; manet@ietf.org Subject: RE: [manet] Dumber Question? Mr. Mullen, Perhaps I am not understanding your point of view here or I have not read the earlier threads closely enough. It would seem like a proactive algorithm, like OLSR, would not have the problem that you described. When you say that "Node A does not know it is reachable from Node B until it receives a packet from Node B." I assume that you mean a data packet. However, it would seem as if using periodic "hello" messages, as OLSR does, would avoid this problem. If a collisions can prevent "hello" messages from being received, but I believe that OLSR allows for 3 missed messages before timing out. In this case Nodes A and B are ALWAYS expecting a packet from other nodes. But, as we all know by know, this consumes more bandwidth. I hope that this comment is relevant! :) On Wed, 15 May 2002, Mullen, John P. (Contractor) wrote: > Hello Lin, > > Perhaps, we are not discussing the same sorts of MANETs. > > In general, Node A does not know it is reachable from Node B until it > receives a packet from Node B. Node B does not know that it can reach Node > A until it receives an ACK from Node A, indicating that it received the > packet from Node B. Whether the protocol is proactive or not, data > collisions, etc. can cause the impression that a node is not reachable. > > If Node A's status changes from reachable to unreachable from Node B, it > will not know, unless it is expecting a packet from Node B, that such a > thing has happened. Node B, however, will know, since its packet was not > ACKed, that either Node A did not get the packet or Node B could not hear > Node A's reply. > > If Node A later becomes reachable, it will still not know until Node B sends > it a packet. These control packets are as likely to suffer a data collision > or be damaged by temporary interference as those of a reactive protocol, so > I see no inherent advantage. > > > The only difference I see in the protocols is their impact on overhead. > This would include the re-transmission of packets directed onto obsolete > paths, those lost in data collisions, and those lost in buffer overflows, as > well as the packets needed to inform each node about the others. Since > these would depend on the traffic load, network density, propagation > conditions, and operational factors, it would seem that an adaptive hybrid > protocol would be best. > > However, I would have to say that giving the protocol more degrees of > freedom also introduces the problem of how to control those settings and > admits the possibility of instability. > > John Mullen > > -----Original Message----- > From: Tao Lin [mailto:taolin@vt.edu] > Sent: Wednesday, May 15, 2002 3:45 PM > To: Mullen, John P. (Contractor) > Cc: manet@ietf.org > Subject: Re: [manet] Dumber Question? > > > I agree that proactive protocols may have higher overhead if a topology > change does not affect a in-use route. We have to admit that this is a > disadvantage for proactive protocols in MANET. However, proactive protocols > have many advantages, e.g. they can respond to route changes faster, they > provide immediate notification of reachable or unreachable destinations > (reactive protocols can not decide whether the destination is unreachable or > not because there could be packet collisions when broadcasting route > requests or destination unreachable.), in general they build shorter paths, > and an overhead with proactive protocols is independent of traffic profiles. > If we use a mixed protocol, we may suffer both disadvanatges. So my point is > that proactive protocols are good approaches for MANET routing, especially > with a low mobility MANET. When the network mobility increases, (AND with > certain traffic profiles), we should introduce some reactive features. We > are looking into the performance (in term of overhead) of MANET routing > protocols given several network and traffic profiles. Hopefully these > results will be available soon. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 16 13:06:05 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 NAA02422 for ; Thu, 16 May 2002 13:06:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26928; Thu, 16 May 2002 12:45:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10538 for ; Wed, 15 May 2002 19:47:26 -0400 (EDT) Received: from io.irean.vt.edu (io.irean.vt.edu [128.173.52.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25662 for ; Wed, 15 May 2002 19:47:12 -0400 (EDT) Received: from localhost (mchristm@localhost) by io.irean.vt.edu (8.11.6/8.11.6) with ESMTP id g4FNlNv24604; Wed, 15 May 2002 19:47:23 -0400 X-Authentication-Warning: io.irean.vt.edu: mchristm owned process doing -bs Date: Wed, 15 May 2002 19:47:23 -0400 (EDT) From: Mike Christman X-X-Sender: mchristm@io.irean.vt.edu To: "Mullen, John P. (Contractor)" cc: Tao Lin , Subject: RE: [manet] Dumber Question? In-Reply-To: <02May15.160819mdt.117131@gw.trac.wsmr.army.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Mr. Mullen, Perhaps I am not understanding your point of view here or I have not read the earlier threads closely enough. It would seem like a proactive algorithm, like OLSR, would not have the problem that you described. When you say that "Node A does not know it is reachable from Node B until it receives a packet from Node B." I assume that you mean a data packet. However, it would seem as if using periodic "hello" messages, as OLSR does, would avoid this problem. If a collisions can prevent "hello" messages from being received, but I believe that OLSR allows for 3 missed messages before timing out. In this case Nodes A and B are ALWAYS expecting a packet from other nodes. But, as we all know by know, this consumes more bandwidth. I hope that this comment is relevant! :) On Wed, 15 May 2002, Mullen, John P. (Contractor) wrote: > Hello Lin, > > Perhaps, we are not discussing the same sorts of MANETs. > > In general, Node A does not know it is reachable from Node B until it > receives a packet from Node B. Node B does not know that it can reach Node > A until it receives an ACK from Node A, indicating that it received the > packet from Node B. Whether the protocol is proactive or not, data > collisions, etc. can cause the impression that a node is not reachable. > > If Node A's status changes from reachable to unreachable from Node B, it > will not know, unless it is expecting a packet from Node B, that such a > thing has happened. Node B, however, will know, since its packet was not > ACKed, that either Node A did not get the packet or Node B could not hear > Node A's reply. > > If Node A later becomes reachable, it will still not know until Node B sends > it a packet. These control packets are as likely to suffer a data collision > or be damaged by temporary interference as those of a reactive protocol, so > I see no inherent advantage. > > > The only difference I see in the protocols is their impact on overhead. > This would include the re-transmission of packets directed onto obsolete > paths, those lost in data collisions, and those lost in buffer overflows, as > well as the packets needed to inform each node about the others. Since > these would depend on the traffic load, network density, propagation > conditions, and operational factors, it would seem that an adaptive hybrid > protocol would be best. > > However, I would have to say that giving the protocol more degrees of > freedom also introduces the problem of how to control those settings and > admits the possibility of instability. > > John Mullen > > -----Original Message----- > From: Tao Lin [mailto:taolin@vt.edu] > Sent: Wednesday, May 15, 2002 3:45 PM > To: Mullen, John P. (Contractor) > Cc: manet@ietf.org > Subject: Re: [manet] Dumber Question? > > > I agree that proactive protocols may have higher overhead if a topology > change does not affect a in-use route. We have to admit that this is a > disadvantage for proactive protocols in MANET. However, proactive protocols > have many advantages, e.g. they can respond to route changes faster, they > provide immediate notification of reachable or unreachable destinations > (reactive protocols can not decide whether the destination is unreachable or > not because there could be packet collisions when broadcasting route > requests or destination unreachable.), in general they build shorter paths, > and an overhead with proactive protocols is independent of traffic profiles. > If we use a mixed protocol, we may suffer both disadvanatges. So my point is > that proactive protocols are good approaches for MANET routing, especially > with a low mobility MANET. When the network mobility increases, (AND with > certain traffic profiles), we should introduce some reactive features. We > are looking into the performance (in term of overhead) of MANET routing > protocols given several network and traffic profiles. Hopefully these > results will be available soon. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu May 16 13:06:06 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 NAA02432 for ; Thu, 16 May 2002 13:06:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29252 for manet-archive@odin.ietf.org; Thu, 16 May 2002 13:06:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26928; Thu, 16 May 2002 12:45:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10538 for ; Wed, 15 May 2002 19:47:26 -0400 (EDT) Received: from io.irean.vt.edu (io.irean.vt.edu [128.173.52.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25662 for ; Wed, 15 May 2002 19:47:12 -0400 (EDT) Received: from localhost (mchristm@localhost) by io.irean.vt.edu (8.11.6/8.11.6) with ESMTP id g4FNlNv24604; Wed, 15 May 2002 19:47:23 -0400 X-Authentication-Warning: io.irean.vt.edu: mchristm owned process doing -bs Date: Wed, 15 May 2002 19:47:23 -0400 (EDT) From: Mike Christman X-X-Sender: mchristm@io.irean.vt.edu To: "Mullen, John P. (Contractor)" cc: Tao Lin , Subject: RE: [manet] Dumber Question? In-Reply-To: <02May15.160819mdt.117131@gw.trac.wsmr.army.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Mr. Mullen, Perhaps I am not understanding your point of view here or I have not read the earlier threads closely enough. It would seem like a proactive algorithm, like OLSR, would not have the problem that you described. When you say that "Node A does not know it is reachable from Node B until it receives a packet from Node B." I assume that you mean a data packet. However, it would seem as if using periodic "hello" messages, as OLSR does, would avoid this problem. If a collisions can prevent "hello" messages from being received, but I believe that OLSR allows for 3 missed messages before timing out. In this case Nodes A and B are ALWAYS expecting a packet from other nodes. But, as we all know by know, this consumes more bandwidth. I hope that this comment is relevant! :) On Wed, 15 May 2002, Mullen, John P. (Contractor) wrote: > Hello Lin, > > Perhaps, we are not discussing the same sorts of MANETs. > > In general, Node A does not know it is reachable from Node B until it > receives a packet from Node B. Node B does not know that it can reach Node > A until it receives an ACK from Node A, indicating that it received the > packet from Node B. Whether the protocol is proactive or not, data > collisions, etc. can cause the impression that a node is not reachable. > > If Node A's status changes from reachable to unreachable from Node B, it > will not know, unless it is expecting a packet from Node B, that such a > thing has happened. Node B, however, will know, since its packet was not > ACKed, that either Node A did not get the packet or Node B could not hear > Node A's reply. > > If Node A later becomes reachable, it will still not know until Node B sends > it a packet. These control packets are as likely to suffer a data collision > or be damaged by temporary interference as those of a reactive protocol, so > I see no inherent advantage. > > > The only difference I see in the protocols is their impact on overhead. > This would include the re-transmission of packets directed onto obsolete > paths, those lost in data collisions, and those lost in buffer overflows, as > well as the packets needed to inform each node about the others. Since > these would depend on the traffic load, network density, propagation > conditions, and operational factors, it would seem that an adaptive hybrid > protocol would be best. > > However, I would have to say that giving the protocol more degrees of > freedom also introduces the problem of how to control those settings and > admits the possibility of instability. > > John Mullen > > -----Original Message----- > From: Tao Lin [mailto:taolin@vt.edu] > Sent: Wednesday, May 15, 2002 3:45 PM > To: Mullen, John P. (Contractor) > Cc: manet@ietf.org > Subject: Re: [manet] Dumber Question? > > > I agree that proactive protocols may have higher overhead if a topology > change does not affect a in-use route. We have to admit that this is a > disadvantage for proactive protocols in MANET. However, proactive protocols > have many advantages, e.g. they can respond to route changes faster, they > provide immediate notification of reachable or unreachable destinations > (reactive protocols can not decide whether the destination is unreachable or > not because there could be packet collisions when broadcasting route > requests or destination unreachable.), in general they build shorter paths, > and an overhead with proactive protocols is independent of traffic profiles. > If we use a mixed protocol, we may suffer both disadvanatges. So my point is > that proactive protocols are good approaches for MANET routing, especially > with a low mobility MANET. When the network mobility increases, (AND with > certain traffic profiles), we should introduce some reactive features. We > are looking into the performance (in term of overhead) of MANET routing > protocols given several network and traffic profiles. Hopefully these > results will be available soon. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 16 13:11:53 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 NAA02589 for ; Thu, 16 May 2002 13:11:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26880; Thu, 16 May 2002 12:44:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04955 for ; Wed, 15 May 2002 11:57:26 -0400 (EDT) Received: from amber.crhc.uiuc.edu (amber.crhc.uiuc.edu [130.126.143.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10815 for ; Wed, 15 May 2002 11:57:10 -0400 (EDT) Received: from nhv (dhcp67.crhc.uiuc.edu [130.126.140.67]) by amber.crhc.uiuc.edu (8.9.3/8.9.3) with SMTP id KAA04919; Wed, 15 May 2002 10:57:22 -0500 (CDT) From: "Nitin Vaidya" To: "Charlie Perkins" Cc: Subject: RE: [manet] Dumber Question? Date: Wed, 15 May 2002 11:01:13 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <3CE27186.8AA51649@iprg.nokia.com> Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit >>From: manet-admin@ietf.org [mailto:manet-admin@ietf.org]On Behalf Of >>Charlie Perkins >>> What happens if there are duplicate IP addresses in an ad-hoc network? >> >>Lose, lose. Are you sure? What if the packets reach their intended destinations despite address duplication? In that case, duplicate addresses may not be so bad. See www.crhc.uiuc.edu/~nhv/publications.html for a MobiHoc 2002 paper based on this theme. The above paper essentially uses IP address as "labels" which are used for routing, and some other unique string as "key" which is used to set up routes. The "key" can be made unique with adequately low probability simply by choosing a sufficiently long string of bits randomly. IP address duplicate is detected when two different "keys" are assigned the same label (i.e., same IP address). (By the way, the paper does not describe the scheme this way, since I did not see the analogy with labels until recently.) Trivial idea, but can use some improvements (as elaborated in the paper). - nitin _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu May 16 13:11:54 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 NAA02597 for ; Thu, 16 May 2002 13:11:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29572 for manet-archive@odin.ietf.org; Thu, 16 May 2002 13:12:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26880; Thu, 16 May 2002 12:44:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04955 for ; Wed, 15 May 2002 11:57:26 -0400 (EDT) Received: from amber.crhc.uiuc.edu (amber.crhc.uiuc.edu [130.126.143.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10815 for ; Wed, 15 May 2002 11:57:10 -0400 (EDT) Received: from nhv (dhcp67.crhc.uiuc.edu [130.126.140.67]) by amber.crhc.uiuc.edu (8.9.3/8.9.3) with SMTP id KAA04919; Wed, 15 May 2002 10:57:22 -0500 (CDT) From: "Nitin Vaidya" To: "Charlie Perkins" Cc: Subject: RE: [manet] Dumber Question? Date: Wed, 15 May 2002 11:01:13 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <3CE27186.8AA51649@iprg.nokia.com> Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit >>From: manet-admin@ietf.org [mailto:manet-admin@ietf.org]On Behalf Of >>Charlie Perkins >>> What happens if there are duplicate IP addresses in an ad-hoc network? >> >>Lose, lose. Are you sure? What if the packets reach their intended destinations despite address duplication? In that case, duplicate addresses may not be so bad. See www.crhc.uiuc.edu/~nhv/publications.html for a MobiHoc 2002 paper based on this theme. The above paper essentially uses IP address as "labels" which are used for routing, and some other unique string as "key" which is used to set up routes. The "key" can be made unique with adequately low probability simply by choosing a sufficiently long string of bits randomly. IP address duplicate is detected when two different "keys" are assigned the same label (i.e., same IP address). (By the way, the paper does not describe the scheme this way, since I did not see the analogy with labels until recently.) Trivial idea, but can use some improvements (as elaborated in the paper). - nitin _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 16 13:12:13 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 NAA02627 for ; Thu, 16 May 2002 13:12:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26830; Thu, 16 May 2002 12:43:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21138 for ; Tue, 14 May 2002 23:31:03 -0400 (EDT) Received: from ponyexpress.ee.columbia.edu (ponyexpress.ee.columbia.edu [128.59.64.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20823 for ; Tue, 14 May 2002 23:30:47 -0400 (EDT) Received: from comet.columbia.edu (bongo.comet.columbia.edu [128.59.64.210]) by ponyexpress.ee.columbia.edu (8.12.1/8.12.1) with ESMTP id g4F3V0OY032594; Tue, 14 May 2002 23:31:00 -0400 Received: from localhost (sbl@localhost) by comet.columbia.edu (8.8.7/8.8.7/COMET) with SMTP id XAA09851; Tue, 14 May 2002 23:31:00 -0400 (EDT) X-Authentication-Warning: bongo.ctr.columbia.edu: sbl owned process doing -bs Date: Tue, 14 May 2002 23:29:58 -0400 (EDT) From: Seoung-Bum Lee To: Liangping Ma cc: manet@ietf.org, sbl@comet.columbia.edu Subject: Re: [manet] Questions about INSIGNIA In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hello, First of all, glad to hear that INSIGNIA is being implemented in Glomosim. Well, the MAX and MIN requirements of INSIGNIA should be specified by the application. INSIGNIA uses three service levels, namely [1] best effort, [2] minimum and [3] maximum service. All published simulation works of INSIGNIA used three levels of services but the number of service levels can be more than three (any number of service levels can be set). In fact, in the released NS2 implementation of INSIGNIA, the number of service levels is N (N+1 including best effort service). The N service levels are; (This is merely an example that is included in the package. You are free to introduce more sophisticated ones.) - best effort : all packets are BE - service level 1 : min packets are RES, rests are BE - service level 2 : min + (max - min) / N are RES, rests are BE - service level 3 : min + 2 * (max - min) / N are RES, rests are BE - service level 4 : min + 3 * (max - min) / N are RES, rests are BE ... - service level N : all packets are RES (RES packets have priority over BE packet.) As for your other question about the definition of BQ and BE; - BQ/EQ is payload type - RES/BE is service mode For detailed information and definition of INSIGNIA, please refer to; "INSIGNIA: An IP-Based Quality of Service Framework for Mobile Ad Hoc Networks", Journal of Parallel and Distributed Computing(Academic Press), Special issue on Wireless and Mobile Computing and Communications, Vol. 60 No. 4 pg. 374-406, April 2000". You can also download the paper from "comet.columbia.edu/insignia" Thank you. On Tue, 14 May 2002, Liangping Ma wrote: > Hello, everyone, > > I am implementing INSIGNIA in Glomosim and have several questions to > ask. First, at what layer the MAX and MIN bandwidth requirement should be > specified. Second, how many services are available in INSIGNIA? What is > the difference between BQ and BE? It seems to me packets can be > delivered as best effort, and reserved, which inturn includes BQ and EQ. > > Thanks! > > Sincerely yours, > Liangping Ma > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > Best Regards, ----------------------------------------------------- Seoung-Bum Lee COMET Group, Columbia University e-mail : sbl@comet.columbia.edu http://www.comet.columbia.edu/~sbl * Push your limits! ----------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu May 16 13:12:19 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 NAA02636 for ; Thu, 16 May 2002 13:12:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29588 for manet-archive@odin.ietf.org; Thu, 16 May 2002 13:12:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26830; Thu, 16 May 2002 12:43:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21138 for ; Tue, 14 May 2002 23:31:03 -0400 (EDT) Received: from ponyexpress.ee.columbia.edu (ponyexpress.ee.columbia.edu [128.59.64.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20823 for ; Tue, 14 May 2002 23:30:47 -0400 (EDT) Received: from comet.columbia.edu (bongo.comet.columbia.edu [128.59.64.210]) by ponyexpress.ee.columbia.edu (8.12.1/8.12.1) with ESMTP id g4F3V0OY032594; Tue, 14 May 2002 23:31:00 -0400 Received: from localhost (sbl@localhost) by comet.columbia.edu (8.8.7/8.8.7/COMET) with SMTP id XAA09851; Tue, 14 May 2002 23:31:00 -0400 (EDT) X-Authentication-Warning: bongo.ctr.columbia.edu: sbl owned process doing -bs Date: Tue, 14 May 2002 23:29:58 -0400 (EDT) From: Seoung-Bum Lee To: Liangping Ma cc: manet@ietf.org, sbl@comet.columbia.edu Subject: Re: [manet] Questions about INSIGNIA In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hello, First of all, glad to hear that INSIGNIA is being implemented in Glomosim. Well, the MAX and MIN requirements of INSIGNIA should be specified by the application. INSIGNIA uses three service levels, namely [1] best effort, [2] minimum and [3] maximum service. All published simulation works of INSIGNIA used three levels of services but the number of service levels can be more than three (any number of service levels can be set). In fact, in the released NS2 implementation of INSIGNIA, the number of service levels is N (N+1 including best effort service). The N service levels are; (This is merely an example that is included in the package. You are free to introduce more sophisticated ones.) - best effort : all packets are BE - service level 1 : min packets are RES, rests are BE - service level 2 : min + (max - min) / N are RES, rests are BE - service level 3 : min + 2 * (max - min) / N are RES, rests are BE - service level 4 : min + 3 * (max - min) / N are RES, rests are BE ... - service level N : all packets are RES (RES packets have priority over BE packet.) As for your other question about the definition of BQ and BE; - BQ/EQ is payload type - RES/BE is service mode For detailed information and definition of INSIGNIA, please refer to; "INSIGNIA: An IP-Based Quality of Service Framework for Mobile Ad Hoc Networks", Journal of Parallel and Distributed Computing(Academic Press), Special issue on Wireless and Mobile Computing and Communications, Vol. 60 No. 4 pg. 374-406, April 2000". You can also download the paper from "comet.columbia.edu/insignia" Thank you. On Tue, 14 May 2002, Liangping Ma wrote: > Hello, everyone, > > I am implementing INSIGNIA in Glomosim and have several questions to > ask. First, at what layer the MAX and MIN bandwidth requirement should be > specified. Second, how many services are available in INSIGNIA? What is > the difference between BQ and BE? It seems to me packets can be > delivered as best effort, and reserved, which inturn includes BQ and EQ. > > Thanks! > > Sincerely yours, > Liangping Ma > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > Best Regards, ----------------------------------------------------- Seoung-Bum Lee COMET Group, Columbia University e-mail : sbl@comet.columbia.edu http://www.comet.columbia.edu/~sbl * Push your limits! ----------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 16 14:40:46 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 OAA05804 for ; Thu, 16 May 2002 14:40:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03976; Thu, 16 May 2002 14:13:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03947 for ; Thu, 16 May 2002 14:13:55 -0400 (EDT) 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 OAA04765 for ; Thu, 16 May 2002 14:13:41 -0400 (EDT) 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 OAA26236 for ; Thu, 16 May 2002 14:13:23 -0400 (EDT) Message-Id: <5.0.1.4.2.20020516125457.01a07350@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 16 May 2002 14:21:59 -0400 To: manet@ietf.org From: Joe Macker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [manet] List posting reminder 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 JUST A FRIENDLY REMINDER: A members only posting restriction is and has been in effect for manet@ietf.org. Please try to post from your subscribed accounts to avoid problems in posting (delays, duplicates --from eventual approvals, etc). Also, you (not me) are also in control of your own accounts and settings via your password. Regards, joe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu May 16 15:27:34 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 OAA05814 for ; Thu, 16 May 2002 14:40:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05884 for manet-archive@odin.ietf.org; Thu, 16 May 2002 14:41:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03976; Thu, 16 May 2002 14:13:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03947 for ; Thu, 16 May 2002 14:13:55 -0400 (EDT) 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 OAA04765 for ; Thu, 16 May 2002 14:13:41 -0400 (EDT) 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 OAA26236 for ; Thu, 16 May 2002 14:13:23 -0400 (EDT) Message-Id: <5.0.1.4.2.20020516125457.01a07350@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 16 May 2002 14:21:59 -0400 To: manet@ietf.org From: Joe Macker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [manet] List posting reminder 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 JUST A FRIENDLY REMINDER: A members only posting restriction is and has been in effect for manet@ietf.org. Please try to post from your subscribed accounts to avoid problems in posting (delays, duplicates --from eventual approvals, etc). Also, you (not me) are also in control of your own accounts and settings via your password. Regards, joe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 16 20:36:06 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 UAA15678 for ; Thu, 16 May 2002 20:36:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21223; Thu, 16 May 2002 20:07:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21195 for ; Thu, 16 May 2002 20:07:42 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15205 for ; Thu, 16 May 2002 20:07:27 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id RAA08329; Thu, 16 May 2002 17:05:27 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id RAA07749; Thu, 16 May 2002 17:07:35 -0700 (PDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g4H084h07113; Thu, 16 May 2002 17:08:04 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 May 2002 17:07:34 -0700 Message-ID: <8006AC6A777F3F4F8B2A6383C19C5B7A05503554@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric" To: "'Mike Christman'" , "Mullen, John P. (Contractor)" Cc: Tao Lin , manet@ietf.org Subject: RE: [manet] Dumber Question? Date: Thu, 16 May 2002 17:07:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 Mike Christman wrote (in part): > If a collisions can prevent "hello" messages > from being received, but I believe that OLSR allows > for 3 missed messages before timing out. Since the topic of this thread is "dumber question", I feel brave enough to publicly question whether timing out after three missed messages is a good idea or not. That is, I have just begun experimenting with TORA and I've been very impressed at how even a few feet of antenna placement directly impacts network availability for our omni-directional antennas. I've noted that as my devices approach their furthest (distance) range at a given transmission rate, using the filtering option (at which the link was dropped for two successive missed messages) significantly decreased that range. Thus, for my tests, I quickly decided that we could not afford to have our broadcast range needlessly truncated by that restriction. For example, I found that the filtering option would shut down a link that was experiencing 80% availability. Envisioning military operations (especially in view of the 2001 Marine Corps Littoral study) I would say that 80% availability is significantly better than "the norm". Hence my skepticism as to whether the "3 missed messages" restriction is desirable. I would be very appreciative to receive "push back" or agreement from this list since I value your greater maturity in this field and would like to learn from your experience. --Eric _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu May 16 20:36:06 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 UAA15689 for ; Thu, 16 May 2002 20:36:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA22713 for manet-archive@odin.ietf.org; Thu, 16 May 2002 20:36:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21223; Thu, 16 May 2002 20:07:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21195 for ; Thu, 16 May 2002 20:07:42 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15205 for ; Thu, 16 May 2002 20:07:27 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id RAA08329; Thu, 16 May 2002 17:05:27 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id RAA07749; Thu, 16 May 2002 17:07:35 -0700 (PDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g4H084h07113; Thu, 16 May 2002 17:08:04 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 May 2002 17:07:34 -0700 Message-ID: <8006AC6A777F3F4F8B2A6383C19C5B7A05503554@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric" To: "'Mike Christman'" , "Mullen, John P. (Contractor)" Cc: Tao Lin , manet@ietf.org Subject: RE: [manet] Dumber Question? Date: Thu, 16 May 2002 17:07:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 Mike Christman wrote (in part): > If a collisions can prevent "hello" messages > from being received, but I believe that OLSR allows > for 3 missed messages before timing out. Since the topic of this thread is "dumber question", I feel brave enough to publicly question whether timing out after three missed messages is a good idea or not. That is, I have just begun experimenting with TORA and I've been very impressed at how even a few feet of antenna placement directly impacts network availability for our omni-directional antennas. I've noted that as my devices approach their furthest (distance) range at a given transmission rate, using the filtering option (at which the link was dropped for two successive missed messages) significantly decreased that range. Thus, for my tests, I quickly decided that we could not afford to have our broadcast range needlessly truncated by that restriction. For example, I found that the filtering option would shut down a link that was experiencing 80% availability. Envisioning military operations (especially in view of the 2001 Marine Corps Littoral study) I would say that 80% availability is significantly better than "the norm". Hence my skepticism as to whether the "3 missed messages" restriction is desirable. I would be very appreciative to receive "push back" or agreement from this list since I value your greater maturity in this field and would like to learn from your experience. --Eric _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri May 17 00:39:55 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 AAA23671 for ; Fri, 17 May 2002 00:39:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02946; Fri, 17 May 2002 00:12:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02911 for ; Fri, 17 May 2002 00:12:25 -0400 (EDT) Received: from avaznet.com ([203.215.160.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21694 for ; Fri, 17 May 2002 00:12:07 -0400 (EDT) Received: (from qayyum@localhost) by avaznet.com (8.11.6/8.11.6) id g4H5Bgf22685; Fri, 17 May 2002 10:11:42 +0500 From: "Amir Qayyum MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15588.37133.921172.300334@avaznet.com> Date: Fri, 17 May 2002 10:11:41 +0500 To: "Mullen, John P. (Contractor)" Cc: manet@ietf.org Subject: Re: [manet] Dumber Question? In-Reply-To: <02May16.082341mdt.117134@gw.trac.wsmr.army.mil> References: <02May16.082341mdt.117134@gw.trac.wsmr.army.mil> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: qayyum@avaznet.com Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hi John, Mullen, John P. (Contractor) writes: > Hi Mike, > > By "packet," I meant any packet, data or control. > All I know about OLSR is what I've read at: > http://menetou.inria.fr/olsr/draft-ietf-manet-olsr-04.txt Version 6 of the draft is now available on IETF web site and also at http://hipercom.inria.fr/olsr/draft-ietf-manet-olsr-06.txt. (However, what I write below is there in OLSR since its very first draft). > > ... > > The problem is that since the links are not symmetric, it is often true that > Node A receiving a HELLO from Node B does not mean Node B can receive a > packet from Node A. If the HELLO message does not contain A's address, Node > A knows that it can receive packets from B, but it is probable that it > cannot send packets directly to B. It can send B's address in its own > HELLO, but, as I read the protocol, unless B is a two-hop neighbor, Node B > will never know that Node A can receive its packets. In OLSR, a node includes all of its one-hop neighbor nodes along with their link status (symmetric or asymmetric) in its HELLO messages. It helps to determine the bi-directional links between one-hop neighbor nodes. Therefore in OLSR, a node A does know after receiving a HELLO message from node B whether node B can also hear it or not. Moreover, the HELLO messages provide information about two-hop neighborhood which helps to compute MPRs "locally" at each node. A node selects its MPRs among the neighbor nodes with bi-directional connectivity only. Amir ---- Amir Qayyum Avaz Networks Inc. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri May 17 00:39:55 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 AAA23683 for ; Fri, 17 May 2002 00:39:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA04582 for manet-archive@odin.ietf.org; Fri, 17 May 2002 00:40:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02946; Fri, 17 May 2002 00:12:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA02911 for ; Fri, 17 May 2002 00:12:25 -0400 (EDT) Received: from avaznet.com ([203.215.160.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21694 for ; Fri, 17 May 2002 00:12:07 -0400 (EDT) Received: (from qayyum@localhost) by avaznet.com (8.11.6/8.11.6) id g4H5Bgf22685; Fri, 17 May 2002 10:11:42 +0500 From: "Amir Qayyum MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15588.37133.921172.300334@avaznet.com> Date: Fri, 17 May 2002 10:11:41 +0500 To: "Mullen, John P. (Contractor)" Cc: manet@ietf.org Subject: Re: [manet] Dumber Question? In-Reply-To: <02May16.082341mdt.117134@gw.trac.wsmr.army.mil> References: <02May16.082341mdt.117134@gw.trac.wsmr.army.mil> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: qayyum@avaznet.com Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hi John, Mullen, John P. (Contractor) writes: > Hi Mike, > > By "packet," I meant any packet, data or control. > All I know about OLSR is what I've read at: > http://menetou.inria.fr/olsr/draft-ietf-manet-olsr-04.txt Version 6 of the draft is now available on IETF web site and also at http://hipercom.inria.fr/olsr/draft-ietf-manet-olsr-06.txt. (However, what I write below is there in OLSR since its very first draft). > > ... > > The problem is that since the links are not symmetric, it is often true that > Node A receiving a HELLO from Node B does not mean Node B can receive a > packet from Node A. If the HELLO message does not contain A's address, Node > A knows that it can receive packets from B, but it is probable that it > cannot send packets directly to B. It can send B's address in its own > HELLO, but, as I read the protocol, unless B is a two-hop neighbor, Node B > will never know that Node A can receive its packets. In OLSR, a node includes all of its one-hop neighbor nodes along with their link status (symmetric or asymmetric) in its HELLO messages. It helps to determine the bi-directional links between one-hop neighbor nodes. Therefore in OLSR, a node A does know after receiving a HELLO message from node B whether node B can also hear it or not. Moreover, the HELLO messages provide information about two-hop neighborhood which helps to compute MPRs "locally" at each node. A node selects its MPRs among the neighbor nodes with bi-directional connectivity only. Amir ---- Amir Qayyum Avaz Networks Inc. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri May 17 09:58:52 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 JAA14203 for ; Fri, 17 May 2002 09:58:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07396; Fri, 17 May 2002 09:35:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07364 for ; Fri, 17 May 2002 09:35:45 -0400 (EDT) Received: from amber.ccs.neu.edu (postfix@amber.ccs.neu.edu [129.10.116.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13263 for ; Fri, 17 May 2002 09:35:30 -0400 (EDT) Received: from CASABLANCA.ccs.neu.edu (casablanca.ccs.neu.edu [129.10.118.188]) by amber.ccs.neu.edu (Postfix) with ESMTP id 03FC01AAF1; Fri, 17 May 2002 09:35:17 -0400 (EDT) Message-Id: <5.0.2.1.0.20020517092546.0319aeb8@mail.ccs.neu.edu> X-Sender: noubir@mail.ccs.neu.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 17 May 2002 09:26:22 -0400 To: manet@ietf.org From: "G. Noubir" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [manet] Deadline Extended to May 30: Workshop on Wireless Security (in conjunction with MobiCom 2002) 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 The deadline for paper submissions was extended to May 30, 2002. Best regards, Guevara ----------------------------------------------------------------------- Please Accept Our Sincere Apologies Should you Receive Multiple Copies of this CFP ----------------------------------------------------------------------- Call for Papers Workshop on Wireless Security (WiSe) in conjunction with ACM MobiCom 2002 September 28, 2002 Atlanta, Georgia, U.S.A. http://www.crhc.uiuc.edu/~nhv/wise Sponsored by SIGMOBILE (pending) A workshop on Wireless Security will be held in conjunction with ACM MobiCom 2002. The objective of this workshop is to bring together researchers from research communities in wireless networking, security, and dependability, with the goal of fostering interaction among them. With the increasing reliance on wireless networks, issues related to secure and dependable operation of such networks are gaining importance. Topics of interest include, but are not limited to: * Key management in wireless/mobile environments * Intrusion detection * Secure MAC protocols * Secure routing * Denial of service * Privacy and anonymity * Prevention of traffic analysis * Dependable wireless networking * Monitoring and surveillance * Disaster response Paper submission instructions: Submission of papers based on work-in-progress is encouraged. Submitted papers must not be previously published elsewhere or currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs. All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their paper. Papers must meet the following restrictions: No longer than 10 pages (single or double column); in font no smaller than 11 points; must fit properly on US Letter-sized paper (8.5 inch x 11 inch) with reasonable margins. Instructions for electronic submission of papers will be posted at http://www.crhc.uiuc.edu/~nhv/wise/submission.html. Important dates: Paper submissions due: May 30, 2002 Notification of acceptance: July 5, 2002 Camera-ready papers due: July 31, 2002 Workshop date: September 28, 2002 Workshop Co-Chairs: * Douglas Maughan, Defense Advanced Research Projects Agency (dmaughan@darpa.mil) * Nitin Vaidya, University of Illinois at Urbana-Champaign (nhv@uiuc.edu) Program Committee: Yair Amir, Johns Hopkins University Pete Dinsmore, NAI Chip Elliott, BBN Technologies Zygmunt Haas, Cornell University Jean-Pierre Hubaux, EPFL-Lausanne David B. Johnson, Rice University Douglas Maughan, Defense Advanced Research Projects Agency (co-chair) Brian Noble, University of Michigan Ranga Ramanujan, Architecture Technology Corporation Frank Stajano, University of Cambridge Brian Van Leeuwen, Sandia National Laboratories Nitin Vaidya, University of Illinois at Urbana-Champaign (co-chair) Wei Zhao, Texas A&M University Taieb Znati, National Science Foundation, and University of Pittsburgh Publicity Co-Chairs: Mohsen Guizani, University of West Florida Guevara Noubir, Northeastern University Publication Chair: Saad Biaz, Auburn University Registration Chair: Robin Kravets, University of Illinois at Urbana-Champaign _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri May 17 09:58:52 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 JAA14213 for ; Fri, 17 May 2002 09:58:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08543 for manet-archive@odin.ietf.org; Fri, 17 May 2002 09:59:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07396; Fri, 17 May 2002 09:35:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07364 for ; Fri, 17 May 2002 09:35:45 -0400 (EDT) Received: from amber.ccs.neu.edu (postfix@amber.ccs.neu.edu [129.10.116.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13263 for ; Fri, 17 May 2002 09:35:30 -0400 (EDT) Received: from CASABLANCA.ccs.neu.edu (casablanca.ccs.neu.edu [129.10.118.188]) by amber.ccs.neu.edu (Postfix) with ESMTP id 03FC01AAF1; Fri, 17 May 2002 09:35:17 -0400 (EDT) Message-Id: <5.0.2.1.0.20020517092546.0319aeb8@mail.ccs.neu.edu> X-Sender: noubir@mail.ccs.neu.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 17 May 2002 09:26:22 -0400 To: manet@ietf.org From: "G. Noubir" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [manet] Deadline Extended to May 30: Workshop on Wireless Security (in conjunction with MobiCom 2002) 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 The deadline for paper submissions was extended to May 30, 2002. Best regards, Guevara ----------------------------------------------------------------------- Please Accept Our Sincere Apologies Should you Receive Multiple Copies of this CFP ----------------------------------------------------------------------- Call for Papers Workshop on Wireless Security (WiSe) in conjunction with ACM MobiCom 2002 September 28, 2002 Atlanta, Georgia, U.S.A. http://www.crhc.uiuc.edu/~nhv/wise Sponsored by SIGMOBILE (pending) A workshop on Wireless Security will be held in conjunction with ACM MobiCom 2002. The objective of this workshop is to bring together researchers from research communities in wireless networking, security, and dependability, with the goal of fostering interaction among them. With the increasing reliance on wireless networks, issues related to secure and dependable operation of such networks are gaining importance. Topics of interest include, but are not limited to: * Key management in wireless/mobile environments * Intrusion detection * Secure MAC protocols * Secure routing * Denial of service * Privacy and anonymity * Prevention of traffic analysis * Dependable wireless networking * Monitoring and surveillance * Disaster response Paper submission instructions: Submission of papers based on work-in-progress is encouraged. Submitted papers must not be previously published elsewhere or currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs. All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their paper. Papers must meet the following restrictions: No longer than 10 pages (single or double column); in font no smaller than 11 points; must fit properly on US Letter-sized paper (8.5 inch x 11 inch) with reasonable margins. Instructions for electronic submission of papers will be posted at http://www.crhc.uiuc.edu/~nhv/wise/submission.html. Important dates: Paper submissions due: May 30, 2002 Notification of acceptance: July 5, 2002 Camera-ready papers due: July 31, 2002 Workshop date: September 28, 2002 Workshop Co-Chairs: * Douglas Maughan, Defense Advanced Research Projects Agency (dmaughan@darpa.mil) * Nitin Vaidya, University of Illinois at Urbana-Champaign (nhv@uiuc.edu) Program Committee: Yair Amir, Johns Hopkins University Pete Dinsmore, NAI Chip Elliott, BBN Technologies Zygmunt Haas, Cornell University Jean-Pierre Hubaux, EPFL-Lausanne David B. Johnson, Rice University Douglas Maughan, Defense Advanced Research Projects Agency (co-chair) Brian Noble, University of Michigan Ranga Ramanujan, Architecture Technology Corporation Frank Stajano, University of Cambridge Brian Van Leeuwen, Sandia National Laboratories Nitin Vaidya, University of Illinois at Urbana-Champaign (co-chair) Wei Zhao, Texas A&M University Taieb Znati, National Science Foundation, and University of Pittsburgh Publicity Co-Chairs: Mohsen Guizani, University of West Florida Guevara Noubir, Northeastern University Publication Chair: Saad Biaz, Auburn University Registration Chair: Robin Kravets, University of Illinois at Urbana-Champaign _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 21 07:31: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 HAA04970 for ; Tue, 21 May 2002 07:31:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09582; Tue, 21 May 2002 06:57:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09558 for ; Tue, 21 May 2002 06:57:53 -0400 (EDT) Received: from mail.emu.edu.tr (mail.emu.edu.tr [193.140.41.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03971 for ; Tue, 21 May 2002 06:57:15 -0400 (EDT) Received: from romeoe (207.12.185.138 [207.12.185.138]) by mail.emu.edu.tr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LBK7F982; Tue, 21 May 2002 13:56:40 +0300 From: "Evren CAVDIR" To: "Manet List" Date: Tue, 21 May 2002 13:57:26 +0300 Message-ID: <000b01c200b6$4de9c8d0$8ab90ccf@romeoe> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C200CF.733700D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [manet] simulation problem 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 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C200CF.733700D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 I am an MSc. Student in Eastern Mediterranean University Computer Engineering Dept. My thesis is simulating the Dynamic Source Routing (DSR) and Associativity Based Routing (ABR) protocols in Wireless LAN. I would really like to use Ptolemy for my thesis.But unfortunately I do not know which domain is used for such purpose. For time being, I focused on DSR protocol.There is three types of messages in DSR; =20 1. For Route Request message and it has 4 fields in the packet=20 2. For Route Error message and it has 2 fields in the packet=20 3. For Route Reply message and it has 2 fields in the packet=20 =20 Also, we use two types of table stored in each mobile nodes. One is for storing the routes to each node in the network and second one is for storing the received Route Request packets. Besides, these two tables should be dynamic, means that the information stored in these tables are always changing during the cycle of network. =20 So if you know anything about simulating such protocols or if have simulated any of them before, could you please help me. Which domain should I use? And how? Thank you for your cooperation. =20 =20 Evren =C7AVDIR Research Assistant Computer Engineering Department Eastern Mediterranean University Famagusta Mersin 10 Turkey +90-392-630-2831 =20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.362 / Virus Database: 199 - Release Date: 07.05.2002 =20 ------=_NextPart_000_000C_01C200CF.733700D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

I am an MSc. Student in Eastern = Mediterranean University Computer Engineering Dept. My thesis is simulating the Dynamic Source = Routing (DSR) and Associativity=A0 Based = Routing (ABR) protocols in Wireless LAN. I would really like to use Ptolemy for my = thesis.But unfortunately I do not know which = domain is used for such purpose. For time being, I focused on DSR protocol.There is three types of messages in DSR;

 

  1. For Route Request message and it has 4 fields in the = packet
  2. For Route Error message and it has 2 fields in the packet =
  3. For Route Reply message and it has 2 fields in the packet =

 

Also, we use two types of table stored in each mobile = nodes. One is for storing the routes to each node in the network and second one = is for storing the received Route Request packets. Besides, these two tables = should be dynamic, means that the information stored in = these tables are always changing during the cycle of = network.

 

So if you know anything about simulating such = protocols or if have simulated any of them before, could you please help me. Which = domain should I use? And how? Thank you for your = cooperation.

 

 

Evren =C7AVDIR

Research = Assistant

Computer Engineering = Department

Eastern = Mediterranean = University

Famagusta Mersin 10 Turkey

+90-392-630-2831

 


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.362 / Virus Database: 199 - Release Date: 07.05.2002

------=_NextPart_000_000C_01C200CF.733700D0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue May 21 07:31:13 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 HAA04985 for ; Tue, 21 May 2002 07:31:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA11944 for manet-archive@odin.ietf.org; Tue, 21 May 2002 07:31:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09582; Tue, 21 May 2002 06:57:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09558 for ; Tue, 21 May 2002 06:57:53 -0400 (EDT) Received: from mail.emu.edu.tr (mail.emu.edu.tr [193.140.41.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03971 for ; Tue, 21 May 2002 06:57:15 -0400 (EDT) Received: from romeoe (207.12.185.138 [207.12.185.138]) by mail.emu.edu.tr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LBK7F982; Tue, 21 May 2002 13:56:40 +0300 From: "Evren CAVDIR" To: "Manet List" Date: Tue, 21 May 2002 13:57:26 +0300 Message-ID: <000b01c200b6$4de9c8d0$8ab90ccf@romeoe> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C200CF.733700D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [manet] simulation problem 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 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C200CF.733700D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 I am an MSc. Student in Eastern Mediterranean University Computer Engineering Dept. My thesis is simulating the Dynamic Source Routing (DSR) and Associativity Based Routing (ABR) protocols in Wireless LAN. I would really like to use Ptolemy for my thesis.But unfortunately I do not know which domain is used for such purpose. For time being, I focused on DSR protocol.There is three types of messages in DSR; =20 1. For Route Request message and it has 4 fields in the packet=20 2. For Route Error message and it has 2 fields in the packet=20 3. For Route Reply message and it has 2 fields in the packet=20 =20 Also, we use two types of table stored in each mobile nodes. One is for storing the routes to each node in the network and second one is for storing the received Route Request packets. Besides, these two tables should be dynamic, means that the information stored in these tables are always changing during the cycle of network. =20 So if you know anything about simulating such protocols or if have simulated any of them before, could you please help me. Which domain should I use? And how? Thank you for your cooperation. =20 =20 Evren =C7AVDIR Research Assistant Computer Engineering Department Eastern Mediterranean University Famagusta Mersin 10 Turkey +90-392-630-2831 =20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.362 / Virus Database: 199 - Release Date: 07.05.2002 =20 ------=_NextPart_000_000C_01C200CF.733700D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

I am an MSc. Student in Eastern = Mediterranean University Computer Engineering Dept. My thesis is simulating the Dynamic Source = Routing (DSR) and Associativity=A0 Based = Routing (ABR) protocols in Wireless LAN. I would really like to use Ptolemy for my = thesis.But unfortunately I do not know which = domain is used for such purpose. For time being, I focused on DSR protocol.There is three types of messages in DSR;

 

  1. For Route Request message and it has 4 fields in the = packet
  2. For Route Error message and it has 2 fields in the packet =
  3. For Route Reply message and it has 2 fields in the packet =

 

Also, we use two types of table stored in each mobile = nodes. One is for storing the routes to each node in the network and second one = is for storing the received Route Request packets. Besides, these two tables = should be dynamic, means that the information stored in = these tables are always changing during the cycle of = network.

 

So if you know anything about simulating such = protocols or if have simulated any of them before, could you please help me. Which = domain should I use? And how? Thank you for your = cooperation.

 

 

Evren =C7AVDIR

Research = Assistant

Computer Engineering = Department

Eastern = Mediterranean = University

Famagusta Mersin 10 Turkey

+90-392-630-2831

 


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.362 / Virus Database: 199 - Release Date: 07.05.2002

------=_NextPart_000_000C_01C200CF.733700D0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 21 09:18:52 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 JAA09291 for ; Tue, 21 May 2002 09:18:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15528; Tue, 21 May 2002 08:44:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15499 for ; Tue, 21 May 2002 08:44:19 -0400 (EDT) Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07829 for ; Tue, 21 May 2002 08:44:00 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 235F0C6940 for ; Tue, 21 May 2002 08:43:48 -0400 (EDT) Received: from doldham.lerc.nasa.gov (doldham.lerc.nasa.gov [139.88.102.106]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA10516 for ; Tue, 21 May 2002 08:43:47 -0400 (EDT) From: Daniel Oldham Date: Tue, 21 May 2002 12:43:50 GMT Message-ID: <20020521.12435000@doldham.lerc.nasa.gov> To: Manet List X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.2;Linux) X-Priority: 3 (Normal) 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 optimus.ietf.org id IAA15500 Subject: [manet] Fixed Vs Ad-hoc network question? 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 Content-Transfer-Encoding: 8bit Hello everyone: Ad-hoc networks have advantages for applications where it is not possible to deploy a base station to cover all the mobile nodes and in situations where nodes can be lost or destroyed. I also see in the news, a Navy ship that just deployed a wireless fixed network structure using access points and ultra wide band (UWB) technology. UWB technology is more resistive to interference then 802.11 and hopefully more secure. UWB technology can also be used in a ad-hoc network instead of 802.11 to help mask the active source problem for military applications. My understanding is that when using 802.11 hardware in a wireless fixed structure network, the access point (base station) allows for up to a possible 2048 nodes with about 50 active nodes, being the realistic usable maximum. When using 802.11 hardware in an ad-hoc network, the access point is removed and for the same area, only about 10 nodes can now be supported. This is really due to the limit of using only one channel on the 802.11 hardware and not due to the routing protocol. So my question is this: For every ad-hoc network is there an equivalent fixed structure network? -- Daniel R. Oldham Ph.D. Computer Engineer Satellite Networks and Architectures Branch NASA Glenn Research Center 21000 Brookpark Road (MS 54-5) Cleveland OH 44135 216.433.6307 - voice 216.433.8705 - fax oldham@grc.nasa.gov _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue May 21 09:18:52 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 JAA09300 for ; Tue, 21 May 2002 09:18:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17316 for manet-archive@odin.ietf.org; Tue, 21 May 2002 09:19:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15528; Tue, 21 May 2002 08:44:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15499 for ; Tue, 21 May 2002 08:44:19 -0400 (EDT) Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07829 for ; Tue, 21 May 2002 08:44:00 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 235F0C6940 for ; Tue, 21 May 2002 08:43:48 -0400 (EDT) Received: from doldham.lerc.nasa.gov (doldham.lerc.nasa.gov [139.88.102.106]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA10516 for ; Tue, 21 May 2002 08:43:47 -0400 (EDT) From: Daniel Oldham Date: Tue, 21 May 2002 12:43:50 GMT Message-ID: <20020521.12435000@doldham.lerc.nasa.gov> To: Manet List X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.2;Linux) X-Priority: 3 (Normal) 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 optimus.ietf.org id IAA15500 Subject: [manet] Fixed Vs Ad-hoc network question? 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 Content-Transfer-Encoding: 8bit Hello everyone: Ad-hoc networks have advantages for applications where it is not possible to deploy a base station to cover all the mobile nodes and in situations where nodes can be lost or destroyed. I also see in the news, a Navy ship that just deployed a wireless fixed network structure using access points and ultra wide band (UWB) technology. UWB technology is more resistive to interference then 802.11 and hopefully more secure. UWB technology can also be used in a ad-hoc network instead of 802.11 to help mask the active source problem for military applications. My understanding is that when using 802.11 hardware in a wireless fixed structure network, the access point (base station) allows for up to a possible 2048 nodes with about 50 active nodes, being the realistic usable maximum. When using 802.11 hardware in an ad-hoc network, the access point is removed and for the same area, only about 10 nodes can now be supported. This is really due to the limit of using only one channel on the 802.11 hardware and not due to the routing protocol. So my question is this: For every ad-hoc network is there an equivalent fixed structure network? -- Daniel R. Oldham Ph.D. Computer Engineer Satellite Networks and Architectures Branch NASA Glenn Research Center 21000 Brookpark Road (MS 54-5) Cleveland OH 44135 216.433.6307 - voice 216.433.8705 - fax oldham@grc.nasa.gov _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 21 12:37:22 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 MAA18139 for ; Tue, 21 May 2002 12:37:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25697; Tue, 21 May 2002 11:56:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25667 for ; Tue, 21 May 2002 11:56:02 -0400 (EDT) Received: from webmail7.rediffmail.com (webmail7.rediffmail.com [202.54.124.152] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15593 for ; Tue, 21 May 2002 11:55:42 -0400 (EDT) Received: (qmail 15014 invoked by uid 510); 21 May 2002 15:53:36 -0000 Date: 21 May 2002 15:53:36 -0000 Message-ID: <20020521155336.15013.qmail@webmail7.rediffmail.com> Received: from unknown (61.1.132.72) by rediffmail.com via HTTP; 21 May 2002 15:53:36 -0000 MIME-Version: 1.0 From: "sabeel ansari" Reply-To: "sabeel ansari" To: manet@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [manet] help required 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 Hi I am a newbie in wireless networking and new to the NS2 simulator. The NS2 doc says that the TCPSink is sink - only for the Tahoe and Reno versions. What do I use as a sink, for testing the Vegas version?? Thanks in advance sabeel _________________________________________________________ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue May 21 12:37:22 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 MAA18148 for ; Tue, 21 May 2002 12:37:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA00420 for manet-archive@odin.ietf.org; Tue, 21 May 2002 12:37:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25697; Tue, 21 May 2002 11:56:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25667 for ; Tue, 21 May 2002 11:56:02 -0400 (EDT) Received: from webmail7.rediffmail.com (webmail7.rediffmail.com [202.54.124.152] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15593 for ; Tue, 21 May 2002 11:55:42 -0400 (EDT) Received: (qmail 15014 invoked by uid 510); 21 May 2002 15:53:36 -0000 Date: 21 May 2002 15:53:36 -0000 Message-ID: <20020521155336.15013.qmail@webmail7.rediffmail.com> Received: from unknown (61.1.132.72) by rediffmail.com via HTTP; 21 May 2002 15:53:36 -0000 MIME-Version: 1.0 From: "sabeel ansari" Reply-To: "sabeel ansari" To: manet@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [manet] help required 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 Hi I am a newbie in wireless networking and new to the NS2 simulator. The NS2 doc says that the TCPSink is sink - only for the Tahoe and Reno versions. What do I use as a sink, for testing the Vegas version?? Thanks in advance sabeel _________________________________________________________ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 21 12:42:55 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 MAA18419 for ; Tue, 21 May 2002 12:42:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28515; Tue, 21 May 2002 12:18:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28486 for ; Tue, 21 May 2002 12:18:37 -0400 (EDT) Received: from hikari.mkg.sfc.keio.ac.jp (hikari.mkg.sfc.keio.ac.jp [133.27.186.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16556 for ; Tue, 21 May 2002 12:18:15 -0400 (EDT) Received: (from tobe@localhost) by hikari.mkg.sfc.keio.ac.jp (8.9.3/3.7W-mkg) id BAA53281; Wed, 22 May 2002 01:18:01 +0900 (JST) Date: Wed, 22 May 2002 01:18:01 +0900 (JST) Message-Id: <200205211618.BAA53281@hikari.mkg.sfc.keio.ac.jp> From: Yoshito Tobe To: manet@ietf.org Subject: [manet] WMCSA 2002: Early Registration Deadline Approaching 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 Hello, folks, You are invited to participate in the following workshop on mobile computing. Please note: The early registration deadline is *May 29*. - Yoshito Tobe ============================================================ WMCSA 2002 Call for Participation (We apologise if you receive multiple copies.) 4th IEEE Workshop on Mobile Computing Systems & Applications (WMCSA2002) Thursday-Friday, June 20-21, 2002 Villa Roma Resort & Conference Center, Callicoon, New York http://wmcsa2002.hpl.hp.com/ info@wmcsa2002.hpl.hp.com Sponsored by the IEEE Computer Society (TCI & TCOS), Hewlett-Packard, IBM and Intel In cooperation with ACM SIGMOBILE and USENIX The Fourth IEEE Workshop on Mobile Computing Systems and Applications is the latest in a series of high-quality, interactive forums for discussion on all aspects of mobile computing systems and applications. We look forward to another highly successful and enjoyable workshop, this time in the Catskills area of New York, by the Delaware river with rolling hills, lakes and small quiet towns, a few hours' drive from New York City and 1 hour's drive from the Stuart/Newburgh airport. To encourage an interactive atmosphere, attendance will be limited to approximately 75 attendees. Authors of submitted papers and demo proposals will be given first preference, with others able to register on a space-available basis. THE PROGRAM: There will be technical paper sessions on a wide range of topics, including location-dependence, smart space infrastructure, security, pervasive querying, inter-device aggregation and routing. There will be demonstrations of research prototypes, including sensor networks, personal servers, tools for ubicomp development and wireless load-balancing. The workshop will also feature an invited talk and panel session. The preliminary program can be found at http://wmcsa2002.hpl.hp.com/program.html. HOTEL and REGISTRATION: Workshop registration is by online form or by fax/letter; hotel booking is via the Villa Roma Conference Center. See http://wmcsa2002.hpl.hp.com/register.html for details. The early registration deadline and hotel cut-off date is May 29, 2002. IMPORTANT DATES: Early Registration & Hotel Cut-off Deadline: May 29, 2002 WORKSHOP: June 20-21, 2002 ORGANIZING COMMITTEE: * General Chair: Tim Kindberg, HP Labs * Program Chair: Brian Noble, University of Michigan * Research Demos Chair: Hans-W. Gellersen, Lancaster University * Finance Chair: John Barton, HP Labs * Local arrangements Chair: Apratim Purakayastha, IBM * Publicity co-chairs: Anthony Joseph, University of California, Berkeley;Jochen Seitz, Technical University of Ilmenau; Yoshito Tobe, Tokyo Denki University, Japan PROGRAM COMMITTEE: * Gregory Abowd, Georgia Tech * Barry Brumitt, Microsoft * Adrian Friday, Lancaster University * Armando Fox, Stanford * John Heidemann, USC/ISI * Robin Kravets, University of Illinois-UC * Hui Lei, IBM * Gerald Q. Maguire, KTH Sweden * Brian Noble (Chair), University of Michigan * Trevor Pering, Intel * Bill Schilit, FXPAL * Cormac Sreenan, U. College Cork * Dan Wallach, Rice FOR MORE INFORMATION: http://wmcsa2002.hpl.hp.com/ info@wmcsa2002.hpl.hp.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue May 21 12:42:56 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 MAA18430 for ; Tue, 21 May 2002 12:42:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA00724 for manet-archive@odin.ietf.org; Tue, 21 May 2002 12:43:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28515; Tue, 21 May 2002 12:18:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28486 for ; Tue, 21 May 2002 12:18:37 -0400 (EDT) Received: from hikari.mkg.sfc.keio.ac.jp (hikari.mkg.sfc.keio.ac.jp [133.27.186.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16556 for ; Tue, 21 May 2002 12:18:15 -0400 (EDT) Received: (from tobe@localhost) by hikari.mkg.sfc.keio.ac.jp (8.9.3/3.7W-mkg) id BAA53281; Wed, 22 May 2002 01:18:01 +0900 (JST) Date: Wed, 22 May 2002 01:18:01 +0900 (JST) Message-Id: <200205211618.BAA53281@hikari.mkg.sfc.keio.ac.jp> From: Yoshito Tobe To: manet@ietf.org Subject: [manet] WMCSA 2002: Early Registration Deadline Approaching 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 Hello, folks, You are invited to participate in the following workshop on mobile computing. Please note: The early registration deadline is *May 29*. - Yoshito Tobe ============================================================ WMCSA 2002 Call for Participation (We apologise if you receive multiple copies.) 4th IEEE Workshop on Mobile Computing Systems & Applications (WMCSA2002) Thursday-Friday, June 20-21, 2002 Villa Roma Resort & Conference Center, Callicoon, New York http://wmcsa2002.hpl.hp.com/ info@wmcsa2002.hpl.hp.com Sponsored by the IEEE Computer Society (TCI & TCOS), Hewlett-Packard, IBM and Intel In cooperation with ACM SIGMOBILE and USENIX The Fourth IEEE Workshop on Mobile Computing Systems and Applications is the latest in a series of high-quality, interactive forums for discussion on all aspects of mobile computing systems and applications. We look forward to another highly successful and enjoyable workshop, this time in the Catskills area of New York, by the Delaware river with rolling hills, lakes and small quiet towns, a few hours' drive from New York City and 1 hour's drive from the Stuart/Newburgh airport. To encourage an interactive atmosphere, attendance will be limited to approximately 75 attendees. Authors of submitted papers and demo proposals will be given first preference, with others able to register on a space-available basis. THE PROGRAM: There will be technical paper sessions on a wide range of topics, including location-dependence, smart space infrastructure, security, pervasive querying, inter-device aggregation and routing. There will be demonstrations of research prototypes, including sensor networks, personal servers, tools for ubicomp development and wireless load-balancing. The workshop will also feature an invited talk and panel session. The preliminary program can be found at http://wmcsa2002.hpl.hp.com/program.html. HOTEL and REGISTRATION: Workshop registration is by online form or by fax/letter; hotel booking is via the Villa Roma Conference Center. See http://wmcsa2002.hpl.hp.com/register.html for details. The early registration deadline and hotel cut-off date is May 29, 2002. IMPORTANT DATES: Early Registration & Hotel Cut-off Deadline: May 29, 2002 WORKSHOP: June 20-21, 2002 ORGANIZING COMMITTEE: * General Chair: Tim Kindberg, HP Labs * Program Chair: Brian Noble, University of Michigan * Research Demos Chair: Hans-W. Gellersen, Lancaster University * Finance Chair: John Barton, HP Labs * Local arrangements Chair: Apratim Purakayastha, IBM * Publicity co-chairs: Anthony Joseph, University of California, Berkeley;Jochen Seitz, Technical University of Ilmenau; Yoshito Tobe, Tokyo Denki University, Japan PROGRAM COMMITTEE: * Gregory Abowd, Georgia Tech * Barry Brumitt, Microsoft * Adrian Friday, Lancaster University * Armando Fox, Stanford * John Heidemann, USC/ISI * Robin Kravets, University of Illinois-UC * Hui Lei, IBM * Gerald Q. Maguire, KTH Sweden * Brian Noble (Chair), University of Michigan * Trevor Pering, Intel * Bill Schilit, FXPAL * Cormac Sreenan, U. College Cork * Dan Wallach, Rice FOR MORE INFORMATION: http://wmcsa2002.hpl.hp.com/ info@wmcsa2002.hpl.hp.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 21 13:37:49 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 NAA21320 for ; Tue, 21 May 2002 13:37:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02994; Tue, 21 May 2002 13:17:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02963 for ; Tue, 21 May 2002 13:17:35 -0400 (EDT) Received: from web20805.mail.yahoo.com (web20805.mail.yahoo.com [216.136.226.194]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20191 for ; Tue, 21 May 2002 13:17:16 -0400 (EDT) Message-ID: <20020521171733.45679.qmail@web20805.mail.yahoo.com> Received: from [128.194.135.8] by web20805.mail.yahoo.com via HTTP; Tue, 21 May 2002 10:17:33 PDT Date: Tue, 21 May 2002 10:17:33 -0700 (PDT) From: Jianfeng Cai To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] Can we use the packet loss rate to detect DOS attack? 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 Hi, all, I am a newcommer in ad hoc network field. I get a question of Denail-of-service attack. In case a malicious node resides on a route, it drops packets according to a possibility, say dropping 20% or 30%. Can we detect this attack by looking at the packet loss rate? In another word, can we get normal packet loss rates for specific environments? thanks, Jianfeng __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue May 21 14:28: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 NAA21332 for ; Tue, 21 May 2002 13:37:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA04502 for manet-archive@odin.ietf.org; Tue, 21 May 2002 13:38:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02994; Tue, 21 May 2002 13:17:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02963 for ; Tue, 21 May 2002 13:17:35 -0400 (EDT) Received: from web20805.mail.yahoo.com (web20805.mail.yahoo.com [216.136.226.194]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20191 for ; Tue, 21 May 2002 13:17:16 -0400 (EDT) Message-ID: <20020521171733.45679.qmail@web20805.mail.yahoo.com> Received: from [128.194.135.8] by web20805.mail.yahoo.com via HTTP; Tue, 21 May 2002 10:17:33 PDT Date: Tue, 21 May 2002 10:17:33 -0700 (PDT) From: Jianfeng Cai To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] Can we use the packet loss rate to detect DOS attack? 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 Hi, all, I am a newcommer in ad hoc network field. I get a question of Denail-of-service attack. In case a malicious node resides on a route, it drops packets according to a possibility, say dropping 20% or 30%. Can we detect this attack by looking at the packet loss rate? In another word, can we get normal packet loss rates for specific environments? thanks, Jianfeng __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 21 18:21:26 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 SAA03787 for ; Tue, 21 May 2002 18:21:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17363; Tue, 21 May 2002 17:53:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17331 for ; Tue, 21 May 2002 17:53:24 -0400 (EDT) Received: from wolfe.bbn.com (wolfe.BBN.COM [128.89.80.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02566 for ; Tue, 21 May 2002 17:52:50 -0400 (EDT) Received: by wolfe.bbn.com (Postfix, from userid 20251) id 0D91716484; Tue, 21 May 2002 17:52:39 -0400 (EDT) To: manet@ietf.org Subject: Re:[manet] Dumb Question? Message-Id: <20020521215239.0D91716484@wolfe.bbn.com> Date: Tue, 21 May 2002 17:52:39 -0400 (EDT) From: csantiva@bbn.com (cesar santivanez) 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 Hi all, When evaluating a routing protocol performance, we need to consider not only the network size but also the traffic and mobility rate. Also, the traffic distribution is of paramount importance, since uniformly distributed traffic will favor proactive approaches while a more reduced sets of destination (in a period of time) will favor reactive approahes. Also, not only the impact of the control overhead need to be considered, but also the effect of route information latency, etc. in route optimality, and the final efferct of route sub-optimality in th esystem performance. We have developed a methodology for the study of scalability of ad hoc networks, defining the total overhead as the metric that encompass the effect of control overhead (either proactive updates or reactive route discovery packets) and the effect of sub-optimal routes (more transmissions that required. We applied out methodology for comparing several ad-hoc routing protocols, including standard link state, hierarchical link state, ZRP, and Hazy Sighted Link State (HSLS). Both, the methodology and our results (based on a set of realistics assumptions, of which the more controversial may be the uniform traffci distribution ;-) can be found in our upcoming INFOCOM'02 paper: C. Santivanez, B. McDonald, I. Stavrakakis, and R. Ramanathan., "On the Scalability of Ad Hoc Routing Protocols," to appear in Proceedings of IEEE INFOCOM'02, New York, June, 2002. A copy of this paper may be found at the conference web page or at th efollowing URL http://www.ir.bbn.com/documents/articles/index.html Among other things, we found that ZRP - by being able to dynamically adapts its zone size reduced de rate of increase of overhead w.r.t. network size (N) from N^2 for pure proactive or reactive approaches, to N^1.66. Multilevel Hierarchical link state, further reduced the overhead to a little more than N^1.5, and HSLS by balancing the control overhead and the negative impact of route innacuracies reduced the total overhead to N^1.5. We noted that ZRP behaves as a 2-level hierarchy system, while multi-level Hierarchical link state and HSLS behave as having as many level as needed. The results also relate total overhead to traffic intensity (assuming uniformly distributed source-destinations) and mobility. An important conclusion of these results is that as mobility increases, it pays off to allow the control overhead to increase, but not linearly with the rate of link changes, that is, to allow nodes to have a distorted view of the network. Also, as traffic rate increases, it pays off to let the control overhead to increase as well, since the quality of the routes become more important as these routes are used more intensively ... I hope these results will help the discussion ... Cesar Santivanez Network Scientist BBN Technologies haas@ece.cornell.edu wrote: > Hi Charlie, > > Well, I agree with you that since pure on-demand protocol is a > special case of a hybrid scheme, such as ZRP, a hybrid scheme > performance is bound to produce at least as good results as any of the two > extremes - purely proactive and purely proactive schemes. In fact, our > study (for example, the paper in your book) shows that it can reduce the > control traffic to a small fraction of those two extremes. These results > have been confirmed both analytically and through simulation. > > Your point regarding scalability is a very valid point. We are currently > evaluating the scalability of the hybrid (ZRP) approach for thousands to > tens of thousands of nodes. This is not a trivial task, taking into the > account the simulation runtime duration. But the preliminary results are > *very* encouraging, to say the least. Stay tuned .... > > Zygmunt. > ==-=-===== > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > Wireless Networks Laboratory http://wnl.ece.cornell.edu > School of Electrical Engineering > Cornell University tel: +1-607-255-3454 > 323 Frank Rhodes Hall fax: +1-607-255-9072 > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > U.S.A > WNL web page: http://wnl.ece.cornell.edu > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > On Wed, 15 May 2002, Charlie Perkins wrote: > > > > > Hello Douglas, > > > > We have results for scaling AODV up to 10,000 nodes. > > We know that we can do better by improving the packet > > delivery ratio. In a few weeks, I reckon we'll have some > > specific directions for algorithm improvement. > > > > ZDP is theoretically able to do better, simply because it > > admits as special cases all on-demand protocols. However, > > I have never seen any results showing ZDP on a network > > of 10,000 nodes (simulated). > > > > Regards, > > Charlie P. > > > > > > "Nast, Douglas P" wrote: > > > > > Zygmunt, > > > > > > I think your idea is very interesting, as it addresses the latency issue for > > > routes in your zone (which is important in military apps), and offers the > > > promise of scalability: The reactive inter-zone idea is reminiscent of the > > > hierarchical architecture of OSPF, which essentially operates LS intra-area > > > and DV inter-area. How would you contrast your zone idea to OSPF areas? > > > > > > Doug Nast, Boeing > > > > > > -----Original Message----- > > > From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] > > > Sent: Tuesday, May 14, 2002 11:56 AM > > > To: Mullen, John P. (Contractor) > > > Cc: manet@ietf.org > > > Subject: RE: [manet] Dumb Question? > > > > > > Hi John, > > > > > > > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > > > > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser > > > speculates > > > > on p. 33 that it is unlikely a single protocol will be able to operate > > > > efficiently over the full range of conditions under which a military MANET > > > > must operate. If he is correct, the issue may never be fully resolved. > > > > > > Yes, I read this book too (:-) ... > > > > > > I hate to bring this point over again ... and self-promote our work ... > > > but the issue of "efficient operation over a wide range of conditions" can > > > and should be addressed by a *hybrid* routing scheme, where the "proactive" > > > and "reactive" behavior are "mixed" in the amounts that match these > > > operational conditions. In other words, *adaptivity* is the key issue > > > here. > > > > > > One such an example of a hybrid scheme is (of course, you have guessed) > > > the ZRP protocol, in which the amount of proactive vs reactive behavior is > > > *dynamically* adjusted through a single parameter - the zone radius. > > > > > > Now imagine this - one could use the AODV (or DSR, or your favorite > > > reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or > > > your favorite proactive protocol) as the proactive protocol in ZRP (I > > > tried to offend the smallest number of people here (;-)). This is why ZRP > > > is a framework for ... for exactly this - for "efficient operation over a > > > wide range of conditions". So, maybe, there is a hope to resolve this > > > issue after all. > > > > > > Zygmunt. > > > ==-=-===== > > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > > > Wireless Networks Laboratory http://wnl.ece.cornell.edu > > > School of Electrical Engineering > > > Cornell University tel: +1-607-255-3454 > > > 323 Frank Rhodes Hall fax: +1-607-255-9072 > > > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > > > U.S.A > > > WNL web page: http://wnl.ece.cornell.edu > > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue May 21 18:21:38 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 SAA03810 for ; Tue, 21 May 2002 18:21:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA19140 for manet-archive@odin.ietf.org; Tue, 21 May 2002 18:21:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17363; Tue, 21 May 2002 17:53:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17331 for ; Tue, 21 May 2002 17:53:24 -0400 (EDT) Received: from wolfe.bbn.com (wolfe.BBN.COM [128.89.80.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02566 for ; Tue, 21 May 2002 17:52:50 -0400 (EDT) Received: by wolfe.bbn.com (Postfix, from userid 20251) id 0D91716484; Tue, 21 May 2002 17:52:39 -0400 (EDT) To: manet@ietf.org Subject: Re:[manet] Dumb Question? Message-Id: <20020521215239.0D91716484@wolfe.bbn.com> Date: Tue, 21 May 2002 17:52:39 -0400 (EDT) From: csantiva@bbn.com (cesar santivanez) 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 Hi all, When evaluating a routing protocol performance, we need to consider not only the network size but also the traffic and mobility rate. Also, the traffic distribution is of paramount importance, since uniformly distributed traffic will favor proactive approaches while a more reduced sets of destination (in a period of time) will favor reactive approahes. Also, not only the impact of the control overhead need to be considered, but also the effect of route information latency, etc. in route optimality, and the final efferct of route sub-optimality in th esystem performance. We have developed a methodology for the study of scalability of ad hoc networks, defining the total overhead as the metric that encompass the effect of control overhead (either proactive updates or reactive route discovery packets) and the effect of sub-optimal routes (more transmissions that required. We applied out methodology for comparing several ad-hoc routing protocols, including standard link state, hierarchical link state, ZRP, and Hazy Sighted Link State (HSLS). Both, the methodology and our results (based on a set of realistics assumptions, of which the more controversial may be the uniform traffci distribution ;-) can be found in our upcoming INFOCOM'02 paper: C. Santivanez, B. McDonald, I. Stavrakakis, and R. Ramanathan., "On the Scalability of Ad Hoc Routing Protocols," to appear in Proceedings of IEEE INFOCOM'02, New York, June, 2002. A copy of this paper may be found at the conference web page or at th efollowing URL http://www.ir.bbn.com/documents/articles/index.html Among other things, we found that ZRP - by being able to dynamically adapts its zone size reduced de rate of increase of overhead w.r.t. network size (N) from N^2 for pure proactive or reactive approaches, to N^1.66. Multilevel Hierarchical link state, further reduced the overhead to a little more than N^1.5, and HSLS by balancing the control overhead and the negative impact of route innacuracies reduced the total overhead to N^1.5. We noted that ZRP behaves as a 2-level hierarchy system, while multi-level Hierarchical link state and HSLS behave as having as many level as needed. The results also relate total overhead to traffic intensity (assuming uniformly distributed source-destinations) and mobility. An important conclusion of these results is that as mobility increases, it pays off to allow the control overhead to increase, but not linearly with the rate of link changes, that is, to allow nodes to have a distorted view of the network. Also, as traffic rate increases, it pays off to let the control overhead to increase as well, since the quality of the routes become more important as these routes are used more intensively ... I hope these results will help the discussion ... Cesar Santivanez Network Scientist BBN Technologies haas@ece.cornell.edu wrote: > Hi Charlie, > > Well, I agree with you that since pure on-demand protocol is a > special case of a hybrid scheme, such as ZRP, a hybrid scheme > performance is bound to produce at least as good results as any of the two > extremes - purely proactive and purely proactive schemes. In fact, our > study (for example, the paper in your book) shows that it can reduce the > control traffic to a small fraction of those two extremes. These results > have been confirmed both analytically and through simulation. > > Your point regarding scalability is a very valid point. We are currently > evaluating the scalability of the hybrid (ZRP) approach for thousands to > tens of thousands of nodes. This is not a trivial task, taking into the > account the simulation runtime duration. But the preliminary results are > *very* encouraging, to say the least. Stay tuned .... > > Zygmunt. > ==-=-===== > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > Wireless Networks Laboratory http://wnl.ece.cornell.edu > School of Electrical Engineering > Cornell University tel: +1-607-255-3454 > 323 Frank Rhodes Hall fax: +1-607-255-9072 > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > U.S.A > WNL web page: http://wnl.ece.cornell.edu > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > On Wed, 15 May 2002, Charlie Perkins wrote: > > > > > Hello Douglas, > > > > We have results for scaling AODV up to 10,000 nodes. > > We know that we can do better by improving the packet > > delivery ratio. In a few weeks, I reckon we'll have some > > specific directions for algorithm improvement. > > > > ZDP is theoretically able to do better, simply because it > > admits as special cases all on-demand protocols. However, > > I have never seen any results showing ZDP on a network > > of 10,000 nodes (simulated). > > > > Regards, > > Charlie P. > > > > > > "Nast, Douglas P" wrote: > > > > > Zygmunt, > > > > > > I think your idea is very interesting, as it addresses the latency issue for > > > routes in your zone (which is important in military apps), and offers the > > > promise of scalability: The reactive inter-zone idea is reminiscent of the > > > hierarchical architecture of OSPF, which essentially operates LS intra-area > > > and DV inter-area. How would you contrast your zone idea to OSPF areas? > > > > > > Doug Nast, Boeing > > > > > > -----Original Message----- > > > From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] > > > Sent: Tuesday, May 14, 2002 11:56 AM > > > To: Mullen, John P. (Contractor) > > > Cc: manet@ietf.org > > > Subject: RE: [manet] Dumb Question? > > > > > > Hi John, > > > > > > > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > > > > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser > > > speculates > > > > on p. 33 that it is unlikely a single protocol will be able to operate > > > > efficiently over the full range of conditions under which a military MANET > > > > must operate. If he is correct, the issue may never be fully resolved. > > > > > > Yes, I read this book too (:-) ... > > > > > > I hate to bring this point over again ... and self-promote our work ... > > > but the issue of "efficient operation over a wide range of conditions" can > > > and should be addressed by a *hybrid* routing scheme, where the "proactive" > > > and "reactive" behavior are "mixed" in the amounts that match these > > > operational conditions. In other words, *adaptivity* is the key issue > > > here. > > > > > > One such an example of a hybrid scheme is (of course, you have guessed) > > > the ZRP protocol, in which the amount of proactive vs reactive behavior is > > > *dynamically* adjusted through a single parameter - the zone radius. > > > > > > Now imagine this - one could use the AODV (or DSR, or your favorite > > > reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or > > > your favorite proactive protocol) as the proactive protocol in ZRP (I > > > tried to offend the smallest number of people here (;-)). This is why ZRP > > > is a framework for ... for exactly this - for "efficient operation over a > > > wide range of conditions". So, maybe, there is a hope to resolve this > > > issue after all. > > > > > > Zygmunt. > > > ==-=-===== > > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > > > Wireless Networks Laboratory http://wnl.ece.cornell.edu > > > School of Electrical Engineering > > > Cornell University tel: +1-607-255-3454 > > > 323 Frank Rhodes Hall fax: +1-607-255-9072 > > > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > > > U.S.A > > > WNL web page: http://wnl.ece.cornell.edu > > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 21 23:33:09 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 XAA15312 for ; Tue, 21 May 2002 23:33:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00474; Tue, 21 May 2002 23:06:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00421 for ; Tue, 21 May 2002 23:06:24 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14003 for ; Tue, 21 May 2002 23:06:05 -0400 (EDT) Received: from FRED-W2K6.cisco.com (sjc-vpn1-826.cisco.com [10.21.99.58]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4M34DPV003865; Tue, 21 May 2002 20:05:51 -0700 (PDT) Message-Id: <5.1.0.14.2.20020521225153.04b659a8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 21 May 2002 22:53:42 -0500 To: Jianfeng Cai From: Fred Baker Subject: Re: [manet] Can we use the packet loss rate to detect DOS attack? Cc: manet@ietf.org In-Reply-To: <20020521171733.45679.qmail@web20805.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 At 10:17 AM 5/21/2002 -0700, Jianfeng Cai wrote: >Can we detect this attack by looking at the packet loss rate? not really. We can detect the onset of a potential attack by a change in the loss rate, but we have to look at the traffic to tell whether there is an elastic application running that should have adapted by didn't (SYN attack, for example) or an inelastic application run amuck, perhaps due to a remote routing change. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue May 21 23:33:10 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 XAA15322 for ; Tue, 21 May 2002 23:33:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA02438 for manet-archive@odin.ietf.org; Tue, 21 May 2002 23:33:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00474; Tue, 21 May 2002 23:06:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00421 for ; Tue, 21 May 2002 23:06:24 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14003 for ; Tue, 21 May 2002 23:06:05 -0400 (EDT) Received: from FRED-W2K6.cisco.com (sjc-vpn1-826.cisco.com [10.21.99.58]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4M34DPV003865; Tue, 21 May 2002 20:05:51 -0700 (PDT) Message-Id: <5.1.0.14.2.20020521225153.04b659a8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 21 May 2002 22:53:42 -0500 To: Jianfeng Cai From: Fred Baker Subject: Re: [manet] Can we use the packet loss rate to detect DOS attack? Cc: manet@ietf.org In-Reply-To: <20020521171733.45679.qmail@web20805.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 At 10:17 AM 5/21/2002 -0700, Jianfeng Cai wrote: >Can we detect this attack by looking at the packet loss rate? not really. We can detect the onset of a potential attack by a change in the loss rate, but we have to look at the traffic to tell whether there is an elastic application running that should have adapted by didn't (SYN attack, for example) or an inelastic application run amuck, perhaps due to a remote routing change. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 21 23:36:07 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 XAA15410 for ; Tue, 21 May 2002 23:36:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00451; Tue, 21 May 2002 23:06:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00413 for ; Tue, 21 May 2002 23:06:22 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14000 for ; Tue, 21 May 2002 23:06:03 -0400 (EDT) Received: from FRED-W2K6.cisco.com (sjc-vpn1-826.cisco.com [10.21.99.58]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4M34DPT003865; Tue, 21 May 2002 20:05:47 -0700 (PDT) Message-Id: <5.1.0.14.2.20020521225100.02a18ce8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 21 May 2002 22:51:31 -0500 To: Daniel Oldham From: Fred Baker Subject: Re: [manet] Fixed Vs Ad-hoc network question? Cc: Manet List In-Reply-To: <20020521.12435000@doldham.lerc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 At 12:43 PM 5/21/2002 +0000, Daniel Oldham wrote: >For every ad-hoc network is there an equivalent >fixed structure network? there is for every static instance of an ad-hoc network. If it changes and freezes, there is another. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue May 21 23:36:08 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 XAA15419 for ; Tue, 21 May 2002 23:36:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA02490 for manet-archive@odin.ietf.org; Tue, 21 May 2002 23:36:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00451; Tue, 21 May 2002 23:06:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00413 for ; Tue, 21 May 2002 23:06:22 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14000 for ; Tue, 21 May 2002 23:06:03 -0400 (EDT) Received: from FRED-W2K6.cisco.com (sjc-vpn1-826.cisco.com [10.21.99.58]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4M34DPT003865; Tue, 21 May 2002 20:05:47 -0700 (PDT) Message-Id: <5.1.0.14.2.20020521225100.02a18ce8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 21 May 2002 22:51:31 -0500 To: Daniel Oldham From: Fred Baker Subject: Re: [manet] Fixed Vs Ad-hoc network question? Cc: Manet List In-Reply-To: <20020521.12435000@doldham.lerc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 At 12:43 PM 5/21/2002 +0000, Daniel Oldham wrote: >For every ad-hoc network is there an equivalent >fixed structure network? there is for every static instance of an ad-hoc network. If it changes and freezes, there is another. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 22 09:44:48 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 JAA01664 for ; Wed, 22 May 2002 09:44:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21793; Wed, 22 May 2002 09:06:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21755 for ; Wed, 22 May 2002 09:06:49 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29836 for ; Wed, 22 May 2002 09:06:30 -0400 (EDT) Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L2Q4T7VY; Wed, 22 May 2002 09:06:42 -0400 Message-ID: <00c401c20191$83aec570$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Daniel Oldham" , "Fred Baker" Cc: "Manet List" References: <5.1.0.14.2.20020521225100.02a18ce8@mira-sjcm-4.cisco.com> Subject: Re: [manet] Fixed Vs Ad-hoc network question? Date: Wed, 22 May 2002 09:06:40 -0400 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 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Furthermore, nothing stops you from running ad hoc routing protocols on edge access routers on their wireless links. ----- Original Message ----- From: "Fred Baker" To: "Daniel Oldham" Cc: "Manet List" Sent: Tuesday, May 21, 2002 11:51 PM Subject: Re: [manet] Fixed Vs Ad-hoc network question? > At 12:43 PM 5/21/2002 +0000, Daniel Oldham wrote: > >For every ad-hoc network is there an equivalent > >fixed structure network? > > there is for every static instance of an ad-hoc network. If it changes and > freezes, there is another. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 22 09:44:48 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 JAA01674 for ; Wed, 22 May 2002 09:44:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA24601 for manet-archive@odin.ietf.org; Wed, 22 May 2002 09:45:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21793; Wed, 22 May 2002 09:06:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21755 for ; Wed, 22 May 2002 09:06:49 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29836 for ; Wed, 22 May 2002 09:06:30 -0400 (EDT) Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L2Q4T7VY; Wed, 22 May 2002 09:06:42 -0400 Message-ID: <00c401c20191$83aec570$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Daniel Oldham" , "Fred Baker" Cc: "Manet List" References: <5.1.0.14.2.20020521225100.02a18ce8@mira-sjcm-4.cisco.com> Subject: Re: [manet] Fixed Vs Ad-hoc network question? Date: Wed, 22 May 2002 09:06:40 -0400 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 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Furthermore, nothing stops you from running ad hoc routing protocols on edge access routers on their wireless links. ----- Original Message ----- From: "Fred Baker" To: "Daniel Oldham" Cc: "Manet List" Sent: Tuesday, May 21, 2002 11:51 PM Subject: Re: [manet] Fixed Vs Ad-hoc network question? > At 12:43 PM 5/21/2002 +0000, Daniel Oldham wrote: > >For every ad-hoc network is there an equivalent > >fixed structure network? > > there is for every static instance of an ad-hoc network. If it changes and > freezes, there is another. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 22 10:46:14 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 KAA05233 for ; Wed, 22 May 2002 10:46:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24946; Wed, 22 May 2002 09:50:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA11781 for ; Fri, 17 May 2002 20:25:30 -0400 (EDT) Received: from raisin.bbn.com (raisin.BBN.COM [128.89.80.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14570 for ; Fri, 17 May 2002 20:25:14 -0400 (EDT) Received: from bbn.com (localhost.bbn.com [127.0.0.1]) by raisin.bbn.com (8.11.1/8.11.1) with ESMTP id g4I0Eqx32150; Fri, 17 May 2002 20:14:56 -0400 (EDT) (envelope-from csantiva@bbn.com) Message-ID: <3CE59CFC.92B370B1@bbn.com> Date: Fri, 17 May 2002 20:14:52 -0400 From: Cesar Santivanez Organization: BBN Technologies (a Verizon's unit) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: haas@ece.cornell.edu CC: Charlie Perkins , "Nast, Douglas P" , manet@ietf.org Subject: Re: [manet] Dumb Question? References: Content-Type: multipart/mixed; boundary="------------A4C8300D10F2E4831D1A0944" 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 This is a multi-part message in MIME format. --------------A4C8300D10F2E4831D1A0944 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, When evaluating a routing protocol performance, we need to consider not only the network size but also the traffic and mobility rate. Also, the traffic distribution is of paramount importance, since uniformly distributed traffic will favor proactive approaches while a more reduced sets of destination (in a period of time) will favor reactive approahes. Also, not only the impact of the control overhead need to be considered, but also the effect of route information latency, etc. in route optimality, and the final efferct of route sub-optimality in th esystem performance. We have developed a methodology for the study of scalability of ad hoc networks, defining the total overhead as the metric that encompass the effect of control overhead (either proactive updates or reactive route discovery packets) and the effect of sub-optimal routes (more transmissions that required. We applied out methodology for comparing several ad-hoc routing protocols, including standard link state, hierarchical link state, ZRP, and Hazy Sighted Link State (HSLS). Both, the methodology and our results (based on a set of realistics assumptions, of which the more controversial may be the uniform traffci distribution ;-) can be found in our upcoming INFOCOM'02 paper: C. Santivanez, B. McDonald, I. Stavrakakis, and R. Ramanathan., "On the Scalability of Ad Hoc Routing Protocols," to appear in Proceedings of IEEE INFOCOM'02, New York, June, 2002. A copy of this paper may be found at : http://www.ir.bbn.com/documents/articles/index.html Among other things, we found that ZRP - by being able to dynamically adapts its zone size reduced de rate of increase of overhead w.r.t. network size (N) from N^2 for pure proactive or reactive approaches, to N^1.66. Multilevel Hierarchical link state, further reduced the overhead to a little more than N^1.5, and HSLS by balancing the control overhead and the negative impact of route innacuracies reduced the total overhead to N^1.5. We noted that ZRP behaves as a 2-level hierarchy system, while multi-level Hierarchical link state and HSLS behave as having as many level as needed. The results also relate total overhead to traffic intensity (assuming uniformly distributed source-destinations) and mobility. An important conclusion of these results is that as mobility increases, it pays off to allow the control overhead to increase, but not linearly with the rate of link changes, that is, to allow nodes to have a distorted view of the network. Also, as traffic rate increases, it pays off to let the control overhead to increase as well, since the quality of the routes become more important as these routes are used more intensively ... I hope these results will help the discussion ... Cesar haas@ece.cornell.edu wrote: > Hi Charlie, > > Well, I agree with you that since pure on-demand protocol is a > special case of a hybrid scheme, such as ZRP, a hybrid scheme > performance is bound to produce at least as good results as any of the two > extremes - purely proactive and purely proactive schemes. In fact, our > study (for example, the paper in your book) shows that it can reduce the > control traffic to a small fraction of those two extremes. These results > have been confirmed both analytically and through simulation. > > Your point regarding scalability is a very valid point. We are currently > evaluating the scalability of the hybrid (ZRP) approach for thousands to > tens of thousands of nodes. This is not a trivial task, taking into the > account the simulation runtime duration. But the preliminary results are > *very* encouraging, to say the least. Stay tuned .... > > Zygmunt. > ==-=-===== > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > Wireless Networks Laboratory http://wnl.ece.cornell.edu > School of Electrical Engineering > Cornell University tel: +1-607-255-3454 > 323 Frank Rhodes Hall fax: +1-607-255-9072 > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > U.S.A > WNL web page: http://wnl.ece.cornell.edu > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > On Wed, 15 May 2002, Charlie Perkins wrote: > > > > > Hello Douglas, > > > > We have results for scaling AODV up to 10,000 nodes. > > We know that we can do better by improving the packet > > delivery ratio. In a few weeks, I reckon we'll have some > > specific directions for algorithm improvement. > > > > ZDP is theoretically able to do better, simply because it > > admits as special cases all on-demand protocols. However, > > I have never seen any results showing ZDP on a network > > of 10,000 nodes (simulated). > > > > Regards, > > Charlie P. > > > > > > "Nast, Douglas P" wrote: > > > > > Zygmunt, > > > > > > I think your idea is very interesting, as it addresses the latency issue for > > > routes in your zone (which is important in military apps), and offers the > > > promise of scalability: The reactive inter-zone idea is reminiscent of the > > > hierarchical architecture of OSPF, which essentially operates LS intra-area > > > and DV inter-area. How would you contrast your zone idea to OSPF areas? > > > > > > Doug Nast, Boeing > > > > > > -----Original Message----- > > > From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] > > > Sent: Tuesday, May 14, 2002 11:56 AM > > > To: Mullen, John P. (Contractor) > > > Cc: manet@ietf.org > > > Subject: RE: [manet] Dumb Question? > > > > > > Hi John, > > > > > > > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > > > > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser > > > speculates > > > > on p. 33 that it is unlikely a single protocol will be able to operate > > > > efficiently over the full range of conditions under which a military MANET > > > > must operate. If he is correct, the issue may never be fully resolved. > > > > > > Yes, I read this book too (:-) ... > > > > > > I hate to bring this point over again ... and self-promote our work ... > > > but the issue of "efficient operation over a wide range of conditions" can > > > and should be addressed by a *hybrid* routing scheme, where the "proactive" > > > and "reactive" behavior are "mixed" in the amounts that match these > > > operational conditions. In other words, *adaptivity* is the key issue > > > here. > > > > > > One such an example of a hybrid scheme is (of course, you have guessed) > > > the ZRP protocol, in which the amount of proactive vs reactive behavior is > > > *dynamically* adjusted through a single parameter - the zone radius. > > > > > > Now imagine this - one could use the AODV (or DSR, or your favorite > > > reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or > > > your favorite proactive protocol) as the proactive protocol in ZRP (I > > > tried to offend the smallest number of people here (;-)). This is why ZRP > > > is a framework for ... for exactly this - for "efficient operation over a > > > wide range of conditions". So, maybe, there is a hope to resolve this > > > issue after all. > > > > > > Zygmunt. > > > ==-=-===== > > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > > > Wireless Networks Laboratory http://wnl.ece.cornell.edu > > > School of Electrical Engineering > > > Cornell University tel: +1-607-255-3454 > > > 323 Frank Rhodes Hall fax: +1-607-255-9072 > > > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > > > U.S.A > > > WNL web page: http://wnl.ece.cornell.edu > > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet --------------A4C8300D10F2E4831D1A0944 Content-Type: text/x-vcard; charset=us-ascii; name="csantiva.vcf" Content-Description: Card for Cesar Santivanez Content-Disposition: attachment; filename="csantiva.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Santivanez;Cesar x-mozilla-html:FALSE org:BBN Technologies (A Verizon's unit);Internetwork research adr:;;;;;; version:2.1 email;internet:csantiva@bbn.com title:Network Scientist x-mozilla-cpt:;-29376 fn:Cesar Santivanez end:vcard --------------A4C8300D10F2E4831D1A0944-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 22 10:46:44 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 KAA05241 for ; Wed, 22 May 2002 10:46:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29052 for manet-archive@odin.ietf.org; Wed, 22 May 2002 10:46:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24946; Wed, 22 May 2002 09:50:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA11781 for ; Fri, 17 May 2002 20:25:30 -0400 (EDT) Received: from raisin.bbn.com (raisin.BBN.COM [128.89.80.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14570 for ; Fri, 17 May 2002 20:25:14 -0400 (EDT) Received: from bbn.com (localhost.bbn.com [127.0.0.1]) by raisin.bbn.com (8.11.1/8.11.1) with ESMTP id g4I0Eqx32150; Fri, 17 May 2002 20:14:56 -0400 (EDT) (envelope-from csantiva@bbn.com) Message-ID: <3CE59CFC.92B370B1@bbn.com> Date: Fri, 17 May 2002 20:14:52 -0400 From: Cesar Santivanez Organization: BBN Technologies (a Verizon's unit) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: haas@ece.cornell.edu CC: Charlie Perkins , "Nast, Douglas P" , manet@ietf.org Subject: Re: [manet] Dumb Question? References: Content-Type: multipart/mixed; boundary="------------A4C8300D10F2E4831D1A0944" 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 This is a multi-part message in MIME format. --------------A4C8300D10F2E4831D1A0944 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, When evaluating a routing protocol performance, we need to consider not only the network size but also the traffic and mobility rate. Also, the traffic distribution is of paramount importance, since uniformly distributed traffic will favor proactive approaches while a more reduced sets of destination (in a period of time) will favor reactive approahes. Also, not only the impact of the control overhead need to be considered, but also the effect of route information latency, etc. in route optimality, and the final efferct of route sub-optimality in th esystem performance. We have developed a methodology for the study of scalability of ad hoc networks, defining the total overhead as the metric that encompass the effect of control overhead (either proactive updates or reactive route discovery packets) and the effect of sub-optimal routes (more transmissions that required. We applied out methodology for comparing several ad-hoc routing protocols, including standard link state, hierarchical link state, ZRP, and Hazy Sighted Link State (HSLS). Both, the methodology and our results (based on a set of realistics assumptions, of which the more controversial may be the uniform traffci distribution ;-) can be found in our upcoming INFOCOM'02 paper: C. Santivanez, B. McDonald, I. Stavrakakis, and R. Ramanathan., "On the Scalability of Ad Hoc Routing Protocols," to appear in Proceedings of IEEE INFOCOM'02, New York, June, 2002. A copy of this paper may be found at : http://www.ir.bbn.com/documents/articles/index.html Among other things, we found that ZRP - by being able to dynamically adapts its zone size reduced de rate of increase of overhead w.r.t. network size (N) from N^2 for pure proactive or reactive approaches, to N^1.66. Multilevel Hierarchical link state, further reduced the overhead to a little more than N^1.5, and HSLS by balancing the control overhead and the negative impact of route innacuracies reduced the total overhead to N^1.5. We noted that ZRP behaves as a 2-level hierarchy system, while multi-level Hierarchical link state and HSLS behave as having as many level as needed. The results also relate total overhead to traffic intensity (assuming uniformly distributed source-destinations) and mobility. An important conclusion of these results is that as mobility increases, it pays off to allow the control overhead to increase, but not linearly with the rate of link changes, that is, to allow nodes to have a distorted view of the network. Also, as traffic rate increases, it pays off to let the control overhead to increase as well, since the quality of the routes become more important as these routes are used more intensively ... I hope these results will help the discussion ... Cesar haas@ece.cornell.edu wrote: > Hi Charlie, > > Well, I agree with you that since pure on-demand protocol is a > special case of a hybrid scheme, such as ZRP, a hybrid scheme > performance is bound to produce at least as good results as any of the two > extremes - purely proactive and purely proactive schemes. In fact, our > study (for example, the paper in your book) shows that it can reduce the > control traffic to a small fraction of those two extremes. These results > have been confirmed both analytically and through simulation. > > Your point regarding scalability is a very valid point. We are currently > evaluating the scalability of the hybrid (ZRP) approach for thousands to > tens of thousands of nodes. This is not a trivial task, taking into the > account the simulation runtime duration. But the preliminary results are > *very* encouraging, to say the least. Stay tuned .... > > Zygmunt. > ==-=-===== > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > Wireless Networks Laboratory http://wnl.ece.cornell.edu > School of Electrical Engineering > Cornell University tel: +1-607-255-3454 > 323 Frank Rhodes Hall fax: +1-607-255-9072 > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > U.S.A > WNL web page: http://wnl.ece.cornell.edu > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > On Wed, 15 May 2002, Charlie Perkins wrote: > > > > > Hello Douglas, > > > > We have results for scaling AODV up to 10,000 nodes. > > We know that we can do better by improving the packet > > delivery ratio. In a few weeks, I reckon we'll have some > > specific directions for algorithm improvement. > > > > ZDP is theoretically able to do better, simply because it > > admits as special cases all on-demand protocols. However, > > I have never seen any results showing ZDP on a network > > of 10,000 nodes (simulated). > > > > Regards, > > Charlie P. > > > > > > "Nast, Douglas P" wrote: > > > > > Zygmunt, > > > > > > I think your idea is very interesting, as it addresses the latency issue for > > > routes in your zone (which is important in military apps), and offers the > > > promise of scalability: The reactive inter-zone idea is reminiscent of the > > > hierarchical architecture of OSPF, which essentially operates LS intra-area > > > and DV inter-area. How would you contrast your zone idea to OSPF areas? > > > > > > Doug Nast, Boeing > > > > > > -----Original Message----- > > > From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] > > > Sent: Tuesday, May 14, 2002 11:56 AM > > > To: Mullen, John P. (Contractor) > > > Cc: manet@ietf.org > > > Subject: RE: [manet] Dumb Question? > > > > > > Hi John, > > > > > > > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > > > > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser > > > speculates > > > > on p. 33 that it is unlikely a single protocol will be able to operate > > > > efficiently over the full range of conditions under which a military MANET > > > > must operate. If he is correct, the issue may never be fully resolved. > > > > > > Yes, I read this book too (:-) ... > > > > > > I hate to bring this point over again ... and self-promote our work ... > > > but the issue of "efficient operation over a wide range of conditions" can > > > and should be addressed by a *hybrid* routing scheme, where the "proactive" > > > and "reactive" behavior are "mixed" in the amounts that match these > > > operational conditions. In other words, *adaptivity* is the key issue > > > here. > > > > > > One such an example of a hybrid scheme is (of course, you have guessed) > > > the ZRP protocol, in which the amount of proactive vs reactive behavior is > > > *dynamically* adjusted through a single parameter - the zone radius. > > > > > > Now imagine this - one could use the AODV (or DSR, or your favorite > > > reactive protocol) as the reactive protocol in ZRP and OLSR (or TBRPF, or > > > your favorite proactive protocol) as the proactive protocol in ZRP (I > > > tried to offend the smallest number of people here (;-)). This is why ZRP > > > is a framework for ... for exactly this - for "efficient operation over a > > > wide range of conditions". So, maybe, there is a hope to resolve this > > > issue after all. > > > > > > Zygmunt. > > > ==-=-===== > > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > > > Wireless Networks Laboratory http://wnl.ece.cornell.edu > > > School of Electrical Engineering > > > Cornell University tel: +1-607-255-3454 > > > 323 Frank Rhodes Hall fax: +1-607-255-9072 > > > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > > > U.S.A > > > WNL web page: http://wnl.ece.cornell.edu > > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet --------------A4C8300D10F2E4831D1A0944 Content-Type: text/x-vcard; charset=us-ascii; name="csantiva.vcf" Content-Description: Card for Cesar Santivanez Content-Disposition: attachment; filename="csantiva.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Santivanez;Cesar x-mozilla-html:FALSE org:BBN Technologies (A Verizon's unit);Internetwork research adr:;;;;;; version:2.1 email;internet:csantiva@bbn.com title:Network Scientist x-mozilla-cpt:;-29376 fn:Cesar Santivanez end:vcard --------------A4C8300D10F2E4831D1A0944-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 22 12:39:50 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 MAA17407 for ; Wed, 22 May 2002 12:39:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03572; Wed, 22 May 2002 11:46:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03493 for ; Wed, 22 May 2002 11:46:26 -0400 (EDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13118 for ; Wed, 22 May 2002 11:46:06 -0400 (EDT) Received: from frink.ece.udel.edu by mail.eecis.udel.edu id aa05491; 22 May 2002 11:45 EDT Date: Wed, 22 May 2002 11:45:51 -0400 (EDT) From: Liangping Ma To: manet@ietf.org MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Which approach better for QoS implementation? 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 Hi, everyone, I am implementing INSIGNIA, a type of QoS, in glomosim. The appraoch is to change the behavior of the IP functionality of each node so that INSIGNIA can be supported. The problem is that I do not want any application (for exmaple, ftps) to be served with INSIGNIA. Instead, the user can configure which nodes to use INSIGNIA to their applications, and which nodes to use Best Effort (ordinary) service. One way is that the user specifies the type of service to be used in the packets from the application layer, and then the lower layers snoop this information. The other way is to explictly let the IP layers of specific nodes (for example, client nodes for ftps) to initiate INSIGNIA, and everything in the application and transport layer remains the same. If I adopt the first approach, I have to change the application layer, and the transport layer. For example, I may need to create a type of application called INSIGNIA ftp. For the second approach, no change is made in layers above IP, and the QoS is exclusively a task of the IP layer. But the user has to give commands to the IP layers of some nodes. This may cause some problems in configuration (config.in). Which approach is easier to implement for simulation? And which would be used in the real world? Thanks! Sincerely yours, Liangping Ma _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 22 12:39:50 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 MAA17416 for ; Wed, 22 May 2002 12:39:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA08052 for manet-archive@odin.ietf.org; Wed, 22 May 2002 12:40:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03572; Wed, 22 May 2002 11:46:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03493 for ; Wed, 22 May 2002 11:46:26 -0400 (EDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13118 for ; Wed, 22 May 2002 11:46:06 -0400 (EDT) Received: from frink.ece.udel.edu by mail.eecis.udel.edu id aa05491; 22 May 2002 11:45 EDT Date: Wed, 22 May 2002 11:45:51 -0400 (EDT) From: Liangping Ma To: manet@ietf.org MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Which approach better for QoS implementation? 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 Hi, everyone, I am implementing INSIGNIA, a type of QoS, in glomosim. The appraoch is to change the behavior of the IP functionality of each node so that INSIGNIA can be supported. The problem is that I do not want any application (for exmaple, ftps) to be served with INSIGNIA. Instead, the user can configure which nodes to use INSIGNIA to their applications, and which nodes to use Best Effort (ordinary) service. One way is that the user specifies the type of service to be used in the packets from the application layer, and then the lower layers snoop this information. The other way is to explictly let the IP layers of specific nodes (for example, client nodes for ftps) to initiate INSIGNIA, and everything in the application and transport layer remains the same. If I adopt the first approach, I have to change the application layer, and the transport layer. For example, I may need to create a type of application called INSIGNIA ftp. For the second approach, no change is made in layers above IP, and the QoS is exclusively a task of the IP layer. But the user has to give commands to the IP layers of some nodes. This may cause some problems in configuration (config.in). Which approach is easier to implement for simulation? And which would be used in the real world? Thanks! Sincerely yours, Liangping Ma _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 22 15:00:31 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 PAA25449 for ; Wed, 22 May 2002 15:00:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12544; Wed, 22 May 2002 14:05:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12511 for ; Wed, 22 May 2002 14:05:13 -0400 (EDT) Received: from mail.emu.edu.tr (mail.emu.edu.tr [193.140.41.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22435 for ; Wed, 22 May 2002 14:04:36 -0400 (EDT) Received: from romeoe (207.12.185.138 [207.12.185.138]) by mail.emu.edu.tr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LBK7GV4T; Wed, 22 May 2002 21:03:57 +0300 From: "Evren CAVDIR" To: "Manet List" Date: Wed, 22 May 2002 21:04:37 +0300 Message-ID: <000501c201bb$25c6c190$8ab90ccf@romeoe> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C201D4.4B13F990" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [manet] Simulation problem 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 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C201D4.4B13F990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all; =20 Is there anybody who has the simulation code of DSR protocol in Glomosim/Parsec? I need it urgently for my thesis research. Thank you for your cooperation. =20 Evren =C7AVDIR Research Assistant Computer Engineering Department Eastern Mediterranean University Famagusta Mersin 10 Turkey +90-392-630-2831 =20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.362 / Virus Database: 199 - Release Date: 07.05.2002 =20 ------=_NextPart_000_0006_01C201D4.4B13F990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello all;

 

Is there anybody who has the simulation code of DSR = protocol in Glomosim/Parsec? I need it urgently for = my thesis research. Thank you for your cooperation.

 

Evren =C7AVDIR

Research = Assistant

Computer Engineering = Department

Eastern = Mediterranean = University

Famagusta Mersin 10 Turkey

+90-392-630-2831

 


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.362 / Virus Database: 199 - Release Date: 07.05.2002

------=_NextPart_000_0006_01C201D4.4B13F990-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 22 15:00:32 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 PAA25461 for ; Wed, 22 May 2002 15:00:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA16305 for manet-archive@odin.ietf.org; Wed, 22 May 2002 15:00:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12544; Wed, 22 May 2002 14:05:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12511 for ; Wed, 22 May 2002 14:05:13 -0400 (EDT) Received: from mail.emu.edu.tr (mail.emu.edu.tr [193.140.41.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22435 for ; Wed, 22 May 2002 14:04:36 -0400 (EDT) Received: from romeoe (207.12.185.138 [207.12.185.138]) by mail.emu.edu.tr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LBK7GV4T; Wed, 22 May 2002 21:03:57 +0300 From: "Evren CAVDIR" To: "Manet List" Date: Wed, 22 May 2002 21:04:37 +0300 Message-ID: <000501c201bb$25c6c190$8ab90ccf@romeoe> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C201D4.4B13F990" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [manet] Simulation problem 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 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C201D4.4B13F990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all; =20 Is there anybody who has the simulation code of DSR protocol in Glomosim/Parsec? I need it urgently for my thesis research. Thank you for your cooperation. =20 Evren =C7AVDIR Research Assistant Computer Engineering Department Eastern Mediterranean University Famagusta Mersin 10 Turkey +90-392-630-2831 =20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.362 / Virus Database: 199 - Release Date: 07.05.2002 =20 ------=_NextPart_000_0006_01C201D4.4B13F990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello all;

 

Is there anybody who has the simulation code of DSR = protocol in Glomosim/Parsec? I need it urgently for = my thesis research. Thank you for your cooperation.

 

Evren =C7AVDIR

Research = Assistant

Computer Engineering = Department

Eastern = Mediterranean = University

Famagusta Mersin 10 Turkey

+90-392-630-2831

 


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.362 / Virus Database: 199 - Release Date: 07.05.2002

------=_NextPart_000_0006_01C201D4.4B13F990-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 23 19:55:29 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 TAA00940 for ; Thu, 23 May 2002 19:55:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25048; Thu, 23 May 2002 19:19:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25023 for ; Thu, 23 May 2002 19:19:53 -0400 (EDT) Received: from pimout2-int.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00120 for ; Thu, 23 May 2002 19:19:32 -0400 (EDT) Received: from uta.edu (adsl-65-71-198-237.dsl.eulstx.swbell.net [65.71.198.237]) by pimout2-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g4NNJZ279818 for ; Thu, 23 May 2002 19:19:35 -0400 Message-ID: <3CED7906.6D695283@uta.edu> Date: Thu, 23 May 2002 18:19:34 -0500 From: Gergely Zaruba X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "'manet@ietf.org'" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] CfP for Hawaiian conference - minitrack on WLANs and WPANs 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 Content-Transfer-Encoding: 7bit Dear Colleagues, (We apologize if you receive multiple copies.) Please feel free to distribute the below CfP among colleagues, interested parties, and related lists. Best Regards, Sajal Das, Gergely Zaruba and Kalyan Basu ==================================================================== CALL FOR PAPERS HICSS-36 Minitrack on WIRELESS LANs AND PANs http://crystal.uta.edu/~zaruba/hicss36/ Part of the Software Technology Track Thirty-sixth Annual HAWAI'I INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES January 6 - 9, 2003, Hilton Waikoloa Village on the Big Island of Hawaii --------------------------------------------------------------------- Full Papers due: June 1, 2002 ===================================================================== Minitrack Co-Chairs and Technical Committee * Sajal K. Das * Gergely V. Zaruba * Kalyan Basu Center for Research in Wireless Mobility and Networking (CReWMaN) Department of Computer Science and Engineering (CSE@UTA) The University of Texas at Arlington Email: {das,zaruba,basu}@cse.uta.edu Overview: In the past quarter century we have seen the rollout of three generations of wireless cellular systems attracting end-users by providing efficient mobile communications. On another front wireless technology became an important component in providing networking infrastructure for localized data delivery. This later revolution was made possible by the induction of new networking technologies and paradigms, such as wireless local area networks (WLAN) and wireless personal area networks (WPAN). Wireless personal area networks (WPANs) are short to very short-range (from a couple centimeters to a couple of meters) wireless networks that can be used to exchange information between devices in the reach of a person. WPANs can be used to replace cables between computers and their peripherals, to establish communities helping people do their everyday chores making them more productive, or to establish location aware services. Wireless local area networks (WLANs) on the other hand provide with a larger transmission range. Although WLAN equipment usually carries the capability to be set up for ad hoc networking, the premier choice of deployment is yet a cellular like infrastructure mode to interface wireless users with the Internet. The best example representing WPANs is the recent industry standard: Bluetooth, other examples include Spike (for real time gaming - proprietary technology), and in the broad sense HomeRF. The IEEE 802 committee has also realized the importance of short-range wireless networking and initiated the establishment of the IEEE 802.15 working group to standardize protocols and interfaces for wireless personal area networking. For WLANs the most well known representatives are based on the standards IEEE802.11 and HiperLAN with all their different variations. One key issue of the feasibility of WPANs is the cost of the chips enabling the actual wireless data transfer. Companies developing Bluetooth chips claim, that in the near future complex one-chip solutions of the Bluetooth specification will be available in the $5 price range. With this target price it is predicted that not only will most PDAs, phones, laptops include such technology but that the number of small WPAN enabled devices (e.g., pens, cameras, headsets, various sensors) will soon outnumber the computers on the Internet. Another key issue is the inter-working of wireless technologies to create heterogeneous wireless networks. For instance, WPANs and WLANs will enable an extension of the third generation (3G) cellular networks (i.e., UMTS and cdma2000) into devices without direct cellular access. Moreover, devices interconnected in a WPAN may be able to utilize a combination of 3G access and WLAN access by selecting the access that is best for the moment. In such networks 3G, WLAN and WPAN technologies do not compete against each other but enable the user to select the best connectivity for his/her purposes. We expect that the availability of a cheap short-range wireless technology will further fuel research and development in what, where and most importantly how WLAN and WPAN technologies could be used for. Scope: The minitrack will concentrate on completed or ongoing research in the area of wireless local area networking and wireless personal area networking (excluding manufacturing). Areas of interest include but are not limited to research in: * QoS provisioning in WLANs and WPANs * TCP performance of WLANs and WPANs * Bluetooth for ad hoc networks (scatternets) * IP over Bluetooth * Bluetooth performance evaluation * Routing in Bluetooth scatternets * Security issues of WPANs and WLANs * Mobility management and seamless integration of WLANs and PANs * Heterogeneous wireless infrastructures employing WLANS and/or WPANs * Interoperability, interference and co-existence issues * WPANs vs. WLANs * Protocols tailored to WLANs and WPANs * Caching in WLANs and WPANs * Service discovery using WLANs and WPANs Important Deadlines in 2002: * March 31, 2002 Abstracts submitted for guidance and indication of appropriate content. * June 1, 2002 Full papers submitted to Minitrack Chairs. Contact minitrack chairs for submission instructions. * August 31, 2002 Notice of acceptance or rejections of papers sent to Authors by Minitrack Chairs. * October 1, 2002 Accepted manuscripts submitted electronically to the publisher of the conference proceedings. At least one author of each accepted paper must register to attend the conference by this date. Registration cancellations after this date may result in the paper being pulled from the Proceedings prior to printing. See conference web site for registration fee refund policy. NOTE: Because HICSS is a nonprofit activity funded entirely by registration fees, all participants and speakers are expected to have their university/organization bear the costs of their expenses and registration. HICSS is not able to subsidize registrations or offer reduced fees. Instructions for the Authors: 1. Contact Gergely Zaruba in advance for specific submission instructions. Otherwise, submit six (6) copies of the full paper, consisting of 22-26 double- spaced pages, including diagrams, directly to Gergely Zaruba. (NOTE: The final paper will be 10 pages, double-column, single-spaced.) 2. Do not submit the manuscript to more than one Minitrack Chair. Papers should contain original material and not be previously published, or currently submitted for consideration elsewhere. 3. Each paper must have a title page to include title of the paper, full name of all authors, and complete addresses including affiliation(s), telephone number(s), and e-mail address(es). 4. The first page of the manuscript should include only the title and a 300-word abstract of the paper. 5. Individuals interested in refereeing papers should contact the minitrack chairs directly. 6. If you have more questions or want to find out more about other minitracks in the track, please go to the Software Technology Track homepage. Other Useful Information: Tracks at HICSS-36 * Collaboration Systems; Co-Chairs: Jay Nunamaker; Email: nunamaker@bpa.arizona.edu and Robert O. Briggs; Email: bbriggs@GroupSystems.com * Complex Systems; Chair: Robert Thomas; Email: rjt1@cornell.edu * Decision Tech. for Management; Chair: Dan Dolk; Email: dolker@redshift.com * Digital Documents and Media; Chair: Michael Shepherd; Email: shepherd@cs.dal.ca * Emerging Technologies; Co-Chairs Ralph H. Sprague; Email: sprague@hawaii.edu and Hesham El-Rewini; Email: rewini@engr.smu.edu * Information Technology in Health Care; Chair: William Chismar; Email: chismar@cba.hawaii.edu * Internet & the Digital Economy; Co-Chairs: David King; Email: dave@comshare.com and Alan Dennis; Email: ardennis@indiana.edu * Organizational Systems & Tech.; Chair: Hugh Watson; Email: hwatson@uga.edu * Software Technology; Chair: Hesham El-Rewini; Email: rewini@engr.smu.edu HICSS conferences are devoted to advances in the information, computer, and system sciences, and encompass developments in both theory and practice. Invited papers may be theoretical, conceptual, tutorial or descriptive in nature. Submissions undergo a peer referee process and those selected for presentation will be published in the Conference Proceedings. Submissions must not have been previously published. For the latest information visit the HICSS web site at: http://www.hicss.hawaii.edu Conference Administration * Ralph Sprague, Conference Chair Email: sprague@hawaii.edu * Eileen Dennis, Track Administrator Email: eidennis@indiana.edu Tel: 1-812-331-0551 Fax: 1-812-331-0564 * Sandra Laney, Conference Administrator Email: hicss@hawaii.edu Tel: 1-808-956-3251 Fax: 1-808-956-5759 2003 HICSS-36 Conference Venue Hilton Waikoloa Village on the Big Island of Hawaii 425 Waikoloa Beach Drive Waikoloa, Hawaii 96738 Tel: 1-808-886-1234 Fax: 1-808-886-2900 www.hiltonwaikoloavillage.com -- *********************************************************** Gergely V. Zaruba Ph.D. C.S. zaruba@ieee.org Assistant Professor Computer Science and Engineering Dept. Center for Research in Wireless Mobility and Networking The University of Texas at Arlington phone:(817) 272 3602 *********************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu May 23 19:55:30 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 TAA00950 for ; Thu, 23 May 2002 19:55:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA26382 for manet-archive@odin.ietf.org; Thu, 23 May 2002 19:55:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25048; Thu, 23 May 2002 19:19:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25023 for ; Thu, 23 May 2002 19:19:53 -0400 (EDT) Received: from pimout2-int.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00120 for ; Thu, 23 May 2002 19:19:32 -0400 (EDT) Received: from uta.edu (adsl-65-71-198-237.dsl.eulstx.swbell.net [65.71.198.237]) by pimout2-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g4NNJZ279818 for ; Thu, 23 May 2002 19:19:35 -0400 Message-ID: <3CED7906.6D695283@uta.edu> Date: Thu, 23 May 2002 18:19:34 -0500 From: Gergely Zaruba X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "'manet@ietf.org'" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] CfP for Hawaiian conference - minitrack on WLANs and WPANs 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 Content-Transfer-Encoding: 7bit Dear Colleagues, (We apologize if you receive multiple copies.) Please feel free to distribute the below CfP among colleagues, interested parties, and related lists. Best Regards, Sajal Das, Gergely Zaruba and Kalyan Basu ==================================================================== CALL FOR PAPERS HICSS-36 Minitrack on WIRELESS LANs AND PANs http://crystal.uta.edu/~zaruba/hicss36/ Part of the Software Technology Track Thirty-sixth Annual HAWAI'I INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES January 6 - 9, 2003, Hilton Waikoloa Village on the Big Island of Hawaii --------------------------------------------------------------------- Full Papers due: June 1, 2002 ===================================================================== Minitrack Co-Chairs and Technical Committee * Sajal K. Das * Gergely V. Zaruba * Kalyan Basu Center for Research in Wireless Mobility and Networking (CReWMaN) Department of Computer Science and Engineering (CSE@UTA) The University of Texas at Arlington Email: {das,zaruba,basu}@cse.uta.edu Overview: In the past quarter century we have seen the rollout of three generations of wireless cellular systems attracting end-users by providing efficient mobile communications. On another front wireless technology became an important component in providing networking infrastructure for localized data delivery. This later revolution was made possible by the induction of new networking technologies and paradigms, such as wireless local area networks (WLAN) and wireless personal area networks (WPAN). Wireless personal area networks (WPANs) are short to very short-range (from a couple centimeters to a couple of meters) wireless networks that can be used to exchange information between devices in the reach of a person. WPANs can be used to replace cables between computers and their peripherals, to establish communities helping people do their everyday chores making them more productive, or to establish location aware services. Wireless local area networks (WLANs) on the other hand provide with a larger transmission range. Although WLAN equipment usually carries the capability to be set up for ad hoc networking, the premier choice of deployment is yet a cellular like infrastructure mode to interface wireless users with the Internet. The best example representing WPANs is the recent industry standard: Bluetooth, other examples include Spike (for real time gaming - proprietary technology), and in the broad sense HomeRF. The IEEE 802 committee has also realized the importance of short-range wireless networking and initiated the establishment of the IEEE 802.15 working group to standardize protocols and interfaces for wireless personal area networking. For WLANs the most well known representatives are based on the standards IEEE802.11 and HiperLAN with all their different variations. One key issue of the feasibility of WPANs is the cost of the chips enabling the actual wireless data transfer. Companies developing Bluetooth chips claim, that in the near future complex one-chip solutions of the Bluetooth specification will be available in the $5 price range. With this target price it is predicted that not only will most PDAs, phones, laptops include such technology but that the number of small WPAN enabled devices (e.g., pens, cameras, headsets, various sensors) will soon outnumber the computers on the Internet. Another key issue is the inter-working of wireless technologies to create heterogeneous wireless networks. For instance, WPANs and WLANs will enable an extension of the third generation (3G) cellular networks (i.e., UMTS and cdma2000) into devices without direct cellular access. Moreover, devices interconnected in a WPAN may be able to utilize a combination of 3G access and WLAN access by selecting the access that is best for the moment. In such networks 3G, WLAN and WPAN technologies do not compete against each other but enable the user to select the best connectivity for his/her purposes. We expect that the availability of a cheap short-range wireless technology will further fuel research and development in what, where and most importantly how WLAN and WPAN technologies could be used for. Scope: The minitrack will concentrate on completed or ongoing research in the area of wireless local area networking and wireless personal area networking (excluding manufacturing). Areas of interest include but are not limited to research in: * QoS provisioning in WLANs and WPANs * TCP performance of WLANs and WPANs * Bluetooth for ad hoc networks (scatternets) * IP over Bluetooth * Bluetooth performance evaluation * Routing in Bluetooth scatternets * Security issues of WPANs and WLANs * Mobility management and seamless integration of WLANs and PANs * Heterogeneous wireless infrastructures employing WLANS and/or WPANs * Interoperability, interference and co-existence issues * WPANs vs. WLANs * Protocols tailored to WLANs and WPANs * Caching in WLANs and WPANs * Service discovery using WLANs and WPANs Important Deadlines in 2002: * March 31, 2002 Abstracts submitted for guidance and indication of appropriate content. * June 1, 2002 Full papers submitted to Minitrack Chairs. Contact minitrack chairs for submission instructions. * August 31, 2002 Notice of acceptance or rejections of papers sent to Authors by Minitrack Chairs. * October 1, 2002 Accepted manuscripts submitted electronically to the publisher of the conference proceedings. At least one author of each accepted paper must register to attend the conference by this date. Registration cancellations after this date may result in the paper being pulled from the Proceedings prior to printing. See conference web site for registration fee refund policy. NOTE: Because HICSS is a nonprofit activity funded entirely by registration fees, all participants and speakers are expected to have their university/organization bear the costs of their expenses and registration. HICSS is not able to subsidize registrations or offer reduced fees. Instructions for the Authors: 1. Contact Gergely Zaruba in advance for specific submission instructions. Otherwise, submit six (6) copies of the full paper, consisting of 22-26 double- spaced pages, including diagrams, directly to Gergely Zaruba. (NOTE: The final paper will be 10 pages, double-column, single-spaced.) 2. Do not submit the manuscript to more than one Minitrack Chair. Papers should contain original material and not be previously published, or currently submitted for consideration elsewhere. 3. Each paper must have a title page to include title of the paper, full name of all authors, and complete addresses including affiliation(s), telephone number(s), and e-mail address(es). 4. The first page of the manuscript should include only the title and a 300-word abstract of the paper. 5. Individuals interested in refereeing papers should contact the minitrack chairs directly. 6. If you have more questions or want to find out more about other minitracks in the track, please go to the Software Technology Track homepage. Other Useful Information: Tracks at HICSS-36 * Collaboration Systems; Co-Chairs: Jay Nunamaker; Email: nunamaker@bpa.arizona.edu and Robert O. Briggs; Email: bbriggs@GroupSystems.com * Complex Systems; Chair: Robert Thomas; Email: rjt1@cornell.edu * Decision Tech. for Management; Chair: Dan Dolk; Email: dolker@redshift.com * Digital Documents and Media; Chair: Michael Shepherd; Email: shepherd@cs.dal.ca * Emerging Technologies; Co-Chairs Ralph H. Sprague; Email: sprague@hawaii.edu and Hesham El-Rewini; Email: rewini@engr.smu.edu * Information Technology in Health Care; Chair: William Chismar; Email: chismar@cba.hawaii.edu * Internet & the Digital Economy; Co-Chairs: David King; Email: dave@comshare.com and Alan Dennis; Email: ardennis@indiana.edu * Organizational Systems & Tech.; Chair: Hugh Watson; Email: hwatson@uga.edu * Software Technology; Chair: Hesham El-Rewini; Email: rewini@engr.smu.edu HICSS conferences are devoted to advances in the information, computer, and system sciences, and encompass developments in both theory and practice. Invited papers may be theoretical, conceptual, tutorial or descriptive in nature. Submissions undergo a peer referee process and those selected for presentation will be published in the Conference Proceedings. Submissions must not have been previously published. For the latest information visit the HICSS web site at: http://www.hicss.hawaii.edu Conference Administration * Ralph Sprague, Conference Chair Email: sprague@hawaii.edu * Eileen Dennis, Track Administrator Email: eidennis@indiana.edu Tel: 1-812-331-0551 Fax: 1-812-331-0564 * Sandra Laney, Conference Administrator Email: hicss@hawaii.edu Tel: 1-808-956-3251 Fax: 1-808-956-5759 2003 HICSS-36 Conference Venue Hilton Waikoloa Village on the Big Island of Hawaii 425 Waikoloa Beach Drive Waikoloa, Hawaii 96738 Tel: 1-808-886-1234 Fax: 1-808-886-2900 www.hiltonwaikoloavillage.com -- *********************************************************** Gergely V. Zaruba Ph.D. C.S. zaruba@ieee.org Assistant Professor Computer Science and Engineering Dept. Center for Research in Wireless Mobility and Networking The University of Texas at Arlington phone:(817) 272 3602 *********************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 23 20:35:44 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 UAA01758 for ; Thu, 23 May 2002 20:35:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27128; Thu, 23 May 2002 20:02:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27099 for ; Thu, 23 May 2002 20:02:20 -0400 (EDT) Received: from ep_mailout2 ([203.254.224.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01093 for ; Thu, 23 May 2002 20:01:58 -0400 (EDT) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GWL00I019734Y@mailout2.samsung.com> for manet@ietf.org; Fri, 24 May 2002 08:57:03 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GWL00HIB972H1@mailout2.samsung.com> for manet@ietf.org; Fri, 24 May 2002 08:57:02 +0900 (KST) Received: from zbin ([75.2.45.93]) by mmp1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GWL00A3J97Q6D@mmp1.samsung.com> for manet@ietf.org; Fri, 24 May 2002 08:57:26 +0900 (KST) Date: Fri, 24 May 2002 08:59:17 +0900 From: zb To: manet@ietf.org Message-id: <002001c202b5$d9aac9e0$5d2d024b@zbin> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: multipart/alternative; boundary="Boundary_(ID_AdqGcTniDMck8GjjMIj1Ww)" X-Priority: 3 X-MSMail-priority: Normal Subject: [manet] ad hoc network of HyperLAN2? 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 This is a multi-part message in MIME format. --Boundary_(ID_AdqGcTniDMck8GjjMIj1Ww) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT hi, Can anybody tell any paper on the ad hoc network of HyperLAN2? Is there any difference between the ad hoc network of HyperLAN2 and 802.11b? regards bin ************************************* Zhen Bin i-Networking lab, Samsung Advanced Institute of Technology, San14-1, NongSeo-ri, Kiheung-Eup, Yongin, Kyungki-do, 440600, Korea 82-31-2809569 (fax) 82-31-2809534 (o) 82-31-2122268 (h) ************************************* --Boundary_(ID_AdqGcTniDMck8GjjMIj1Ww) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
hi,
 
  Can anybody tell any paper on the ad hoc network of HyperLAN2? Is there any difference between the ad hoc network of HyperLAN2 and 802.11b?
 
regards
 
bin
*************************************
Zhen Bin
 
i-Networking lab,
Samsung Advanced Institute of Technology,
San14-1, NongSeo-ri, Kiheung-Eup,
Yongin, Kyungki-do, 440600, Korea
 
82-31-2809569 (fax)
82-31-2809534 (o)
82-31-2122268 (h)
*************************************
--Boundary_(ID_AdqGcTniDMck8GjjMIj1Ww)-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu May 23 20:35:45 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 UAA01767 for ; Thu, 23 May 2002 20:35:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA28912 for manet-archive@odin.ietf.org; Thu, 23 May 2002 20:36:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27128; Thu, 23 May 2002 20:02:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27099 for ; Thu, 23 May 2002 20:02:20 -0400 (EDT) Received: from ep_mailout2 ([203.254.224.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01093 for ; Thu, 23 May 2002 20:01:58 -0400 (EDT) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GWL00I019734Y@mailout2.samsung.com> for manet@ietf.org; Fri, 24 May 2002 08:57:03 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GWL00HIB972H1@mailout2.samsung.com> for manet@ietf.org; Fri, 24 May 2002 08:57:02 +0900 (KST) Received: from zbin ([75.2.45.93]) by mmp1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GWL00A3J97Q6D@mmp1.samsung.com> for manet@ietf.org; Fri, 24 May 2002 08:57:26 +0900 (KST) Date: Fri, 24 May 2002 08:59:17 +0900 From: zb To: manet@ietf.org Message-id: <002001c202b5$d9aac9e0$5d2d024b@zbin> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: multipart/alternative; boundary="Boundary_(ID_AdqGcTniDMck8GjjMIj1Ww)" X-Priority: 3 X-MSMail-priority: Normal Subject: [manet] ad hoc network of HyperLAN2? 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 This is a multi-part message in MIME format. --Boundary_(ID_AdqGcTniDMck8GjjMIj1Ww) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT hi, Can anybody tell any paper on the ad hoc network of HyperLAN2? Is there any difference between the ad hoc network of HyperLAN2 and 802.11b? regards bin ************************************* Zhen Bin i-Networking lab, Samsung Advanced Institute of Technology, San14-1, NongSeo-ri, Kiheung-Eup, Yongin, Kyungki-do, 440600, Korea 82-31-2809569 (fax) 82-31-2809534 (o) 82-31-2122268 (h) ************************************* --Boundary_(ID_AdqGcTniDMck8GjjMIj1Ww) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
hi,
 
  Can anybody tell any paper on the ad hoc network of HyperLAN2? Is there any difference between the ad hoc network of HyperLAN2 and 802.11b?
 
regards
 
bin
*************************************
Zhen Bin
 
i-Networking lab,
Samsung Advanced Institute of Technology,
San14-1, NongSeo-ri, Kiheung-Eup,
Yongin, Kyungki-do, 440600, Korea
 
82-31-2809569 (fax)
82-31-2809534 (o)
82-31-2122268 (h)
*************************************
--Boundary_(ID_AdqGcTniDMck8GjjMIj1Ww)-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu May 23 21:05:49 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 VAA02492 for ; Thu, 23 May 2002 21:05:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28808; Thu, 23 May 2002 20:34:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28751 for ; Thu, 23 May 2002 20:34:04 -0400 (EDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01728 for ; Thu, 23 May 2002 20:33:42 -0400 (EDT) Received: from frink.ece.udel.edu by mail.eecis.udel.edu id aa01537; 23 May 2002 20:33 EDT Date: Thu, 23 May 2002 20:33:45 -0400 (EDT) From: Liangping Ma To: Seoung-Bum Lee cc: manet@ietf.org, Seoungbum Lee MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: Re: [manet] Which approach better for QoS implementation? In-Reply-To: <000b01c20265$8cb28f60$93413b80@home2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hi, Seoung-Bum, Thanks for your reply! The INSIGNIA control information is in the IP option field. And every intermediate node is supposed to look into this field before deciding which protocol is to be used. This makes INSIGNIA transparent to any routing protocol. For this, I think all nodes should be enabled to support INSIGNIA. One more question about the calcualtion of rate of a UDP flow. In the latest swan paper, it says using weighted moving average on the "rates". But how to get the "rates"? Since the traffic is discrete, a fluid model does not fit it. I think we can only get approximated "rates". Maybe we can divide the packet size by the inter-arrival time, which is dynamic, to get an "instantaneous" rate. Then do averaging. Thanks! Liangping > Hello Lianping, > > I believe the first approach is the right approach. The second approach is > merely > a hack. It requires all nodes to be INSIGNIA-enabled to provide end-to-end > adaptive service. > > In actual imlementation, API of an application specifies the payload type > and > etc. For example, MPEG-2 video server may maps I-frame/B-frame/P-frame into > EQ/BQ with minimum and maximum resource requirement. If an application has > no > understanding of INSIGNIA, its resource/service requirements etc., only > best-effort service can be supported. > > QOS socket (which is API for INSIGNIA) runs on top of UDP or TCP transport, > so there's no need for any change in UDP/TCP. INSIGNIA is an IP layer > signaling > system. In order to support adaptive QOS, we also need some scheduling > (e.g. WFQ, CBQ, etc) and media access control (e.g. EDCF, etc). In fact we > need > support from application layer, transport layer, IP layer and MAC layer > in order to support QOS (even the adaptive QOS) in real world. > > - Seoung-Bum Lee > > ----- Original Message ----- > From: "Liangping Ma" > To: > Sent: Wednesday, May 22, 2002 11:45 AM > Subject: [manet] Which approach better for QoS implementation? > > > > Hi, everyone, > > > > I am implementing INSIGNIA, a type of QoS, in glomosim. The appraoch > > is to change the behavior of the IP functionality of each node so that > INSIGNIA > > can be supported. The problem is that I do not want any application (for > > exmaple, ftps) to be served with INSIGNIA. Instead, the user can configure > > which nodes to use INSIGNIA to their applications, and which nodes to use > > Best Effort (ordinary) service. One way is that the user specifies the > > type of service to be used in the packets from the application layer, and > > then the lower layers snoop this information. The other way is to > > explictly let the IP layers of specific nodes (for example, client nodes > > for ftps) to initiate INSIGNIA, and everything in the application and > > transport layer remains the same. > > > > If I adopt the first approach, I have to change the application > > layer, and the transport layer. For example, I may need to create a type > > of application called INSIGNIA ftp. For the second approach, no change is > > made in layers above IP, and the QoS is exclusively a task of the IP > > layer. But the user has to give commands to the IP layers of some nodes. > > This may cause some problems in configuration (config.in). > > > > Which approach is easier to implement for simulation? And which > > would be used in the real world? > > > > Thanks! > > > > Sincerely yours, > > Liangping Ma > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu May 23 21:05:49 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 VAA02502 for ; Thu, 23 May 2002 21:05:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA00638 for manet-archive@odin.ietf.org; Thu, 23 May 2002 21:06:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28808; Thu, 23 May 2002 20:34:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28751 for ; Thu, 23 May 2002 20:34:04 -0400 (EDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01728 for ; Thu, 23 May 2002 20:33:42 -0400 (EDT) Received: from frink.ece.udel.edu by mail.eecis.udel.edu id aa01537; 23 May 2002 20:33 EDT Date: Thu, 23 May 2002 20:33:45 -0400 (EDT) From: Liangping Ma To: Seoung-Bum Lee cc: manet@ietf.org, Seoungbum Lee MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: Re: [manet] Which approach better for QoS implementation? In-Reply-To: <000b01c20265$8cb28f60$93413b80@home2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hi, Seoung-Bum, Thanks for your reply! The INSIGNIA control information is in the IP option field. And every intermediate node is supposed to look into this field before deciding which protocol is to be used. This makes INSIGNIA transparent to any routing protocol. For this, I think all nodes should be enabled to support INSIGNIA. One more question about the calcualtion of rate of a UDP flow. In the latest swan paper, it says using weighted moving average on the "rates". But how to get the "rates"? Since the traffic is discrete, a fluid model does not fit it. I think we can only get approximated "rates". Maybe we can divide the packet size by the inter-arrival time, which is dynamic, to get an "instantaneous" rate. Then do averaging. Thanks! Liangping > Hello Lianping, > > I believe the first approach is the right approach. The second approach is > merely > a hack. It requires all nodes to be INSIGNIA-enabled to provide end-to-end > adaptive service. > > In actual imlementation, API of an application specifies the payload type > and > etc. For example, MPEG-2 video server may maps I-frame/B-frame/P-frame into > EQ/BQ with minimum and maximum resource requirement. If an application has > no > understanding of INSIGNIA, its resource/service requirements etc., only > best-effort service can be supported. > > QOS socket (which is API for INSIGNIA) runs on top of UDP or TCP transport, > so there's no need for any change in UDP/TCP. INSIGNIA is an IP layer > signaling > system. In order to support adaptive QOS, we also need some scheduling > (e.g. WFQ, CBQ, etc) and media access control (e.g. EDCF, etc). In fact we > need > support from application layer, transport layer, IP layer and MAC layer > in order to support QOS (even the adaptive QOS) in real world. > > - Seoung-Bum Lee > > ----- Original Message ----- > From: "Liangping Ma" > To: > Sent: Wednesday, May 22, 2002 11:45 AM > Subject: [manet] Which approach better for QoS implementation? > > > > Hi, everyone, > > > > I am implementing INSIGNIA, a type of QoS, in glomosim. The appraoch > > is to change the behavior of the IP functionality of each node so that > INSIGNIA > > can be supported. The problem is that I do not want any application (for > > exmaple, ftps) to be served with INSIGNIA. Instead, the user can configure > > which nodes to use INSIGNIA to their applications, and which nodes to use > > Best Effort (ordinary) service. One way is that the user specifies the > > type of service to be used in the packets from the application layer, and > > then the lower layers snoop this information. The other way is to > > explictly let the IP layers of specific nodes (for example, client nodes > > for ftps) to initiate INSIGNIA, and everything in the application and > > transport layer remains the same. > > > > If I adopt the first approach, I have to change the application > > layer, and the transport layer. For example, I may need to create a type > > of application called INSIGNIA ftp. For the second approach, no change is > > made in layers above IP, and the QoS is exclusively a task of the IP > > layer. But the user has to give commands to the IP layers of some nodes. > > This may cause some problems in configuration (config.in). > > > > Which approach is easier to implement for simulation? And which > > would be used in the real world? > > > > Thanks! > > > > Sincerely yours, > > Liangping Ma > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri May 24 10:40:44 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 KAA00392 for ; Fri, 24 May 2002 10:40:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11944; Fri, 24 May 2002 10:02:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11913 for ; Fri, 24 May 2002 10:02:32 -0400 (EDT) Received: from pcgw1.redstone.army.mil (root@pcgw1.redstone.army.mil [136.205.157.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29068 for ; Fri, 24 May 2002 10:02:09 -0400 (EDT) Received: from mrdec-owa.redstone.army.mil (mrdec-exch.redstone.army.mil [136.205.60.25]) by pcgw1.redstone.army.mil (8.9.3/8.9.3) with ESMTP id JAA19119 for ; Fri, 24 May 2002 09:02:28 -0500 (CDT) Received: by mrdec-owa.redstone.army.mil with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 09:02:30 -0500 Message-ID: <9225D2CF179B814F8EC5756DF6E038760B0246@rdec-exch7.redstone.army.mil> From: "Fleischman, John C" To: "MANET (E-mail)" Date: Fri, 24 May 2002 08:57:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] TORA/IMEP Code 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 Can anyone tell me how to get the latest version of the TORA/IMEP code?? Thank you, John C. Fleischman Image & Signal Processing Technology Missile Guidance Directorate Aviation & Missile Research Development & Engineering Center U.S. Army Aviation & Missile Command Email: john.fleischman@rdec.redstone.army.mil Voice: 256.842.8974 DSN: 788.8974 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri May 24 10:40:45 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 KAA00402 for ; Fri, 24 May 2002 10:40:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA14432 for manet-archive@odin.ietf.org; Fri, 24 May 2002 10:41:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11944; Fri, 24 May 2002 10:02:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11913 for ; Fri, 24 May 2002 10:02:32 -0400 (EDT) Received: from pcgw1.redstone.army.mil (root@pcgw1.redstone.army.mil [136.205.157.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29068 for ; Fri, 24 May 2002 10:02:09 -0400 (EDT) Received: from mrdec-owa.redstone.army.mil (mrdec-exch.redstone.army.mil [136.205.60.25]) by pcgw1.redstone.army.mil (8.9.3/8.9.3) with ESMTP id JAA19119 for ; Fri, 24 May 2002 09:02:28 -0500 (CDT) Received: by mrdec-owa.redstone.army.mil with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 09:02:30 -0500 Message-ID: <9225D2CF179B814F8EC5756DF6E038760B0246@rdec-exch7.redstone.army.mil> From: "Fleischman, John C" To: "MANET (E-mail)" Date: Fri, 24 May 2002 08:57:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] TORA/IMEP Code 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 Can anyone tell me how to get the latest version of the TORA/IMEP code?? Thank you, John C. Fleischman Image & Signal Processing Technology Missile Guidance Directorate Aviation & Missile Research Development & Engineering Center U.S. Army Aviation & Missile Command Email: john.fleischman@rdec.redstone.army.mil Voice: 256.842.8974 DSN: 788.8974 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri May 24 11:04:30 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 LAA01334 for ; Fri, 24 May 2002 11:04:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13138; Fri, 24 May 2002 10:26:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13107 for ; Fri, 24 May 2002 10:26:26 -0400 (EDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29953 for ; Fri, 24 May 2002 10:26:00 -0400 (EDT) From: parminder.mudhar@bt.com Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Fri, 24 May 2002 15:24:46 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2654.89) id ; Fri, 24 May 2002 15:22:47 +0100 Message-ID: <18F49733FEE5D5119A590000F8FE9A94012ACACC@mbtlipnt01.btlabs.bt.co.uk> To: John.Fleischman@rdec.redstone.army.mil, manet@ietf.org Subject: RE: [manet] TORA/IMEP Code Date: Fri, 24 May 2002 15:23:57 +0100 X-Mailer: Internet Mail Service (5.5.2654.89) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" 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 Try here http://www.cshcn.umd.edu/tora.shtml Parminder Mudhar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ e-mail: parminder.mudhar@bt.com tel: (+44) (0)1473 648103 fax: (44) (0)1473 620455 mobile: Antares (B61), Admin 2/6, Adastral Park, Martlesham, Ipswich IP5 3RE, UK BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. -----Original Message----- From: Fleischman, John C [mailto:John.Fleischman@rdec.redstone.army.mil] Sent: 24 May 2002 14:57 To: MANET (E-mail) Subject: [manet] TORA/IMEP Code Can anyone tell me how to get the latest version of the TORA/IMEP code?? Thank you, John C. Fleischman Image & Signal Processing Technology Missile Guidance Directorate Aviation & Missile Research Development & Engineering Center U.S. Army Aviation & Missile Command Email: john.fleischman@rdec.redstone.army.mil Voice: 256.842.8974 DSN: 788.8974 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri May 24 11:04:31 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 LAA01345 for ; Fri, 24 May 2002 11:04:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA16090 for manet-archive@odin.ietf.org; Fri, 24 May 2002 11:04:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13138; Fri, 24 May 2002 10:26:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13107 for ; Fri, 24 May 2002 10:26:26 -0400 (EDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29953 for ; Fri, 24 May 2002 10:26:00 -0400 (EDT) From: parminder.mudhar@bt.com Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Fri, 24 May 2002 15:24:46 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2654.89) id ; Fri, 24 May 2002 15:22:47 +0100 Message-ID: <18F49733FEE5D5119A590000F8FE9A94012ACACC@mbtlipnt01.btlabs.bt.co.uk> To: John.Fleischman@rdec.redstone.army.mil, manet@ietf.org Subject: RE: [manet] TORA/IMEP Code Date: Fri, 24 May 2002 15:23:57 +0100 X-Mailer: Internet Mail Service (5.5.2654.89) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" 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 Try here http://www.cshcn.umd.edu/tora.shtml Parminder Mudhar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ e-mail: parminder.mudhar@bt.com tel: (+44) (0)1473 648103 fax: (44) (0)1473 620455 mobile: Antares (B61), Admin 2/6, Adastral Park, Martlesham, Ipswich IP5 3RE, UK BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. -----Original Message----- From: Fleischman, John C [mailto:John.Fleischman@rdec.redstone.army.mil] Sent: 24 May 2002 14:57 To: MANET (E-mail) Subject: [manet] TORA/IMEP Code Can anyone tell me how to get the latest version of the TORA/IMEP code?? Thank you, John C. Fleischman Image & Signal Processing Technology Missile Guidance Directorate Aviation & Missile Research Development & Engineering Center U.S. Army Aviation & Missile Command Email: john.fleischman@rdec.redstone.army.mil Voice: 256.842.8974 DSN: 788.8974 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sun May 26 11:11:57 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 LAA24679 for ; Sun, 26 May 2002 11:11:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11762; Sun, 26 May 2002 10:19:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11733 for ; Sun, 26 May 2002 10:19:10 -0400 (EDT) Received: from web9504.mail.yahoo.com (web9504.mail.yahoo.com [216.136.129.134]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24078 for ; Sun, 26 May 2002 10:18:45 -0400 (EDT) Message-ID: <20020526141907.4633.qmail@web9504.mail.yahoo.com> Received: from [193.140.196.46] by web9504.mail.yahoo.com via HTTP; Sun, 26 May 2002 07:19:07 PDT Date: Sun, 26 May 2002 07:19:07 -0700 (PDT) From: ATILAY YILMAZ To: manet@ietf.org In-Reply-To: <003b01c1da85$eb1b3960$60286f80@cs.ucsb.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1757307147-1022422747=:3299" Subject: [manet] need help 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 --0-1757307147-1022422747=:3299 Content-Type: text/plain; charset=us-ascii Hello, I am undergraduate student working on a project about multihop adhoc networking. I am using AODV as routing protocol and had done some experiments by using ftp. I've found that "ftp get" performs worse than "ftp put". Especially, when multihopping, "put" performs twice -too high- better than "get". my metric is throughput. Could anybody tell me possible reason or did I make configuration mistakes in linux? I am using wavelan PCMCIA cards. I am running redhat 7.1 with pcmcia package 31 with mwavelan driver and wireless tools 23. regards, ATILAY YILMAZ Bogazici University Computer Engineering --------------------------------- Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup --0-1757307147-1022422747=:3299 Content-Type: text/html; charset=us-ascii

Hello,

I am undergraduate student working on a project about multihop adhoc networking. I am using AODV as routing protocol and had done some experiments by using ftp. I've found that "ftp get" performs worse than "ftp put". Especially, when multihopping, "put" performs twice -too high- better than "get". my metric is throughput. Could anybody tell me possible reason or did I make configuration mistakes in linux? I am using wavelan PCMCIA cards. I am running redhat 7.1 with pcmcia package 31 with mwavelan driver and wireless tools 23.

regards,



ATILAY YILMAZ
Bogazici University
Computer Engineering


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup --0-1757307147-1022422747=:3299-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sun May 26 11:11:57 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 LAA24688 for ; Sun, 26 May 2002 11:11:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13876 for manet-archive@odin.ietf.org; Sun, 26 May 2002 11:12:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11762; Sun, 26 May 2002 10:19:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11733 for ; Sun, 26 May 2002 10:19:10 -0400 (EDT) Received: from web9504.mail.yahoo.com (web9504.mail.yahoo.com [216.136.129.134]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24078 for ; Sun, 26 May 2002 10:18:45 -0400 (EDT) Message-ID: <20020526141907.4633.qmail@web9504.mail.yahoo.com> Received: from [193.140.196.46] by web9504.mail.yahoo.com via HTTP; Sun, 26 May 2002 07:19:07 PDT Date: Sun, 26 May 2002 07:19:07 -0700 (PDT) From: ATILAY YILMAZ To: manet@ietf.org In-Reply-To: <003b01c1da85$eb1b3960$60286f80@cs.ucsb.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1757307147-1022422747=:3299" Subject: [manet] need help 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 --0-1757307147-1022422747=:3299 Content-Type: text/plain; charset=us-ascii Hello, I am undergraduate student working on a project about multihop adhoc networking. I am using AODV as routing protocol and had done some experiments by using ftp. I've found that "ftp get" performs worse than "ftp put". Especially, when multihopping, "put" performs twice -too high- better than "get". my metric is throughput. Could anybody tell me possible reason or did I make configuration mistakes in linux? I am using wavelan PCMCIA cards. I am running redhat 7.1 with pcmcia package 31 with mwavelan driver and wireless tools 23. regards, ATILAY YILMAZ Bogazici University Computer Engineering --------------------------------- Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup --0-1757307147-1022422747=:3299 Content-Type: text/html; charset=us-ascii

Hello,

I am undergraduate student working on a project about multihop adhoc networking. I am using AODV as routing protocol and had done some experiments by using ftp. I've found that "ftp get" performs worse than "ftp put". Especially, when multihopping, "put" performs twice -too high- better than "get". my metric is throughput. Could anybody tell me possible reason or did I make configuration mistakes in linux? I am using wavelan PCMCIA cards. I am running redhat 7.1 with pcmcia package 31 with mwavelan driver and wireless tools 23.

regards,



ATILAY YILMAZ
Bogazici University
Computer Engineering


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup --0-1757307147-1022422747=:3299-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon May 27 21:35:04 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 VAA27189 for ; Mon, 27 May 2002 21:35:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16131; Mon, 27 May 2002 20:49:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16102 for ; Mon, 27 May 2002 20:49:06 -0400 (EDT) Received: from ep_mailout2 ([203.254.224.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26643 for ; Mon, 27 May 2002 20:48:43 -0400 (EDT) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GWS00L06Q736W@mailout2.samsung.com> for manet@ietf.org; Tue, 28 May 2002 09:47:27 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GWS00KBJQ72Q7@mailout2.samsung.com> for manet@ietf.org; Tue, 28 May 2002 09:47:27 +0900 (KST) Received: from zbin ([75.2.45.93]) by mmp1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GWS00NB9Q7Q3I@mmp1.samsung.com> for manet@ietf.org; Tue, 28 May 2002 09:47:50 +0900 (KST) Date: Tue, 28 May 2002 09:50:22 +0900 From: zb Subject: Re: [manet] ad hoc network of HyperLAN2? To: Daniel Hollos Cc: manet@ietf.org Message-id: <008201c205e1$a58718b0$5d2d024b@zbin> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Content-Transfer-Encoding: 7BIT 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 Content-Transfer-Encoding: 7BIT hi, Do you mean a HiperLAN2 MT can join 2 CCs by time division or a CC can be MT in another CC's network? If it is true, then the multihop ad hoc network can be supported. But, there must be a protocol on how to form this kind of network because the MAC of HiperLAN2 is connection oriented. That is, which should be CC, MT and joint node. regards, bin ----- Original Message ----- From: "Daniel Hollos" To: "zb" Cc: Sent: Saturday, May 25, 2002 2:55 AM Subject: Re: [manet] ad hoc network of HyperLAN2? > Hi, > > I can suggest you the Overview section of the standard Home Extension, > which describes this mode of the operation: ts101761-4V1.1.1 > http://www.etsi.org > > Yes, the H/2 ad-hoc mode is basically different from the 802.11. > The most important fact is, that it's centralised. The major idea behind > is to create a network which behaves like an adhoc network from the user's > point of view, but is polled MAC-based. > > So, the terminals form cells and elect such called Central Controllers > (CCs). The CCs create MAC frames, just like in the centralised mode, BUT: > - The terminals can communicate with each other directly, they just have > to register this demand at the CC, which allocates space in the MAC frame > for that transmission. > - Any terminal can become the CC, on-demand. (CC responsibility > handover) If, for instance the original one was moved away, it hands all > the data regarding to the open connections to the new one located to a > better position, and turnes itself to an ordinary terminal. > > Disadvantage, that this type of handovers may not be seamless, because the > CC can be even switched off. In this case a new one will be elected. > > These cells however, operate on different frequencies, the > frequ. allocation is automatic. This means, there is no collision during > the data transmission, so the goodput can be quite high; On the other hand > there is a need for a relayer terminal to connect the cells, which might > take time, because of the frequency switching delay. But if there is > two relayer terminals, this delay can be dramatically reduced. > > If you need more information, feel free to contact me! > > > Yours, Daniel > > > > > ****************** Daniel Hollos ************************* > * * > * Technical University of Berlin * > * Faculty of Electrical Engineering and Computer Science * > * Telecommunication Networks Group * > * Phone: +49 30 31428225 (Office) * > * +49 16095401825 (Cell/Mobile) * > * * > ********************************************************** > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon May 27 21:35:04 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 VAA27197 for ; Mon, 27 May 2002 21:35:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA19303 for manet-archive@odin.ietf.org; Mon, 27 May 2002 21:35:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16131; Mon, 27 May 2002 20:49:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16102 for ; Mon, 27 May 2002 20:49:06 -0400 (EDT) Received: from ep_mailout2 ([203.254.224.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26643 for ; Mon, 27 May 2002 20:48:43 -0400 (EDT) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GWS00L06Q736W@mailout2.samsung.com> for manet@ietf.org; Tue, 28 May 2002 09:47:27 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GWS00KBJQ72Q7@mailout2.samsung.com> for manet@ietf.org; Tue, 28 May 2002 09:47:27 +0900 (KST) Received: from zbin ([75.2.45.93]) by mmp1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GWS00NB9Q7Q3I@mmp1.samsung.com> for manet@ietf.org; Tue, 28 May 2002 09:47:50 +0900 (KST) Date: Tue, 28 May 2002 09:50:22 +0900 From: zb Subject: Re: [manet] ad hoc network of HyperLAN2? To: Daniel Hollos Cc: manet@ietf.org Message-id: <008201c205e1$a58718b0$5d2d024b@zbin> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Content-Transfer-Encoding: 7BIT 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 Content-Transfer-Encoding: 7BIT hi, Do you mean a HiperLAN2 MT can join 2 CCs by time division or a CC can be MT in another CC's network? If it is true, then the multihop ad hoc network can be supported. But, there must be a protocol on how to form this kind of network because the MAC of HiperLAN2 is connection oriented. That is, which should be CC, MT and joint node. regards, bin ----- Original Message ----- From: "Daniel Hollos" To: "zb" Cc: Sent: Saturday, May 25, 2002 2:55 AM Subject: Re: [manet] ad hoc network of HyperLAN2? > Hi, > > I can suggest you the Overview section of the standard Home Extension, > which describes this mode of the operation: ts101761-4V1.1.1 > http://www.etsi.org > > Yes, the H/2 ad-hoc mode is basically different from the 802.11. > The most important fact is, that it's centralised. The major idea behind > is to create a network which behaves like an adhoc network from the user's > point of view, but is polled MAC-based. > > So, the terminals form cells and elect such called Central Controllers > (CCs). The CCs create MAC frames, just like in the centralised mode, BUT: > - The terminals can communicate with each other directly, they just have > to register this demand at the CC, which allocates space in the MAC frame > for that transmission. > - Any terminal can become the CC, on-demand. (CC responsibility > handover) If, for instance the original one was moved away, it hands all > the data regarding to the open connections to the new one located to a > better position, and turnes itself to an ordinary terminal. > > Disadvantage, that this type of handovers may not be seamless, because the > CC can be even switched off. In this case a new one will be elected. > > These cells however, operate on different frequencies, the > frequ. allocation is automatic. This means, there is no collision during > the data transmission, so the goodput can be quite high; On the other hand > there is a need for a relayer terminal to connect the cells, which might > take time, because of the frequency switching delay. But if there is > two relayer terminals, this delay can be dramatically reduced. > > If you need more information, feel free to contact me! > > > Yours, Daniel > > > > > ****************** Daniel Hollos ************************* > * * > * Technical University of Berlin * > * Faculty of Electrical Engineering and Computer Science * > * Telecommunication Networks Group * > * Phone: +49 30 31428225 (Office) * > * +49 16095401825 (Cell/Mobile) * > * * > ********************************************************** > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 28 05:24:59 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 FAA11399 for ; Tue, 28 May 2002 05:24:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22210; Tue, 28 May 2002 04:43:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22151 for ; Tue, 28 May 2002 04:43:49 -0400 (EDT) Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10774 for ; Tue, 28 May 2002 04:43:24 -0400 (EDT) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp2.cluster.oleane.net with SMTP id g4S8guJ86852 for ; Tue, 28 May 2002 10:42:57 +0200 (CEST) Message-ID: <00d601c20624$81ed5840$0701a8c0@oleane.com> From: "Peter Lewis" To: Date: Tue, 28 May 2002 10:47:35 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C8_01C20635.13E4F2C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [manet] "WLAN Security 2002" conference 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 This is a multi-part message in MIME format. ------=_NextPart_000_00C8_01C20635.13E4F2C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 The "WLAN Security 2002" conference, to take place June 25-28 in Paris, = will feature the most eminent specialists in the domain of security = applied to wireless local networks.=20 More details at: http://www.upperside.fr/wlansecu/wlansecintro.htm ------=_NextPart_000_00C8_01C20635.13E4F2C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
The "WLAN Security = 2002"=20 conference, to take place June 25-28 in Paris, will feature the most = eminent=20 specialists in the domain of security applied to wireless local = networks.=20

More details at:
http://www.upp= erside.fr/wlansecu/wlansecintro.htm
 
 
------=_NextPart_000_00C8_01C20635.13E4F2C0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue May 28 05:25:00 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 FAA11410 for ; Tue, 28 May 2002 05:24:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA25121 for manet-archive@odin.ietf.org; Tue, 28 May 2002 05:25:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22210; Tue, 28 May 2002 04:43:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22151 for ; Tue, 28 May 2002 04:43:49 -0400 (EDT) Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10774 for ; Tue, 28 May 2002 04:43:24 -0400 (EDT) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp2.cluster.oleane.net with SMTP id g4S8guJ86852 for ; Tue, 28 May 2002 10:42:57 +0200 (CEST) Message-ID: <00d601c20624$81ed5840$0701a8c0@oleane.com> From: "Peter Lewis" To: Date: Tue, 28 May 2002 10:47:35 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C8_01C20635.13E4F2C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [manet] "WLAN Security 2002" conference 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 This is a multi-part message in MIME format. ------=_NextPart_000_00C8_01C20635.13E4F2C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 The "WLAN Security 2002" conference, to take place June 25-28 in Paris, = will feature the most eminent specialists in the domain of security = applied to wireless local networks.=20 More details at: http://www.upperside.fr/wlansecu/wlansecintro.htm ------=_NextPart_000_00C8_01C20635.13E4F2C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
The "WLAN Security = 2002"=20 conference, to take place June 25-28 in Paris, will feature the most = eminent=20 specialists in the domain of security applied to wireless local = networks.=20

More details at:
http://www.upp= erside.fr/wlansecu/wlansecintro.htm
 
 
------=_NextPart_000_00C8_01C20635.13E4F2C0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 28 18:25:13 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 SAA03025 for ; Tue, 28 May 2002 18:25:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19495; Tue, 28 May 2002 17:37:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19464 for ; Tue, 28 May 2002 17:37:46 -0400 (EDT) Received: from cs.uoregon.edu (root@vitalstatistix.cs.uoregon.edu [128.223.4.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01846 for ; Tue, 28 May 2002 17:37:01 -0400 (EDT) Received: from quadratix.cs.uoregon.edu (manoj@quadratix.cs.uoregon.edu [128.223.5.144]) by cs.uoregon.edu (8.11.0/8.11.0) with ESMTP id g4SLbKi05592 for ; Tue, 28 May 2002 14:37:20 -0700 (PDT) Date: Tue, 28 May 2002 14:37:20 -0700 (PDT) From: manoj pandey To: In-Reply-To: <00d601c20624$81ed5840$0701a8c0@oleane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] request for GloMoSim code for AODV 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 Hello All, I am a graduate student at the University of Oregon and am working on simulation of certain multicast protcols for MANETS. I am planning to use GloMoSim as the simulator. Can anyone point me to GloMoSim code for multicast AODV protocol? Thanks in advance. regards, Manoj ****************************** Manoj Pandey, Graduate Teaching Fellow #226, Deschutes, Computer and Information Science University of Oregon Phone# 541-346-1381 [Office] www.cs.uoregon.edu/~manoj ****************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue May 28 18:25:16 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 SAA03042 for ; Tue, 28 May 2002 18:25:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23792 for manet-archive@odin.ietf.org; Tue, 28 May 2002 18:25:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19495; Tue, 28 May 2002 17:37:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19464 for ; Tue, 28 May 2002 17:37:46 -0400 (EDT) Received: from cs.uoregon.edu (root@vitalstatistix.cs.uoregon.edu [128.223.4.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01846 for ; Tue, 28 May 2002 17:37:01 -0400 (EDT) Received: from quadratix.cs.uoregon.edu (manoj@quadratix.cs.uoregon.edu [128.223.5.144]) by cs.uoregon.edu (8.11.0/8.11.0) with ESMTP id g4SLbKi05592 for ; Tue, 28 May 2002 14:37:20 -0700 (PDT) Date: Tue, 28 May 2002 14:37:20 -0700 (PDT) From: manoj pandey To: In-Reply-To: <00d601c20624$81ed5840$0701a8c0@oleane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] request for GloMoSim code for AODV 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 Hello All, I am a graduate student at the University of Oregon and am working on simulation of certain multicast protcols for MANETS. I am planning to use GloMoSim as the simulator. Can anyone point me to GloMoSim code for multicast AODV protocol? Thanks in advance. regards, Manoj ****************************** Manoj Pandey, Graduate Teaching Fellow #226, Deschutes, Computer and Information Science University of Oregon Phone# 541-346-1381 [Office] www.cs.uoregon.edu/~manoj ****************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue May 28 22:42:04 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 WAA07598 for ; Tue, 28 May 2002 22:42:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04930; Tue, 28 May 2002 21:57:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04879 for ; Tue, 28 May 2002 21:57:50 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06600 for ; Tue, 28 May 2002 21:57:26 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA07044; Tue, 28 May 2002 18:57:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4T1vIu30394; Tue, 28 May 2002 18:57:18 -0700 X-mProtect: <200205290157> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYRFsi2; Tue, 28 May 2002 18:57:16 PDT Message-ID: <3CF4357D.A6E3A55@iprg.nokia.com> Date: Tue, 28 May 2002 18:57:17 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Yih-Chun Hu CC: Mobile Ad Hoc IETF working group Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Re: AODV WG Last Call for Comments 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 Content-Transfer-Encoding: 7bit Hello Yih-Chun, I hope you can remember the context for your comments of February 12! > As was mentioned on the list before by Erik Nordstrom (in Message-ID > on December > 13, 2001), Hello messages don't work with unidirectional links, since > Hello messages can propogate over such links, but packets can't flow in > the reverse direction. This is true. In order to fix it, we would put in an optional list of neighbors in the Hello message. That might not be so bad, after all, since the Hello messages "need" to be bigger, to compare in size with data packets. As it is, though, we don't want to use unidirectional links, and use the RREP-ACK message to avoid having them be part of a routing path. > Because of the use of NODE_TRAVERSAL_TIME, it seems inconsistent to allow > any node to hold a packet beyond NODE_TRAVERSAL_TIME (ie a node buffering > a packet for NODE_TRAVERSAL_TIME MUST drop the packet), and > NODE_TRAVERSAL_TIME should not be a configurable parameter at any node > (needs to be consistant network-wide). The best parameter would be "NET_TRAVERSAL_TIME". Now we define that instead of NETWORK_DIAMETER * NODE_TRAVERSAL_TIME. We also say that reconfiguring NODE_TRAVERSAL_TIME at a node would require network-wide knowledge. > Any cycle in the network which has aggregate latency PATH_TRAVERSAL_TIME > could cause the infinite looping of RREQ packets, and each time the RREQ > goes around this cycle, it would cause another flood of the entire > network, subject to TTL constraints. PATH_TRAVERSAL_TIME therefore should > be conservatively set to NETWORK_NODES * NODE_TRAVERSAL_TIME. This should not be a problem, as long as the unique identifier for a RREQ is maintained longer than the aggregate latency of the loop, which would be almost certainly the case. > The definition of PATH_DISCOVERY_TIME in Section 10 is unparsable. Yow, sorry we missed that! > This draft does not seem to define a default RREQ_RETRIES, nor does it > provide any guidance on how one might set that particular parameter. How about 3? It would normally depend on error rates and congestion levels and importance of the application, and you are right that we don't know how to provide guidance on factoring those details together. > There may be a node X which has a very dynamic network on one side of it > and a very static network on the other side of it. It may be possible for > X to issue 2^31 sequence numbers on the active side between new sequence > numbers on the static side. This would cause the static side to believe > that all new sequence numbers were stale for quite a long period of time, > and possibly preclude routing to X. A more aggressive mechanism for > dealing with wraparound is needed. I have a hard time believing this! That's 2 billion sequence numbers. I reckon we could limit sequence number generation to be no more than 100 per second, if this is really a concern. I can't imagine that this would ever be a realistic cause of a protocol error. > Suppose some node Y has a route to X and sends packets over that route > once per ACTIVE_ROUTE_TIMEOUT. If X reboots, and K sequential data packets > or corresponding RERRs are lost over the entire path from X to Y, Y will > be unable to find routes to X until the newly chosen sequence number > becomes greater than Y's current sequence number. This is the point of the DELETE_PERIOD. The choice of K is explicitly made to prevent this from happening. > The draft should give some guidance about the types of networks for which > AODV is a suitable routing protocol. I think it's suitable for all types of networks for which one can have the right kind of system-wide distribution of RREQ messages, and for which the mobility factor is not so huge as to invalidate any hope of route convergence, and for which unidirectional links do not predominate. In other words, the kinds of networks that have been largely the focus of the [manet] working group. > The precursor list is only set in response to RREPs, but RREQs serve as a > form of RREP in that they create routing state. As a result, precursor > lists SHOULD be set in the sender when an RREQ it propogates is received. As stated, I do not exactly agree with your suggestion. However, I do agree that RREQ does create routing state, and that this routing state should be considered when processing other incoming RREQs. The right action is to include the next hop towards the originator in the precursor list for the destination, and the next hop towards the destination in the precursor list towards the originator, at the time when the RREP packet is received. However, something other than precursor list management might be indicated for the transient RREQ state when other RREQs are received for the originator. > In Section 10, the draft allows a node to "possibly [reconfigure] the > HELLO_INTERVAL." This is too vague to be in a specification. Allowing > arbitrary changes to HELLO_INTERVAL is also problematic if a node does not > always boot to a consistant HELLO_INTERVAL. For example, if a node X sets > HELLO_INTERVAL to 10s, and advertises it, upstream neighbors only require > one HELLO within 30s. X reboots and need only wait 5 seconds before it > starts participating in the protocol again. Nodes would no longer be able > to reach X. Any such disconnection would be temporary, but you are right that we had not examined the consequences of this scenario. I have included language according to your suggestion. > In Sec 6.2, the draft allows the receipt of AODV control packets to > confirm that a neighbor is still there. Not only does this suffer the same > problem with unidirectional links as Hello packets, it also is > ill-specified. The language in the draft can be interpreted to allow an > RREQ that has traversed multiple hops could be used to renew the neighbor > status of the source of the RREQ. O.K. Thanks for the pointer! We have tightened up that language. I think that disallowing unidirectional links to be part of discovered routes will mostly fix this problem. Before your observation, I think that we were assuming that "neighbor" carried along with it the implication that the neighbor node was only one hop away. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue May 28 22:42:05 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 WAA07609 for ; Tue, 28 May 2002 22:42:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA08392 for manet-archive@odin.ietf.org; Tue, 28 May 2002 22:42:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04930; Tue, 28 May 2002 21:57:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04879 for ; Tue, 28 May 2002 21:57:50 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06600 for ; Tue, 28 May 2002 21:57:26 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA07044; Tue, 28 May 2002 18:57:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4T1vIu30394; Tue, 28 May 2002 18:57:18 -0700 X-mProtect: <200205290157> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYRFsi2; Tue, 28 May 2002 18:57:16 PDT Message-ID: <3CF4357D.A6E3A55@iprg.nokia.com> Date: Tue, 28 May 2002 18:57:17 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Yih-Chun Hu CC: Mobile Ad Hoc IETF working group Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Re: AODV WG Last Call for Comments 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 Content-Transfer-Encoding: 7bit Hello Yih-Chun, I hope you can remember the context for your comments of February 12! > As was mentioned on the list before by Erik Nordstrom (in Message-ID > on December > 13, 2001), Hello messages don't work with unidirectional links, since > Hello messages can propogate over such links, but packets can't flow in > the reverse direction. This is true. In order to fix it, we would put in an optional list of neighbors in the Hello message. That might not be so bad, after all, since the Hello messages "need" to be bigger, to compare in size with data packets. As it is, though, we don't want to use unidirectional links, and use the RREP-ACK message to avoid having them be part of a routing path. > Because of the use of NODE_TRAVERSAL_TIME, it seems inconsistent to allow > any node to hold a packet beyond NODE_TRAVERSAL_TIME (ie a node buffering > a packet for NODE_TRAVERSAL_TIME MUST drop the packet), and > NODE_TRAVERSAL_TIME should not be a configurable parameter at any node > (needs to be consistant network-wide). The best parameter would be "NET_TRAVERSAL_TIME". Now we define that instead of NETWORK_DIAMETER * NODE_TRAVERSAL_TIME. We also say that reconfiguring NODE_TRAVERSAL_TIME at a node would require network-wide knowledge. > Any cycle in the network which has aggregate latency PATH_TRAVERSAL_TIME > could cause the infinite looping of RREQ packets, and each time the RREQ > goes around this cycle, it would cause another flood of the entire > network, subject to TTL constraints. PATH_TRAVERSAL_TIME therefore should > be conservatively set to NETWORK_NODES * NODE_TRAVERSAL_TIME. This should not be a problem, as long as the unique identifier for a RREQ is maintained longer than the aggregate latency of the loop, which would be almost certainly the case. > The definition of PATH_DISCOVERY_TIME in Section 10 is unparsable. Yow, sorry we missed that! > This draft does not seem to define a default RREQ_RETRIES, nor does it > provide any guidance on how one might set that particular parameter. How about 3? It would normally depend on error rates and congestion levels and importance of the application, and you are right that we don't know how to provide guidance on factoring those details together. > There may be a node X which has a very dynamic network on one side of it > and a very static network on the other side of it. It may be possible for > X to issue 2^31 sequence numbers on the active side between new sequence > numbers on the static side. This would cause the static side to believe > that all new sequence numbers were stale for quite a long period of time, > and possibly preclude routing to X. A more aggressive mechanism for > dealing with wraparound is needed. I have a hard time believing this! That's 2 billion sequence numbers. I reckon we could limit sequence number generation to be no more than 100 per second, if this is really a concern. I can't imagine that this would ever be a realistic cause of a protocol error. > Suppose some node Y has a route to X and sends packets over that route > once per ACTIVE_ROUTE_TIMEOUT. If X reboots, and K sequential data packets > or corresponding RERRs are lost over the entire path from X to Y, Y will > be unable to find routes to X until the newly chosen sequence number > becomes greater than Y's current sequence number. This is the point of the DELETE_PERIOD. The choice of K is explicitly made to prevent this from happening. > The draft should give some guidance about the types of networks for which > AODV is a suitable routing protocol. I think it's suitable for all types of networks for which one can have the right kind of system-wide distribution of RREQ messages, and for which the mobility factor is not so huge as to invalidate any hope of route convergence, and for which unidirectional links do not predominate. In other words, the kinds of networks that have been largely the focus of the [manet] working group. > The precursor list is only set in response to RREPs, but RREQs serve as a > form of RREP in that they create routing state. As a result, precursor > lists SHOULD be set in the sender when an RREQ it propogates is received. As stated, I do not exactly agree with your suggestion. However, I do agree that RREQ does create routing state, and that this routing state should be considered when processing other incoming RREQs. The right action is to include the next hop towards the originator in the precursor list for the destination, and the next hop towards the destination in the precursor list towards the originator, at the time when the RREP packet is received. However, something other than precursor list management might be indicated for the transient RREQ state when other RREQs are received for the originator. > In Section 10, the draft allows a node to "possibly [reconfigure] the > HELLO_INTERVAL." This is too vague to be in a specification. Allowing > arbitrary changes to HELLO_INTERVAL is also problematic if a node does not > always boot to a consistant HELLO_INTERVAL. For example, if a node X sets > HELLO_INTERVAL to 10s, and advertises it, upstream neighbors only require > one HELLO within 30s. X reboots and need only wait 5 seconds before it > starts participating in the protocol again. Nodes would no longer be able > to reach X. Any such disconnection would be temporary, but you are right that we had not examined the consequences of this scenario. I have included language according to your suggestion. > In Sec 6.2, the draft allows the receipt of AODV control packets to > confirm that a neighbor is still there. Not only does this suffer the same > problem with unidirectional links as Hello packets, it also is > ill-specified. The language in the draft can be interpreted to allow an > RREQ that has traversed multiple hops could be used to renew the neighbor > status of the source of the RREQ. O.K. Thanks for the pointer! We have tightened up that language. I think that disallowing unidirectional links to be part of discovered routes will mostly fix this problem. Before your observation, I think that we were assuming that "neighbor" carried along with it the implication that the neighbor node was only one hop away. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed May 29 03:02:18 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 DAA04803 for ; Wed, 29 May 2002 03:02:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11031; Wed, 29 May 2002 02:28:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11002 for ; Wed, 29 May 2002 02:28:05 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03000 for ; Wed, 29 May 2002 02:27:38 -0400 (EDT) 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 XAA24518; Tue, 28 May 2002 23:25:15 -0700 (PDT) Message-Id: <200205290625.XAA24518@pit.erg.sri.com> To: "Charles E. Perkins" cc: Yih-Chun Hu , Mobile Ad Hoc IETF working group Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Re: AODV WG Last Call for Comments In-reply-to: Your message of "Tue, 28 May 2002 18:57:17 PDT." <3CF4357D.A6E3A55@iprg.nokia.com> Date: Tue, 28 May 2002 23:25:15 -0700 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 > > Hello Yih-Chun, > > I hope you can remember the context for your comments of February 12! > > > As was mentioned on the list before by Erik Nordstrom (in Message-ID > > on December > > 13, 2001), Hello messages don't work with unidirectional links, since > > Hello messages can propogate over such links, but packets can't flow in > > the reverse direction. > > This is true. In order to fix it, we would put in an optional list > of neighbors in the Hello message. That might not be so bad, > after all, since the Hello messages "need" to be bigger, to compare > in size with data packets. As it is, though, we don't want to > use unidirectional links, and use the RREP-ACK message to avoid > having them be part of a routing path. I am not sure that the list of neighbors should be optional. Suppose that link-layer notification is not used, and that data packets are being forwarded from node i to node j. If the link becomes unidirectional from j to i, then node i will continue to receive Hellos from j and never detect that the link to j has failed. On the other hand, each Hello need not include *all* neighbors, but only those from which data packets have recently been received. Richard _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed May 29 03:02:18 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 DAA04814 for ; Wed, 29 May 2002 03:02:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA15058 for manet-archive@odin.ietf.org; Wed, 29 May 2002 03:02:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11031; Wed, 29 May 2002 02:28:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11002 for ; Wed, 29 May 2002 02:28:05 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03000 for ; Wed, 29 May 2002 02:27:38 -0400 (EDT) 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 XAA24518; Tue, 28 May 2002 23:25:15 -0700 (PDT) Message-Id: <200205290625.XAA24518@pit.erg.sri.com> To: "Charles E. Perkins" cc: Yih-Chun Hu , Mobile Ad Hoc IETF working group Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Re: AODV WG Last Call for Comments In-reply-to: Your message of "Tue, 28 May 2002 18:57:17 PDT." <3CF4357D.A6E3A55@iprg.nokia.com> Date: Tue, 28 May 2002 23:25:15 -0700 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 > > Hello Yih-Chun, > > I hope you can remember the context for your comments of February 12! > > > As was mentioned on the list before by Erik Nordstrom (in Message-ID > > on December > > 13, 2001), Hello messages don't work with unidirectional links, since > > Hello messages can propogate over such links, but packets can't flow in > > the reverse direction. > > This is true. In order to fix it, we would put in an optional list > of neighbors in the Hello message. That might not be so bad, > after all, since the Hello messages "need" to be bigger, to compare > in size with data packets. As it is, though, we don't want to > use unidirectional links, and use the RREP-ACK message to avoid > having them be part of a routing path. I am not sure that the list of neighbors should be optional. Suppose that link-layer notification is not used, and that data packets are being forwarded from node i to node j. If the link becomes unidirectional from j to i, then node i will continue to receive Hellos from j and never detect that the link to j has failed. On the other hand, each Hello need not include *all* neighbors, but only those from which data packets have recently been received. Richard _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri May 31 14:05:09 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 OAA24933 for ; Fri, 31 May 2002 14:05:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22245; Fri, 31 May 2002 13:26:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22220 for ; Fri, 31 May 2002 13:26:12 -0400 (EDT) Received: from phoebe.eim.surrey.ac.uk (IDENT:exim@phoebe.eim.surrey.ac.uk [131.227.74.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23167 for ; Fri, 31 May 2002 13:25:46 -0400 (EDT) Received: from kenny.ee.surrey.ac.uk ([131.227.74.2] ident=exim) by phoebe.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 17DqA8-0002ju-00 for manet@ietf.org; Fri, 31 May 2002 18:26:04 +0100 Received: from eem1ss (helo=localhost) by kenny.ee.surrey.ac.uk with local-esmtp (Exim 2.12 #5) id 17DqA8-0006EK-00 for manet@ietf.org; Fri, 31 May 2002 18:26:04 +0100 Date: Fri, 31 May 2002 18:26:04 +0100 (BST) From: Sivapathalingham Sivavakeesar X-X-Sender: eem1ss@kenny.ee.surrey.ac.uk To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *17DqA8-0002ju-00*Gmh3reMGAq6* (SECM, UniS) Subject: [manet] Ad Hoc Clustering Algorithm 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 Dear All : I am trying to simulate the Lowest_ID clustering algorith using GloMoSim. Please let me know whether GloMoSim has any in-built capabilities that enable easy implemntation of any clustering algorithm. If not, has anybody ever tried to simulate any of the ad hoc clustering algorithms, namely Lowest-ID, max-connectivity, and CBRP, using GloMoSim OR ns-2 ? It would be greatly appreciated, if anybody spends some time to answer this question. Cheers SIVA SIVAVAKEESAR _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri May 31 14:05:10 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 OAA24944 for ; Fri, 31 May 2002 14:05:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA25021 for manet-archive@odin.ietf.org; Fri, 31 May 2002 14:05:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22245; Fri, 31 May 2002 13:26:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22220 for ; Fri, 31 May 2002 13:26:12 -0400 (EDT) Received: from phoebe.eim.surrey.ac.uk (IDENT:exim@phoebe.eim.surrey.ac.uk [131.227.74.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23167 for ; Fri, 31 May 2002 13:25:46 -0400 (EDT) Received: from kenny.ee.surrey.ac.uk ([131.227.74.2] ident=exim) by phoebe.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 17DqA8-0002ju-00 for manet@ietf.org; Fri, 31 May 2002 18:26:04 +0100 Received: from eem1ss (helo=localhost) by kenny.ee.surrey.ac.uk with local-esmtp (Exim 2.12 #5) id 17DqA8-0006EK-00 for manet@ietf.org; Fri, 31 May 2002 18:26:04 +0100 Date: Fri, 31 May 2002 18:26:04 +0100 (BST) From: Sivapathalingham Sivavakeesar X-X-Sender: eem1ss@kenny.ee.surrey.ac.uk To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *17DqA8-0002ju-00*Gmh3reMGAq6* (SECM, UniS) Subject: [manet] Ad Hoc Clustering Algorithm 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 Dear All : I am trying to simulate the Lowest_ID clustering algorith using GloMoSim. Please let me know whether GloMoSim has any in-built capabilities that enable easy implemntation of any clustering algorithm. If not, has anybody ever tried to simulate any of the ad hoc clustering algorithms, namely Lowest-ID, max-connectivity, and CBRP, using GloMoSim OR ns-2 ? It would be greatly appreciated, if anybody spends some time to answer this question. Cheers SIVA SIVAVAKEESAR _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri May 31 19:49:35 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 TAA06925 for ; Fri, 31 May 2002 19:49:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11113; Fri, 31 May 2002 19:03:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11084 for ; Fri, 31 May 2002 19:03:41 -0400 (EDT) Received: from mailcity.com (fes3.mail.lycos.com [209.185.123.188]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06444 for ; Fri, 31 May 2002 19:03:15 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Fri May 31 16:02:37 2002 To: manet@ietf.org Date: Sat, 01 Jun 2002 04:32:37 +0530 From: "PARAG AGARWAL" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: paragr@lycos.com X-Expiredinmiddle: true X-Mailer: MailCity Service X-Priority: 3 X-Sender-Ip: 129.110.72.25 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] POMC 2002 - Call For Papers 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 Content-Transfer-Encoding: 7bit Call For Papers --------------- Preliminary Announcement and Call for Papers POMC 2002 Workshop on Principles of Mobile Computing October 30-31, 2002, Toulouse, France. Workshop URL: www.utdallas.edu/~ravip/pomc/POMC/POMC.html Sponsor: ACM SIGACT Accepted papers published by ACM Submission deadline : July 5, 2002 To be held in conjunction with International Symposium on DIStributed Computing (DISC 2002) http://www.enseeiht.fr/~disc02/ ============================================================================= Mobile computing and communications devices are proliferating in recent years. The mobility of distributed computing components raises a number of interesting, and difficult, algorithmic issues. This two-day workshop is intended to bring together researchers in mobile computing (especially, but not exclusively, ad hoc networks) and distributed algorithms (especially, but not exclusively, dynamic networks). To facilitate such interaction, the workshop is scheduled to begin on the last day of DISC 2002. The planned format is a combination of contributed papers and one-hour tutorials. Significant time for discussion will be allocated. It is intended to be a lively and informal meeting, and to foster cooperation among mobile computing systems researchers and distributed algorithms theoreticians. ============================================================================= Topics ------ Papers are solicited in all research and applied areas that touch on the application of, or need for, distributed algorithms in the context of mobile computing systems. Papers covering work in progress are especially welcome. Papers should describe original, previously unpublished work that is not currently under review by another conference, workshop, or journal. Specific topics include, but are not limited to: - distributed algorithms - routing - dynamic networks - dynamic graph algorithms - location tracking - middleware - security - scheduling - media access techniques - quality-of-service issues - sensor networks - complexity analysis of algorithms for mobile environments Please consult any member of the technical program committee if you are uncertain whether your paper falls within the scope of the workshop. Submission Instructions ---------------------- Submission should be up to 10 pages in length with reasonable margins and line spacing using at least 11-point font. Submission instructions will be available on the conference website. Important Dates: Paper Submissions Due: July 5, 2002 Notification of Acceptance: August 8, 2002 Camera-ready Version Due: August 30, 2002 Authors of accepted papers are expected to present their paper at the workshop. FOR MORE INFORMATION: Check the workshop website or send email to Ravi Prakash (ravip@utdallas.edu) Organsing Committee =================== General Chair - Andre Schiper, EPFL andre.schiper@epfl.ch Technical Program Co-chairs - Roberto Baldoni, University of Rome "La Sapienza" baldoni@dis.uniroma1.it - Ravi Prakash, University of Texas at Dallas ravip@utdallas.edu Technical Program Committee - Maurizio Bonuccelli, University of Pisa bonucce@di.unipi.it - Sandeep Gupta, Arizona State University sandeep.gupta@asu.edu - David B. Johnson, Rice University dbj@cs.rice.edu - Marc-Olivier Killijian, LAAS-CNRS marco.killijian@laas.fr - Amy Murphy, University of Rochester murphy@cs.rochester.edu - Michel Raynal, IRISA michel.raynal@irisa.fr - Mukesh Singhal, University of Kentucky singhal@cs.uky.edu Registration and Finance Chair - Xavier Defago, JAIST defago@jaist.ac.jp Local Arrangements Chair - Marc-Olivier Killijian, LAAS-CNRS marco.killijian@laas.fr Webmaster and Publicity Co-chair - Mansoor Mohsin, University of Texas at Dallas mmohsin@utdallas.edu - Parag Agarwal, University of Texas at Dallas pxa016500@utdallas.edu Steering Committee - Nancy Lynch, MIT lynch@theory.lcs.mit.edu - Andre Schiper, EPFL andre.schiper@epfl.ch - Nitin Vaidya, University of Illinois at Urbana-Champaign nhv@uiuc.edu - Jennifer Welch, Texas A&M University welch@cs.tamu.edu ________________________________________________________ Outgrown your current e-mail service? Get a 25MB Inbox, POP3 Access, No Ads and No Taglines with LYCOS MAIL PLUS. http://login.mail.lycos.com/brandPage.shtml?pageId=plus _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri May 31 19:49:36 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 TAA06933 for ; Fri, 31 May 2002 19:49:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA13085 for manet-archive@odin.ietf.org; Fri, 31 May 2002 19:50:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11113; Fri, 31 May 2002 19:03:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11084 for ; Fri, 31 May 2002 19:03:41 -0400 (EDT) Received: from mailcity.com (fes3.mail.lycos.com [209.185.123.188]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06444 for ; Fri, 31 May 2002 19:03:15 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Fri May 31 16:02:37 2002 To: manet@ietf.org Date: Sat, 01 Jun 2002 04:32:37 +0530 From: "PARAG AGARWAL" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: paragr@lycos.com X-Expiredinmiddle: true X-Mailer: MailCity Service X-Priority: 3 X-Sender-Ip: 129.110.72.25 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] POMC 2002 - Call For Papers 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 Content-Transfer-Encoding: 7bit Call For Papers --------------- Preliminary Announcement and Call for Papers POMC 2002 Workshop on Principles of Mobile Computing October 30-31, 2002, Toulouse, France. Workshop URL: www.utdallas.edu/~ravip/pomc/POMC/POMC.html Sponsor: ACM SIGACT Accepted papers published by ACM Submission deadline : July 5, 2002 To be held in conjunction with International Symposium on DIStributed Computing (DISC 2002) http://www.enseeiht.fr/~disc02/ ============================================================================= Mobile computing and communications devices are proliferating in recent years. The mobility of distributed computing components raises a number of interesting, and difficult, algorithmic issues. This two-day workshop is intended to bring together researchers in mobile computing (especially, but not exclusively, ad hoc networks) and distributed algorithms (especially, but not exclusively, dynamic networks). To facilitate such interaction, the workshop is scheduled to begin on the last day of DISC 2002. The planned format is a combination of contributed papers and one-hour tutorials. Significant time for discussion will be allocated. It is intended to be a lively and informal meeting, and to foster cooperation among mobile computing systems researchers and distributed algorithms theoreticians. ============================================================================= Topics ------ Papers are solicited in all research and applied areas that touch on the application of, or need for, distributed algorithms in the context of mobile computing systems. Papers covering work in progress are especially welcome. Papers should describe original, previously unpublished work that is not currently under review by another conference, workshop, or journal. Specific topics include, but are not limited to: - distributed algorithms - routing - dynamic networks - dynamic graph algorithms - location tracking - middleware - security - scheduling - media access techniques - quality-of-service issues - sensor networks - complexity analysis of algorithms for mobile environments Please consult any member of the technical program committee if you are uncertain whether your paper falls within the scope of the workshop. Submission Instructions ---------------------- Submission should be up to 10 pages in length with reasonable margins and line spacing using at least 11-point font. Submission instructions will be available on the conference website. Important Dates: Paper Submissions Due: July 5, 2002 Notification of Acceptance: August 8, 2002 Camera-ready Version Due: August 30, 2002 Authors of accepted papers are expected to present their paper at the workshop. FOR MORE INFORMATION: Check the workshop website or send email to Ravi Prakash (ravip@utdallas.edu) Organsing Committee =================== General Chair - Andre Schiper, EPFL andre.schiper@epfl.ch Technical Program Co-chairs - Roberto Baldoni, University of Rome "La Sapienza" baldoni@dis.uniroma1.it - Ravi Prakash, University of Texas at Dallas ravip@utdallas.edu Technical Program Committee - Maurizio Bonuccelli, University of Pisa bonucce@di.unipi.it - Sandeep Gupta, Arizona State University sandeep.gupta@asu.edu - David B. Johnson, Rice University dbj@cs.rice.edu - Marc-Olivier Killijian, LAAS-CNRS marco.killijian@laas.fr - Amy Murphy, University of Rochester murphy@cs.rochester.edu - Michel Raynal, IRISA michel.raynal@irisa.fr - Mukesh Singhal, University of Kentucky singhal@cs.uky.edu Registration and Finance Chair - Xavier Defago, JAIST defago@jaist.ac.jp Local Arrangements Chair - Marc-Olivier Killijian, LAAS-CNRS marco.killijian@laas.fr Webmaster and Publicity Co-chair - Mansoor Mohsin, University of Texas at Dallas mmohsin@utdallas.edu - Parag Agarwal, University of Texas at Dallas pxa016500@utdallas.edu Steering Committee - Nancy Lynch, MIT lynch@theory.lcs.mit.edu - Andre Schiper, EPFL andre.schiper@epfl.ch - Nitin Vaidya, University of Illinois at Urbana-Champaign nhv@uiuc.edu - Jennifer Welch, Texas A&M University welch@cs.tamu.edu ________________________________________________________ Outgrown your current e-mail service? Get a 25MB Inbox, POP3 Access, No Ads and No Taglines with LYCOS MAIL PLUS. http://login.mail.lycos.com/brandPage.shtml?pageId=plus _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri May 31 23:03:20 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 XAA09885 for ; Fri, 31 May 2002 23:03:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA18695; Fri, 31 May 2002 22:25:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA18663 for ; Fri, 31 May 2002 22:25:45 -0400 (EDT) Received: from ims21.stu.nus.edu.sg (nusnet-14-26.dynip.nus.edu.sg [137.132.14.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08918 for ; Fri, 31 May 2002 22:25:16 -0400 (EDT) Received: from mbxsrv26.stu.nus.edu.sg ([137.132.14.236]) by ims21.stu.nus.edu.sg with Microsoft SMTPSVC(5.0.2195.4905); Sat, 1 Jun 2002 10:25:41 +0800 content-class: urn:content-classes:message Date: Sat, 1 Jun 2002 10:25:41 +0800 Message-ID: <6330DC96389A924A804F52FA3848930E5B3E70@MBXSRV26.stu.nus.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Ad Hoc Clustering Algorithm Thread-Index: AcIIxiSMTBDGDVUgT/q/GJbyXgdIJAATPMLw From: "Marwaha Shivanajay" To: Cc: X-OriginalArrivalTime: 01 Jun 2002 02:25:41.0754 (UTC) FILETIME=[A0428DA0:01C20913] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA18664 Subject: [manet] Ad Hoc Clustering Algorithm 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 Content-Transfer-Encoding: 8bit Hi, You can download it from the site below: http://www.comp.nus.edu.sg/~tayyc/cbrp/ Thais was developed in our univ, but I haven't worked on it. Regards, Shivanajay Marwaha ~-~-~-~-~-~-~-~-~-~-~-~-~-~- Research Scholar, Dept. of Electrical & Comp Engg. National University of Singapore. www.nus.edu.sg ~-~-~-~-~-~-~-~-~-~-~-~-~-~- -----Original Message----- From: Sivapathalingham Sivavakeesar [mailto:eem1ss@eim.surrey.ac.uk] Sent: Saturday, June 01, 2002 1:11 AM To: Marwaha Shivanajay Subject: Clustering Algorithm Dear Marwaha Shivanajay : I saw your mail in manet mail list, asking for any clustering algorithm implementation. Have you ever managed to simulate any ad hoc clustering algorithm ? if so would you please pass the code on to me, as it is urgent. Your timely help would be greatly appreciated. Cheers SIVA SIVAVAKEESAR _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri May 31 23:03:25 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 XAA09895 for ; Fri, 31 May 2002 23:03:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA20851 for manet-archive@odin.ietf.org; Fri, 31 May 2002 23:03:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA18695; Fri, 31 May 2002 22:25:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA18663 for ; Fri, 31 May 2002 22:25:45 -0400 (EDT) Received: from ims21.stu.nus.edu.sg (nusnet-14-26.dynip.nus.edu.sg [137.132.14.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08918 for ; Fri, 31 May 2002 22:25:16 -0400 (EDT) Received: from mbxsrv26.stu.nus.edu.sg ([137.132.14.236]) by ims21.stu.nus.edu.sg with Microsoft SMTPSVC(5.0.2195.4905); Sat, 1 Jun 2002 10:25:41 +0800 content-class: urn:content-classes:message Date: Sat, 1 Jun 2002 10:25:41 +0800 Message-ID: <6330DC96389A924A804F52FA3848930E5B3E70@MBXSRV26.stu.nus.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Ad Hoc Clustering Algorithm Thread-Index: AcIIxiSMTBDGDVUgT/q/GJbyXgdIJAATPMLw From: "Marwaha Shivanajay" To: Cc: X-OriginalArrivalTime: 01 Jun 2002 02:25:41.0754 (UTC) FILETIME=[A0428DA0:01C20913] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA18664 Subject: [manet] Ad Hoc Clustering Algorithm 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 Content-Transfer-Encoding: 8bit Hi, You can download it from the site below: http://www.comp.nus.edu.sg/~tayyc/cbrp/ Thais was developed in our univ, but I haven't worked on it. Regards, Shivanajay Marwaha ~-~-~-~-~-~-~-~-~-~-~-~-~-~- Research Scholar, Dept. of Electrical & Comp Engg. National University of Singapore. www.nus.edu.sg ~-~-~-~-~-~-~-~-~-~-~-~-~-~- -----Original Message----- From: Sivapathalingham Sivavakeesar [mailto:eem1ss@eim.surrey.ac.uk] Sent: Saturday, June 01, 2002 1:11 AM To: Marwaha Shivanajay Subject: Clustering Algorithm Dear Marwaha Shivanajay : I saw your mail in manet mail list, asking for any clustering algorithm implementation. Have you ever managed to simulate any ad hoc clustering algorithm ? if so would you please pass the code on to me, as it is urgent. Your timely help would be greatly appreciated. Cheers SIVA SIVAVAKEESAR _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet