From majordom Tue Apr 2 13:40:50 1996 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA14134; Tue, 2 Apr 96 13:40:50 EST Received: from [132.250.92.68] (gumbo.itd.nrl.navy.mil) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA14125; Tue, 2 Apr 96 13:40:44 EST Date: Tue, 2 Apr 96 13:40:43 EST Message-Id: <9604021840.AA14125@itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mmnet@itd.nrl.navy.mil From: macker@itd.nrl.navy.mil (Joseph P. Macker) Subject: REMINDER! Archive Retrieval Instructions Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk We had a few more requests regarding retrieving the archive from newcomers. I am reposting these instructions. Mailing list members can get an archive history by sending mail to majordomo@itd.nrl.navy.mil with the body "get mmnet mmnet.archive". The "mars.itd.nrl.navy.mil" site mentioned in the BOF notes is not retaining the latest archive. Do not go to this site for the mailing list archive! -Joe _/ _/ _/_/_/_/ _/ Joseph P. Macker, Code 5544 _/_/ _/ _/ _/ _/ Naval Research Laboratory _/ _/ _/ _/_/_/_/ _/ Center for High Assurance Computer Systems _/ _/_/ _/ _/ _/ macker@itd.nrl.navy.mil _/ _/ _/ _/ _/_/_/_/ http://tonnant.itd.nrl.navy.mil/macker.html _/ _/ _/_/_/_/ _/ Joseph P. Macker, Code 5544 _/_/ _/ _/ _/ _/ Naval Research Laboratory _/ _/ _/ _/_/_/_/ _/ Center for High Assurance Computer Systems _/ _/_/ _/ _/ _/ macker@itd.nrl.navy.mil _/ _/ _/ _/ _/_/_/_/ http://tonnant.itd.nrl.navy.mil/macker.html From majordom Tue Apr 16 15:48:34 1996 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA18116; Tue, 16 Apr 96 15:48:34 EDT Received: from ursa.cus.cam.ac.uk by itd.nrl.navy.mil (4.1/SMI-4.1) id AA18107; Tue, 16 Apr 96 15:48:28 EDT Received: from bootes.cus.cam.ac.uk [131.111.8.1] (ident = root) by ursa.cus.cam.ac.uk with smtp (Smail-3.1.29.0 #77) id m0u9Gji-00011BC; Tue, 16 Apr 96 20:48 BST Received: by bootes.cus.cam.ac.uk (Smail-3.1.29.0 #36) id m0u9Gjh-000BzKC; Tue, 16 Apr 96 20:48 BST Message-Id: From: ct10000@cus.cam.ac.uk (C. Toh) Subject: New Ad-Hoc Routing Protocol To: mmnet@itd.nrl.navy.mil Date: Tue, 16 Apr 1996 20:48:25 +0100 (BST) Cc: ct10000@cus.cam.ac.uk X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 634 Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk Dear Folks, A new routing protocol for ad-hoc mobile network known as associativity-based routing was born. I am currently filing a US patent for this idea. Interested parties please contact me. Regards, C-K Toh, Cambridge University Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB2 3QG. E-Mail : Chai-Keong.Toh@cl.cam.ac.uk ------------------------------------------------------ URL : http://www.cl.cam.ac.uk/users/ct10000/index.html ------------------------------------------------------ Tel : 44 01223 335444 Fax : 44 01223 334678 ------------------------------------------------------ From majordom Tue Apr 16 16:22:04 1996 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA19602; Tue, 16 Apr 96 16:22:04 EDT Received: from [132.250.92.68] (gumbo.itd.nrl.navy.mil) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA19587; Tue, 16 Apr 96 16:21:54 EDT Message-Id: <9604162021.AA19587@itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Apr 1996 16:21:53 -0400 To: ct10000@cus.cam.ac.uk (C. Toh) From: macker@itd.nrl.navy.mil (Joseph P. Macker) Subject: Re: New Ad-Hoc Routing Protocol Cc: mmnet@itd.nrl.navy.mil Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk CK- There aren't many rules here, but IETF mailing lists are not for soliciting or advertising... I personally view your note as overstepping that boundary. We'd love to hear your ideas or thoughts on mobile-mesh or ad-hoc networking expressed in this open forum. Sounds like you have some. Maybe you would like to present these at the BOF in Montreal ;-). Don't turn me into a mailing list moderator ;-(. -Joe >Dear Folks, > >A new routing protocol for ad-hoc mobile network >known as associativity-based routing was born. > >I am currently filing a US patent for this idea. > >Interested parties please contact me. > >Regards, > > C-K Toh, Cambridge University Computer Laboratory, > New Museums Site, Pembroke Street, Cambridge CB2 3QG. > E-Mail : Chai-Keong.Toh@cl.cam.ac.uk > ------------------------------------------------------ > URL : http://www.cl.cam.ac.uk/users/ct10000/index.html _/ _/ _/_/_/_/ _/ Joseph P. Macker, Code 5544 _/_/ _/ _/ _/ _/ Naval Research Laboratory _/ _/ _/ _/_/_/_/ _/ Center for High Assurance Computer Systems _/ _/_/ _/ _/ _/ macker@itd.nrl.navy.mil _/ _/ _/ _/ _/_/_/_/ http://tonnant.itd.nrl.navy.mil/macker.html From majordom Tue Apr 16 22:37:08 1996 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA28676; Tue, 16 Apr 96 22:37:08 EDT Received: from bnr.ca (x400gate.bnr.ca) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA28670; Tue, 16 Apr 96 22:37:02 EDT X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 16 Apr 1996 22:36:45 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 16 Apr 1996 22:36:30 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Sun, 14 Apr 1996 22:36:00 -0400 Date: Tue, 16 Apr 1996 22:36:00 -0400 X400-Originator: /dd.id=1663884/g=vivek/i=v/s=kapil/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.869:17.03.96.02.36.30] X400-Content-Type: P2-1984 (2) Content-Identifier: re:New Ad-Hoc... From: "vivek (v.) kapil" Message-Id: <"25873 Tue Apr 16 22:36:38 1996"@bnr.ca> To: mmnet@itd.nrl.navy.mil Subject: re:New Ad-Hoc Routing Protocol Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk That's a great news CK, but why don't you present this idea at the next IETF in Montreal. You may want to talk to appropriate folks to arrange a BOF. Should you wish to discuss here, I am sure lot of us will be ready to listen and give commnents. BTW, I thought if some idea ever becomes a standard thru' IETF (I mean internet standard), one has to waive rights of patents. You can consult IETF authorities re this. Regards, Vivek Kapil vkapil@nortel.ca In message "New Ad-Hoc Routing Protocol", ct10000@cus.cam.ac.uk writes: >Dear Folks, > >A new routing protocol for ad-hoc mobile network >known as associativity-based routing was born. > >I am currently filing a US patent for this idea. > >Interested parties please contact me. > >Regards, > > C-K Toh, Cambridge University Computer Laboratory, > New Museums Site, Pembroke Street, Cambridge CB2 3QG. > E-Mail : Chai-Keong.Toh@cl.cam.ac.uk > ------------------------------------------------------ > URL : http://www.cl.cam.ac.uk/users/ct10000/index.html > ------------------------------------------------------ > Tel : 44 01223 335444 Fax : 44 01223 334678 > ------------------------------------------------------ > > From majordom Wed Apr 17 07:46:30 1996 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA13622; Wed, 17 Apr 96 07:46:30 EDT Received: from igw2.watson.ibm.com by itd.nrl.navy.mil (4.1/SMI-4.1) id AA13616; Wed, 17 Apr 96 07:46:21 EDT Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id HAA22018; Wed, 17 Apr 1996 07:46:27 -0400 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96) id AA21898; Wed, 17 Apr 1996 07:46:14 -0400 From: Charlie Perkins Message-Id: <9604171146.AA21898@hawpub1.watson.ibm.com> To: "vivek (v.) kapil" Cc: mmnet@itd.nrl.navy.mil Reply-To: perk@watson.ibm.com Subject: Re: New Ad-Hoc Routing Protocol In-Reply-To: Your message of Tue, 16 Apr 96 22:36:00 D. <"25873.Tue.Apr.16.22:36:38.1996"@bnr.ca>. Date: Wed, 17 Apr 96 07:46:13 -0500 Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk > == "vivek (v.) kapil" > BTW, I thought if some idea ever becomes a standard thru' IETF > (I mean internet standard), one has to waive rights of patents. > You can consult IETF authorities re this. I have been intimately involved with one case of patent rights as they pertain to IETF protocol standardization. One does not have to waive patent rights. However, a working group will usually favor unencumbered technology over patented technology, as long as there isn't any technical reason for preferring the patented technology. Clearly, people would rather not pay if they can get equivalent results in another way. >> == C-K Toh, Cambridge University Computer Laboratory, >> Dear Folks, >> >> A new routing protocol for ad-hoc mobile network >> known as associativity-based routing was born. >> >> I am currently filing a US patent for this idea. >> >> Interested parties please contact me. Is it possible to find out more about this proposal, so that it can be compared to other ad-hoc proposals that might be considered in the upcoming BOF? Charlie P. From majordom Wed Apr 17 09:02:11 1996 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16607; Wed, 17 Apr 96 09:02:11 EDT Received: from zia.epm.ORNL.GOV by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16582; Wed, 17 Apr 96 09:02:01 EDT Received: from zia (LOCALHOST [127.0.0.1]) by zia.epm.ORNL.GOV (8.7.4/8.7.3) with SMTP id JAA08232 for ; Wed, 17 Apr 1996 09:01:57 -0400 (EDT) Message-Id: <3174EBC4.794B@ornl.gov> Date: Wed, 17 Apr 1996 09:01:56 -0400 From: Steve Batsell Organization: Oak Ridge National Laboratory X-Mailer: Mozilla 2.01 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: mmnet@itd.nrl.navy.mil Subject: Re: New Ad-Hoc Routing Protocol References: <"25873 Tue Apr 16 22:36:38 1996"@bnr.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk vivek (v.) kapil wrote: > > That's a great news CK, but why don't you present this idea > at the next IETF in Montreal. You may want to talk to > appropriate folks to arrange a BOF. Should you wish to discuss > here, I am sure lot of us will be ready to listen and give > commnents. > > BTW, I thought if some idea ever becomes a standard thru' IETF > (I mean internet standard), one has to waive rights of patents. > You can consult IETF authorities re this. > > Regards, > mmnet: I have two points to make on the recent mail traffic. First of all, a BOF meeting for the Montreal IETF meeting in June is being arranged, so there is no need for anyone else to try to arrange a meeting. This BOF will be a follow-on to the December BOF meeting. Secondly, I strongly oppose making any patented protocol an IETF standard. For that matter, any "official" standard, because it completely destroys the whole purpose of a standard as it is a negative incentive for companies to implement the standard if they know they will have to pay royalties. Quite to the oppose, I strongly support making free code of all contenters for the standard available on the Internet. The IETF has a long and honorable tradition of doing just this and I believe it has served the Internet community well. I believe everybody should have a chance to present their ideas at the ietf working group meetings and those ideas deemed "good" should be implemented in code and tested. Patented ideas have no place in the standards process, period [unless the company wishes to waive their rights]. The IETF leaves enough capability in their standards for companies to differentiate themselves in the marketplace. -- Steve Batsell, Network Research Group Leader MS 6367, Bldg 6012, Oak Ridge National Laboratory, Oak Ridge, TN 37831 423-574-7401 (phone) 423-574-0680 (Fax) sgb@ornl.gov http://www.epm.ornl.gov/~sgb/net.html From majordom Wed Apr 17 10:17:09 1996 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA20317; Wed, 17 Apr 96 10:17:09 EDT Received: from zia.epm.ORNL.GOV by itd.nrl.navy.mil (4.1/SMI-4.1) id AA20299; Wed, 17 Apr 96 10:16:59 EDT Received: from zia (LOCALHOST [127.0.0.1]) by zia.epm.ORNL.GOV (8.7.4/8.7.3) with SMTP id KAA08347 for ; Wed, 17 Apr 1996 10:16:55 -0400 (EDT) Message-Id: <3174FD56.ABD@ornl.gov> Date: Wed, 17 Apr 1996 10:16:54 -0400 From: Steve Batsell Organization: Oak Ridge National Laboratory X-Mailer: Mozilla 2.01 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: mmnet@itd.nrl.navy.mil Subject: 2nd request for speakers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk I am in the process of setting up a BOF meeting at the Montreal IETF meeting (June 24-27). If you would like to speak but haven't emailed me please do so as soon as possible. I am particularly interested in commercial and Internet applications of ad hoc networking. Thanks -- Steve Batsell, Network Research Group Leader MS 6367, Bldg 6012, Oak Ridge National Laboratory, Oak Ridge, TN 37831 423-574-7401 (phone) 423-574-0680 (Fax) sgb@ornl.gov http://www.epm.ornl.gov/~sgb/net.html From majordom Wed Apr 17 11:34:48 1996 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA23882; Wed, 17 Apr 96 11:34:48 EDT Received: from [132.250.92.68] (gumbo.itd.nrl.navy.mil) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA23871; Wed, 17 Apr 96 11:34:41 EDT Message-Id: <9604171534.AA23871@itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 17 Apr 1996 11:34:40 -0400 To: mmnet@itd.nrl.navy.mil From: macker@itd.nrl.navy.mil (Joseph P. Macker) Subject: review of draft RFC Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk To the mmnet group: Prior to Montreal, we would like to solicit reviews and comments on the Mobile Mesh draft RFC, entitled "Architectural Considerations for Mobile Mesh Networking". This was intended to be an informational RFC and can be found at ftp://ietf.cnri.reston.va.us/internet-drafts/draft-rfced-info-corson-00.txt. This will expire soon and needs to be resubmitted. Thanks, joe _/ _/ _/_/_/_/ _/ Joseph P. Macker, Code 5544 _/_/ _/ _/ _/ _/ Center for High Assurance Computer Systems _/ _/ _/ _/_/_/_/ _/ (202)-767-2001 _/ _/_/ _/ _/ _/ macker@itd.nrl.navy.mil _/ _/ _/ _/ _/_/_/_/ http://tonnant.itd.nrl.navy.mil/macker.html From majordom Wed Apr 17 14:48:58 1996 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA03024; Wed, 17 Apr 96 14:48:58 EDT Received: from CHIMAY.MACH.CS.CMU.EDU by itd.nrl.navy.mil (4.1/SMI-4.1) id AA03016; Wed, 17 Apr 96 14:48:50 EDT Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa19958; 17 Apr 96 14:48:27 EDT To: "vivek (v.) kapil" Cc: mmnet@itd.nrl.navy.mil In-Reply-To: Your message of "Tue, 16 Apr 96 22:36:00 EDT" <"25873 Tue Apr 16 22:36:38 1996"@bnr.ca> From: Dave Johnson Subject: Re: New Ad-Hoc Routing Protocol Date: Wed, 17 Apr 96 14:48:25 -0400 Message-Id: <19956.829766905@CHIMAY.MACH.CS.CMU.EDU> Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk >BTW, I thought if some idea ever becomes a standard thru' IETF >(I mean internet standard), one has to waive rights of patents. >You can consult IETF authorities re this. The rules for dealing with patented technology are spelled out in RFC 1602. The relevant part of that RFC says: (A) ISOC will not propose, adopt, or continue to maintain any standards, including but not limited to standards labelled Proposed, Draft or Internet Standards, which can only be practiced using technology or works that are subject to known copyrights, patents or patent applications, or other rights, except with the prior written assurance of the owner of rights that: l. ISOC may, without cost, freely implement and use the technology or works in its standards work; 2. upon adoption and during maintenance of an Internet Standard, any party will be able to obtain the right to implement and use the technology or works under specified, reasonable, non-discriminatory terms; and 3. the party giving the assurance has the right and power to grant the licenses and knows of no other copyrights, patents, patent applications, or other rights that may prevent ISOC and members of the Internet community from implementing and operating under the standard. So, the patent holder must at least grant licenses to anyone in a "non-discriminatory" maner, the right to use the technology under "reasonable" terms. The general operating rule in the IETF with respect to patents is to include patented technology in a standard *only* when there is no suitable non-patented solution available. Patented technology is sometimes also included in a standard as an optional feature, when it offers some real advantages over other solutions, but in this case it must at least be possible to use the protocol without using the optional feature based on the patented technology. All other things being equal (or close), the patented technology is not included in the standard. Dave From majordom Wed Apr 17 15:13:16 1996 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA04006; Wed, 17 Apr 96 15:13:16 EDT Received: from zia.epm.ORNL.GOV ([128.219.8.140]) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA03960; Wed, 17 Apr 96 15:13:09 EDT Received: from zia (LOCALHOST [127.0.0.1]) by zia.epm.ORNL.GOV (8.7.4/8.7.3) with SMTP id PAA08801 for ; Wed, 17 Apr 1996 15:11:35 -0400 (EDT) Message-Id: <31754266.41C6@ornl.gov> Date: Wed, 17 Apr 1996 15:11:34 -0400 From: Steve Batsell Organization: Oak Ridge National Laboratory X-Mailer: Mozilla 2.01 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: mmnet@itd.nrl.navy.mil Subject: Charter revisions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk We need to rewrite the charter for the proposed working group. I would like your comments on proposed changes. I have enclosed (below) a copy of the old charter. Mail changes to the mailing list. Once we have rewritten the charter, I will put it on the mailing list for more comments. Thanks, Steve ===================================================== Mobile Mesh Networks (mmnet) Charter Chair(s) * Stephen Batsell * M.Scott Corson * Joe Macker Routing Area Director * Joel Halpern Mailing List Information * General Discussion: mmnet@itd.nrl.navy.mil * To Subscribe: majordomo@itd.nrl.navy.mil * In body: subscribe mmnet * Archive: ftp://mars.itd.nrl.navy.mil/pub/mmnet Description of Working Group A "mobile mesh" network is an autonomous system of mobile routers connected by wireless links, the union of which form an arbitrary graph. The routers are free to move randomly; thus, the network's wireless topology may change rapidly and unpredictably. The mobile networks of interest here consist of routers which are free to move about arbitrarily. These routers and the end stations may be located in airplanes, ships, tanks, trucks, cars, even on people (wearable computers), and there may be multiple hosts per router. Such networks are envisioned to have dynamic, often rapidly changing, mesh topologies consisting of bandwidth-constraintedwireless links. These characteristics create a set of underlying assumptions for protocol design which differ from those used for the higher speed, fixed topology Internet. The focus of the working group will be to develop both unicast and multicast routing protocols that will operate efficiency in a mobile mesh environment. The working group will also address issues that directly relate to the routing functionality such as interfacing to the link layer and interaction with or integration of a resource reservation protocol such that the integrated services internetworking environment can be extended into the mobile domain. Goals and Milestones December 95 Hold BOF at Dallas IETF Discuss mobile mesh requirements and the architecture RFC. March 95 Los Angeles IETF: Hold first full meeting. Discuss what are appropriate routing protocols for a mobile environment. June 95 Review Internet Draft routing protocols. Discuss interface issues with both the link layer and the reservation protocol. Input comments into the RSVP working group. Future Meetings Review Internet Drafts for interface with link and transport layers. Submit mobile mesh routing protocols (unicast and multicast) to the IESG as proposed standards. Submit mobile mesh interface documents to the IESG as proposed standards. -- Steve Batsell, Network Research Group Leader MS 6367, Bldg 6012, Oak Ridge National Laboratory, Oak Ridge, TN 37831 423-574-7401 (phone) 423-574-0680 (Fax) sgb@ornl.gov http://www.epm.ornl.gov/~sgb/net.html From majordom Wed Apr 17 15:16:20 1996 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA04154; Wed, 17 Apr 96 15:16:20 EDT Received: from zia.epm.ORNL.GOV by itd.nrl.navy.mil (4.1/SMI-4.1) id AA04147; Wed, 17 Apr 96 15:16:13 EDT Received: from zia (LOCALHOST [127.0.0.1]) by zia.epm.ORNL.GOV (8.7.4/8.7.3) with SMTP id PAA08823 for ; Wed, 17 Apr 1996 15:16:08 -0400 (EDT) Message-Id: <31754377.2781@ornl.gov> Date: Wed, 17 Apr 1996 15:16:07 -0400 From: Steve Batsell Organization: Oak Ridge National Laboratory X-Mailer: Mozilla 2.01 (X11; U; IRIX 5.3 IP22) Mime-Version: 1.0 To: mmnet@itd.nrl.navy.mil Subject: ATM Wireless working group Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk For those interested in wireless ATM, the ATM Forum is setting up a Wireless ATM Working Group. I can't give out ATM Forum documents, but I have enclosed the header of the ATM Forum document so those that are in the ATM Forum will know which document to get. ====================== ATM Forum Technical Committee ATM Forum/96-0530/PLEN __________________________________________________________________________________ Title: Charter, Scope and Work Plan for Proposed Wireless ATM Working Group __________________________________________________________________________________ Source: D. Raychaudhuri, NEC USA, C&C Research Laboratories 4, Independence Way, Princeton, NJ 08540, USA. Tel: (609) 951-2980, Fax: (609) 951-2499; E-mail: ray@ccrl.nj.nec.com. Lou Dellaverson, Motorola, Schaumburg, IL, USA (FLD100@email.mot.com) Masahiro Umehira, NTT Wireless Systems Lab, Yokosuka, Japan (umehira@maria.wslab.ntt.jp) Jouni Mikkonen, Nokia Mobile Phones, Finland (jouni.mikkonen@nmp.nokia.com) Tim Phipps, Symbionics Ltd., Cambridge, UK (tgcp@symbionics.co.uk) John Porter, Olivetti Research Ltd., Cambridge, UK (jporter@cam-orl.co.uk) Christer Lind, Telia Research, Malmo, Sweden (christer.lind@malmo.trab.se) Hiroshi Suzuki, NEC C&C Research Laboratories, Kawasaki, Japan (hiroshi@nwk.cl.nec.co.jp) -- Steve Batsell, Network Research Group Leader MS 6367, Bldg 6012, Oak Ridge National Laboratory, Oak Ridge, TN 37831 423-574-7401 (phone) 423-574-0680 (Fax) sgb@ornl.gov http://www.epm.ornl.gov/~sgb/net.html From majordom Thu Apr 18 08:26:20 1996 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA03611; Thu, 18 Apr 96 08:26:20 EDT Received: from ursa.cus.cam.ac.uk by itd.nrl.navy.mil (4.1/SMI-4.1) id AA03372; Thu, 18 Apr 96 08:18:52 EDT Received: from bootes.cus.cam.ac.uk [131.111.8.1] (ident = root) by ursa.cus.cam.ac.uk with smtp (Smail-3.1.29.0 #77) id m0u9ses-00011lC; Thu, 18 Apr 96 13:17 BST Received: by bootes.cus.cam.ac.uk (Smail-3.1.29.0 #36) id m0u9ser-000BzLC; Thu, 18 Apr 96 13:17 BST Message-Id: Date: Thu, 18 Apr 96 13:17 BST From: ct10000@cus.cam.ac.uk (C. Toh) To: mmnet@itd.nrl.navy.mil Subject: Some Comments : draft RFC Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk Here are some comments : ------------------------ Where are the application viewpoints ? > Examples of Mobile Mesh Networks .. Better to explain if we are dealing with local or wide area basis.. > 3.1 Use of Event-Driven Routing for Quick Adaptation Agree. Quick Adaption must be done in an efficient way. >Event-driven mechanisms should be used the vast majority of the time to quickly and efficiently react to topological changes, while timer-based soft-state mechanisms are used to "soften" this hard state permitting its eventual clean up following rare error situations Agree. >3.3 Shortest-Path Routing (Is it worth the cost?) What about computation and implementation complexities ? > In a rapidly changing topology, it is likely that the topology will change again before a shortest-path computation can converge. Perhaps in the RFC, specification to the degree of mobility considered should be spelled out. Are we considering from pedestrian speed to vehicular speeds ? > Here, routing optimality of secondary importance; what matters is simply finding one or more routes quickly, with minimal overhead. `are' of secondary importance... The RFC mentions about multicast routing, reservation-based routing and congestion avoidance. I haven't really quite get it. How are all these related specifically to an ad-hoc network ? Maybe more details are needed ? The QoS aspects are not clear. Maybe a paragraph on defining QoS for ad-hoc networks will be useful ? Lastly, regarding the application aspects, don't you guys see the benefit of nomadic collaborative computing ? Hope this helps. Regards, C-K Toh, Cambridge University Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB2 3QG. E-Mail : Chai-Keong.Toh@cl.cam.ac.uk ------------------------------------------------------ URL : http://www.cl.cam.ac.uk/users/ct10000/index.html ------------------------------------------------------ Tel : 44 01223 335444 Fax : 44 01223 334678 ------------------------------------------------------ From majordom Thu Apr 18 11:27:47 1996 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA18492; Thu, 18 Apr 96 11:27:47 EDT Received: from arinc.com (interlock.arinc.com) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA18482; Thu, 18 Apr 96 11:27:38 EDT Received: from ccmail.arinc.com ([144.243.35.242]) by interlock.arinc.com with SMTP id <6156>; Thu, 18 Apr 1996 11:26:48 -0400 Received: from ccMail by ccmail.arinc.com (SMTPLINK V2.11 PreRelease 4) id AA829851989; Thu, 18 Apr 96 10:19:03 EST Date: Thu, 18 Apr 1996 11:19:03 -0400 From: mmcmahon@arinc.com Message-Id: <9603188298.AA829851989@ccmail.arinc.com> To: mmnet@itd.nrl.navy.mil Subject: Re: Charter revisions Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk 1. Obviously, our Goals and Milestones should be changed. Perhaps we should be dedicating some time to "create a set of underlying assumptions for protocol design" [next to last paragraph]? I don't think we came to closure in Dallas. Along these lines, perhaps we should be identifying specific services that our mobile mesh architecture is intended to support? 2. I agree that the primary focus of the WG should be resolving "routing" issues. And we,ve listed 2 issues that the WG will also address (interfacing to the link layer & interaction with integration [sic] of a resource reservation protocol). I suggest adding to the list: "developing innovative techniques for conserving bandwidth on the wireless links". For example, we could investigate ways to exploit the broadcast nature of our media to control and/or reduce the number of network accesses needed to deliver data reliably. I am not talking about a link layer protocol here; I'm suggesting that there may be methods that the Transport layer could employ to provide a reliable multi-destination delivery service. Current multicast services do not provide the desired reliability. Neither do they provide a means for originators to identify specific destinations of a single transmission. Our Army users are asking for both features. The desire, of course, is to provide the service using common network and transport protocols that work within an architecture supported by our mobile mesh routing protocols. If we choose not to solve the problem within the WG, at the very least, we need to provide the necessary support for these additional features when developing our routing protocols. ______________________________ Reply Separator _________________________________ Subject: Charter revisions Author: Steve Batsell at SMTPGATE Date: 4/17/96 3:33 PM We need to rewrite the charter for the proposed working group. I would like your comments on proposed changes. I have enclosed (below) a copy of the old charter. Mail changes to the mailing list. Once we have rewritten the charter, I will put it on the mailing list for more comments. Thanks, Steve ===================================================== Mobile Mesh Networks (mmnet) Charter Chair(s) * Stephen Batsell * M.Scott Corson * Joe Macker Routing Area Director * Joel Halpern Mailing List Information * General Discussion: mmnet@itd.nrl.navy.mil * To Subscribe: majordomo@itd.nrl.navy.mil * In body: subscribe mmnet * Archive: ftp://mars.itd.nrl.navy.mil/pub/mmnet Description of Working Group A "mobile mesh" network is an autonomous system of mobile routers connected by wireless links, the union of which form an arbitrary graph. The routers are free to move randomly; thus, the network's wireless topology may change rapidly and unpredictably. The mobile networks of interest here consist of routers which are free to move about arbitrarily. These routers and the end stations may be located in airplanes, ships, tanks, trucks, cars, even on people (wearable computers), and there may be multiple hosts per router. Such networks are envisioned to have dynamic, often rapidly changing, mesh topologies consisting of bandwidth-constraintedwireless links. These characteristics create a set of underlying assumptions for protocol design which differ from those used for the higher speed, fixed topology Internet. The focus of the working group will be to develop both unicast and multicast routing protocols that will operate efficiency in a mobile mesh environment. The working group will also address issues that directly relate to the routing functionality such as interfacing to the link layer and interaction with or integration of a resource reservation protocol such that the integrated services internetworking environment can be extended into the mobile domain. Goals and Milestones December 95 Hold BOF at Dallas IETF Discuss mobile mesh requirements and the architecture RFC. March 95 Los Angeles IETF: Hold first full meeting. Discuss what are appropriate routing protocols for a mobile environment. June 95 Review Internet Draft routing protocols. Discuss interface issues with both the link layer and the reservation protocol. Input comments into the RSVP working group. Future Meetings Review Internet Drafts for interface with link and transport layers. Submit mobile mesh routing protocols (unicast and multicast) to the IESG as proposed standards. Submit mobile mesh interface documents to the IESG as proposed standards. -- Steve Batsell, Network Research Group Leader MS 6367, Bldg 6012, Oak Ridge National Laboratory, Oak Ridge, TN 37831 423-574-7401 (phone) 423-574-0680 (Fax) sgb@ornl.gov http://www.epm.ornl.gov/~sgb/net.html From majordom Thu Apr 18 14:09:29 1996 Return-Path: Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA26959; Thu, 18 Apr 96 14:09:29 EDT Received: from bnr.ca (x400gate.bnr.ca) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA26951; Thu, 18 Apr 96 14:09:17 EDT X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 18 Apr 1996 14:08:51 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 18 Apr 1996 14:08:07 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 18 Apr 1996 14:08:00 -0400 Date: Thu, 18 Apr 1996 14:08:00 -0400 X400-Originator: /dd.id=1663884/g=vivek/i=v/s=kapil/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.867:18.03.96.18.08.07] X400-Content-Type: P2-1984 (2) Content-Identifier: re:Charter re... From: "vivek (v.) kapil" Message-Id: <"24935 Thu Apr 18 14:08:20 1996"@bnr.ca> To: mmnet@itd.nrl.navy.mil Subject: re:Charter revisions Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk The year in Goals and Milestones seems to be wrong. Should it not read 1996 instead of 1995 in all other occurrings except Dallas meeting (Dec 95). >===================================================== >Mobile Mesh Networks (mmnet) Charter > >Chair(s) > >* Stephen Batsell >* M.Scott Corson >* Joe Macker > >Routing Area Director > >* Joel Halpern > >Mailing List Information > >* General Discussion: mmnet@itd.nrl.navy.mil >* To Subscribe: majordomo@itd.nrl.navy.mil > * In body: subscribe mmnet >* Archive: ftp://mars.itd.nrl.navy.mil/pub/mmnet > >Description of Working Group > >A "mobile mesh" network is an autonomous system of mobile routers >connected >by wireless links, the union of which form an arbitrary graph. The >routers >are free to move randomly; thus, the network's wireless topology may >change >rapidly and unpredictably. The mobile networks of interest here consist >of >routers which are free to move about arbitrarily. These routers and the >end >stations may be located in airplanes, ships, tanks, trucks, cars, even >on >people (wearable computers), and there may be multiple hosts per router. > >Such networks are envisioned to have dynamic, often rapidly changing, >mesh >topologies consisting of bandwidth-constraintedwireless links. These >characteristics create a set of underlying assumptions for protocol >design >which differ from those used for the higher speed, fixed topology >Internet. > >The focus of the working group will be to develop both unicast and >multicast >routing protocols that will operate efficiency in a mobile mesh >environment. >The working group will also address issues that directly relate to the >routing >functionality such as interfacing to the link layer and interaction with >or >integration of a resource reservation protocol such that the integrated >services >internetworking environment can be extended into the mobile domain. > > >Goals and Milestones > >December 95 > Hold BOF at Dallas IETF Discuss mobile mesh requirements and the > architecture RFC. > >March 95 > Los Angeles IETF: Hold first full meeting. Discuss what are >appropriate > routing protocols for a mobile environment. > >June 95 > Review Internet Draft routing protocols. Discuss interface >issues with > both the link layer and the reservation protocol. Input comments >into > the RSVP working group. > >Future Meetings > Review Internet Drafts for interface with link and transport >layers. > > Submit mobile mesh routing protocols (unicast and multicast) to >the > IESG as proposed standards. > > Submit mobile mesh interface documents to the IESG as proposed > standards. > > >-- >Steve Batsell, Network Research Group Leader >MS 6367, Bldg 6012, >Oak Ridge National Laboratory, Oak Ridge, TN 37831 >423-574-7401 (phone) >423-574-0680 (Fax) >sgb@ornl.gov >http://www.epm.ornl.gov/~sgb/net.html >