From owner-manet@itd.nrl.navy.mil Mon Apr 2 01:11:11 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24687 for ; Mon, 2 Apr 2001 01:11:10 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id WAA01573 for manet-outgoing; Sun, 1 Apr 2001 22:24:02 -0400 (EDT) Received: from m018.com ([210.112.11.138]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id WAA01568 for ; Sun, 1 Apr 2001 22:23:59 -0400 (EDT) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 2 Apr 2001 11:16:46 +0900 Received: from itd.nrl.navy.mil ([132.250.83.3]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 2 Apr 2001 11:05:00 +0900 Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA16601 for manet-outgoing; Sat, 31 Mar 2001 05:09:01 -0500 (EST) Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id FAA16596 for ; Sat, 31 Mar 2001 05:08:58 -0500 (EST) Received: (cpmta 29139 invoked from network); 31 Mar 2001 02:08:54 -0800 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.221) with SMTP; 31 Mar 2001 02:08:54 -0800 X-Sent: 31 Mar 2001 10:08:54 GMT Message-ID: <004601c0b9ca$9ce29040$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Fred L. Templin" , Cc: References: <52vgp585pp.fsf@sean.ebone.net> <3ABFA01D.7C23A7CD@erg.sri.com> <3ABFEF56.93D9723F@erg.sri.com> <3AC492DD.8E990380@mitre.org> <3AC4BB89.7889297D@erg.sri.com> <003701c0b95f$24f45d40$6501a8c0@philneum> <3AC5121F.7280E897@erg.sri.com> Subject: Re: Challenges for the MANET addressing model Date: Sat, 31 Mar 2001 04:08:56 -0600 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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Fred, At the slight risk of getting off on a rant, at least with IPv6's implict tunnelling capability (as used in MIP), you could tunnel directly over/through these MANET private IPv6 address space bubbles right? So even if MANETS float about on the edge or Interconnect portions of the global Internet they could in theory work the same with these private IPv6 address spaces while tunnelling other traffic over/through them. Thanks, Phil ----- Original Message ----- From: "Fred L. Templin" > Phil, > > I think it's a good question, but I don't think MANETs will > always necessarily live on the edge. In some cases, a MANET > may be the only alternative for transit between disconnected > portions of a larger network. > > Fred Templin > > Phil > From owner-manet@itd.nrl.navy.mil Mon Apr 2 16:55:08 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00804 for ; Mon, 2 Apr 2001 16:55:06 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA17875 for manet-outgoing; Mon, 2 Apr 2001 14:31:26 -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 OAA17861; Mon, 2 Apr 2001 14:31:21 -0400 (EDT) Message-Id: <5.0.1.4.2.20010402140107.01955ec8@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 02 Apr 2001 14:32:45 -0400 To: Charlie Perkins , manet@itd.nrl.navy.mil From: Joe Macker Subject: Re: Challenges for the MANET addressing model In-Reply-To: <3AC59736.59616C49@iprg.nokia.com> References: <52vgp585pp.fsf@sean.ebone.net> <3ABFA01D.7C23A7CD@erg.sri.com> <3ABFEF56.93D9723F@erg.sri.com> <3AC492DD.8E990380@mitre.org> <3AC4BB89.7889297D@erg.sri.com> <3AC4D7A9.7DFB461A@mitre.org> <3AC50C17.C3B2BE41@erg.sri.com> <3AC56AB2.AB35342D@mitr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 12:37 AM 3/31/2001 -0800, Charlie Perkins wrote: >Hello Fred and Kevin, > > > > > > My view is that > > > the MANET should look just like a connected Ethernet segment; every > > > node on the network uses the same logical IP subnet prefix but there > > > may be multiple hops through the same logical IP subnet required to > > > reach some nodes. In order to support this view, I advocate relaxing > > > the notion that MANET routers are "routers" in the traditional sense. > > > Instead, they do something that is not quite routing and not quite > > > bridging but something in between. > >It seems to me that manet nodes have links, and that using manet >routing protocols we can join those links into routing paths between >nodes that are not directly connected. That sounds a lot like >internetworking to me, even if we don't have aggregation. In fact, >when aggregation is available, it can be fit into manet routing just >by handling prefixes instead of full-length IP addresses (which are >the aggregations of one node, described by a /32 prefix). I also see manet routing nodes as performing basic internetwork routing and being able to handle aggregation or /32 prefixes. Also, Scott and I had some older discussion related to a view at that time on manet node definitions in this 1998 MC2R article: http://tonnant.itd.nrl.navy.mil/manet/mc2r/manet_mc2rv2n1.ps At that time, we talked about the use of router node identifiers (e.g., could be one of the local IP interface addresses as in OSPF).....prefixes could be advertised as needed (the degenerate case of a single host address is just a special case). Good old IP routing, don't panic. -Joe From owner-manet@itd.nrl.navy.mil Tue Apr 3 01:54:16 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16395 for ; Tue, 3 Apr 2001 01:54:16 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id XAA28123 for manet-outgoing; Mon, 2 Apr 2001 23:18:55 -0400 (EDT) Received: from sfo.erg.sri.com (sfo.erg.sri.com [128.18.100.4]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id XAA28114 for ; Mon, 2 Apr 2001 23:18:52 -0400 (EDT) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id NAA15604; Mon, 2 Apr 2001 13:06:25 -0700 (PDT) Message-ID: <3AC8DC33.668F957@erg.sri.com> Date: Mon, 02 Apr 2001 13:08:19 -0700 From: "Fred L. Templin" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil CC: templin@erg.sri.com Subject: Re: Challenges for the MANET addressing model References: <52vgp585pp.fsf@sean.ebone.net> <3ABFA01D.7C23A7CD@erg.sri.com> <3ABFEF56.93D9723F@erg.sri.com> <3AC492DD.8E990380@mitre.org> <3AC4BB89.7889297D@erg.sri.com> <3AC4D7A9.7DFB461A@mitre.org> <3AC50C17.C3B2BE41@erg.sri.com> <3AC56AB2.AB35342D@mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Kevin, Certainly no offense taken on my end; this has been interesting and illuminating discussion in my view. Some follow-up thoughts on what you've said: Kevin Grace wrote: > > "Fred L. Templin" wrote: > > My view is that > > the MANET should look just like a connected Ethernet segment; every > > node on the network uses the same logical IP subnet prefix but there > > may be multiple hops through the same logical IP subnet required to > > reach some nodes. In order to support this view, I advocate relaxing > > the notion that MANET routers are "routers" in the traditional sense. > > Instead, they do something that is not quite routing and not quite > > bridging but something in between. > > Forwarding packets below the IP layer in an attempt to hide the fact > that not all interfaces on a subnet are directly connected will create > problems when the subnet becomes partitioned. No longer will it be > true that the subnet interfaces can be reached via a single network > route, though this was the original goal of utilizing subnets. This is a good point, but in terms of connecting a MANET to the Internet - either as a stub network or a transit network - I'm not convinced the situation is any better/worse whether the MANET is treated as a coherent subnet or just a collection of independent hosts with their own unique /32 network numbers. The cases for a partition are: 1) Some of the nodes retain reachability to a gateway that connects the MANET to the Internet, while others wander off and are left with no gateway to the Internet. 2) The MANET has two or more gateways to the Internet. (Let's focus on two such gateways and call them 'A' and 'B'.) When the MANET partitions, there is no longer MANET-level reachability between 'A' and 'B', with some nodes in the MANET only able to reach 'A' and others only able to reach 'B'. In situation 1), nothing can be done to help the wanderers in any case; they are simply adrift in the wilderness unless and until they either return to their home MANET or find another MANET to graft onto. Situation 2) is where the differences lie, and I see challenges for both of the approaches we have discussed: Classical IP Router approach: ***************************** In the case that you are treating the MANET as a collection of independent routers; each with its own /32 network prefix, then 'A' and 'B' are not really Internet gateways. Instead, they are NAT boxes that convert addresses coming from the MANET into IPv4 addresses that make topological sense for the particular point of attachment to the Internet. From the Internet's perspective, 'A' and 'B' appear to be simple (albeit active!) hosts; not gateways to complex networks. In order to access Internet services, some subset of the nodes in the MANET will "bind" to 'A' while other nodes will "bind" to 'B'. When the partition occurs, nodes that were "bound" to 'A' and retain reachability to 'A' will still operate just fine. (Same as for nodes "bound" to 'B'). But, suppose some node 'x' that was bound to 'A' loses touch with 'A' when the partition occurs but still has connectivity to 'B'. First of all, any existing sessions between 'x' and nodes out on the Internet would break, since the NAT translation for 'x' cached in the correspondent nodes out in the Internet would *still* be 'A', and 'x' is no longer reachable through 'A'. Also, since no subnet-level service discovery support exists for the dissemination of such things as Router Advertisements in the model you advocate, you would need to do something special to get 'x' to realize that it should cease treating 'A' as its bound gateway for new sessions and begin treating 'B' as its bound gateway. Another problem occurs for MANET servers that are advertised out to the Internet by 'A' and 'B'. If 'A' advertises a service that is provided by node 'x' within the MANET, but 'x' loses contact with 'A' when the partition occurs, then the service will be unreachable until the partition is repaired. Classical IP subnet approach: ***************************** In the case that you are treating the MANET as a coherent logical IP subnet, then 'A' and 'B' are true gateways. In order to access Internet services, some subset of the nodes in the MANET will set their default route to 'A' while other nodes will set their default route to 'B'. When the partition occurs, the MANET nodes will readjust their default roures just fine if necessary by detecting a change in the router advertisements they are receiving. Correspondent nodes out in the Internet will *still* have valid address cachings for the MANET nodes, and service advertisments from the MANET will *still* point to the same IPv4 addresses. But the problem, of course, is that the subnet itself is partitioned and MANET nodes which were formerly reachable through 'A' may no longer be reachable through 'A' even though Internet routing suggests otherwise. An easy fix for this is for 'A' and 'B' to exchange MANET topology information over their Internet interfaces, since the MANET partition presumably did not affect reachability between 'A' and 'B' over the Internet. Then, for any node 'x' that is no longer reachable from 'A' but still reachable from 'B', 'A' can automatically tunnel messages addressed to 'x' over the Internet to 'B'. This obviously introduces triangle routing, but it provides a simple fix for reachablility. Another possibility is for one of 'A' or 'B' to re-number their MANET interface, cease advertising their original subnet prefix out to the Internet, and begin advertising the *new* subnet prefix out to the Internet. Then, the situation reduces to Mobile IP. In other words, the nodes associated with whichever gateway did the renumbering would detect a prefix change via router advertisments and adopt a care-of address out of the new prefix. A final possibility would be for one or both of 'A' and 'B' to cease acting like a true Internet router and start doing NAT on behalf of their associated MANET nodes. But, I've already expressed my misgivings about this sort of approach. > Just because the subnet is partitioned by a lack of connectivity below > IP does not mean that the MANET is necessarily partitioned. Yet the > attempt to try to hide the topology of the subnet from IP precludes > the possibility of healing the partition by leveraging connectivity at > the IP layer (unless the thingy below IP provides reachability > information, but, this would require IP to use host routes so then > there'd be little reason to do subnets since route aggregation will > not be realized). Had all forwarding been done at the IP layer, there > would not be this accidental partitioning. I'm not sure I followed the case you are referring to above. Are you referring to one of the partition instances I mentioned above, or are you considering some other case of partitioning? > It does not appear to me that subnets are appropriate for MANET's. And > if the purpose of doing forwarding below IP is solely to support > subnets, then I don't see a need to forward below IP. > > I hope I have not offended anyone with these comments...these are just > my humble opinions... I maintain my viewpoint that the classical IPv4 subnet paradigm provides a more natural fit for the Internet, and what is going on in MANETs is *not* classical IPv4 routing in its true sense. The stereotypical MANET "router" configuration is something like a laptop with a single IEEE 802.11 interface attached. When the node is called upon to "route", it receives a packet on its IEEE 802.11 interface and then turns around and send it right back out the *same* interface it came in on! This is *not* Internet routing in the traditional sense; in fact, on most implementations you have to explicitly disable ICMP Redirects in order to support this paradigm in the first place. Fred templin@erg.sri.com From owner-manet@itd.nrl.navy.mil Tue Apr 3 01:59:58 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17022 for ; Tue, 3 Apr 2001 01:59:57 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id XAA28122 for manet-outgoing; Mon, 2 Apr 2001 23:18:54 -0400 (EDT) Received: from sfo.erg.sri.com (sfo.erg.sri.com [128.18.100.4]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id XAA28112 for ; Mon, 2 Apr 2001 23:18:51 -0400 (EDT) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id NAA15830; Mon, 2 Apr 2001 13:13:11 -0700 (PDT) Message-ID: <3AC8DDC9.268C41CE@erg.sri.com> Date: Mon, 02 Apr 2001 13:15:05 -0700 From: "Fred L. Templin" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil CC: templin@erg.sri.com Subject: Re: Challenges for the MANET addressing model References: <52vgp585pp.fsf@sean.ebone.net> <3ABFA01D.7C23A7CD@erg.sri.com> <3ABFEF56.93D9723F@erg.sri.com> <3AC492DD.8E990380@mitre.org> <3AC4BB89.7889297D@erg.sri.com> <003701c0b95f$24f45d40$6501a8c0@philneum> <3AC5121F.7280E897@erg.sri.com> <004601c0b9ca$9ce29040$6501a8c0@philneum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Phil, I don't want to get into detail on this, but I'm a big believer that many of the issues we have been discussing will be either fixed or made much less difficult in IPv6. I'm also a big believer in automatic IPv6-in-IPv4 tunneling to get from private IPv4 address spaces out to the global IPv6 Internet - see my draft on this subject at: http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-00.txt But, once everything goes native IPv6, we should never need to worry about private IPv6 address spaces again - right? Fred templin@erg.sri.com Phil Neumiller wrote: > > Fred, > > At the slight risk of getting off on a rant, at least with IPv6's > implict tunnelling capability (as used in MIP), you could tunnel > directly over/through these MANET private IPv6 address space > bubbles right? So even if MANETS float about on the edge > or Interconnect portions of the global Internet they could in > theory work the same with these private IPv6 address spaces > while tunnelling other traffic over/through them. > > Thanks, > > Phil From owner-manet@itd.nrl.navy.mil Tue Apr 3 12:54:57 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07844 for ; Tue, 3 Apr 2001 12:54:57 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA07542 for manet-outgoing; Tue, 3 Apr 2001 10:08:44 -0400 (EDT) Received: from smtpproxy2.mitre.org (smtpproxy2.mitre.org [128.29.154.90]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA07537 for ; Tue, 3 Apr 2001 10:08:41 -0400 (EDT) Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4]) by smtpproxy2.mitre.org (8.9.3/8.9.3) with ESMTP id KAA20193; Tue, 3 Apr 2001 10:08:02 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id KAA11663; Tue, 3 Apr 2001 10:08:00 -0400 (EDT) Received: from vsb083.mitre.org (129.83.21.83) by mailhub2.mitre.org with SMTP id 6238091; Tue, 03 Apr 2001 10:07:56 -0400 Message-ID: <3AC9D88C.F5397E9E@mitre.org> Date: Tue, 03 Apr 2001 10:05:00 -0400 From: Kevin Grace X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1} (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fred L. Templin" CC: manet@itd.nrl.navy.mil Subject: Re: Challenges for the MANET addressing model References: <52vgp585pp.fsf@sean.ebone.net> <3ABFA01D.7C23A7CD@erg.sri.com> <3ABFEF56.93D9723F@erg.sri.com> <3AC492DD.8E990380@mitre.org> <3AC4BB89.7889297D@erg.sri.com> <3AC4D7A9.7DFB461A@mitre.org> <3AC50C17.C3B2BE41@erg.sri.com> <3AC56AB2.AB35342D@mitre.org> <3AC8DC33.668F957@erg.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi Fred, > Classical IP Router approach: > ***************************** > In the case that you are treating the MANET as a collection of > independent routers; each with its own /32 network prefix, then > 'A' and 'B' are not really Internet gateways. Instead, they are > NAT boxes that convert addresses coming from the MANET into IPv4 > addresses that make topological sense for the particular point > of attachment to the Internet. From the Internet's perspective, > 'A' and 'B' appear to be simple (albeit active!) hosts; not > gateways to complex networks. There's no requirement for NAT...I merely suggested it as a quick and very dirty way of allowing MANET nodes with arbitrary addresses to gain connectivity to nodes outside the MANET. A better approach is to assign MANET node addresses from known address blocks and advertise routes to these spaces on the border router interfaces that reside on the "fixed" network. > In order to access Internet services, some subset of the nodes in > the MANET will "bind" to 'A' while other nodes will "bind" to 'B'. > When the partition occurs, nodes that were "bound" to 'A' and > retain reachability to 'A' will still operate just fine. (Same > as for nodes "bound" to 'B'). But, suppose some node 'x' that was > bound to 'A' loses touch with 'A' when the partition occurs but > still has connectivity to 'B'. First of all, any existing sessions > between 'x' and nodes out on the Internet would break, since the > NAT translation for 'x' cached in the correspondent nodes out in > the Internet would *still* be 'A', and 'x' is no longer reachable > through 'A'. Also, since no subnet-level service discovery support > exists for the dissemination of such things as Router Advertisements > in the model you advocate, you would need to do something special > to get 'x' to realize that it should cease treating 'A' as its > bound gateway for new sessions and begin treating 'B' as its > bound gateway. Another problem occurs for MANET servers that are > advertised out to the Internet by 'A' and 'B'. If 'A' advertises > a service that is provided by node 'x' within the MANET, but 'x' > loses contact with 'A' when the partition occurs, then the service > will be unreachable until the partition is repaired. Yes, NAT has problems when there is more than one border router running NAT. But, again, NAT is not a requirement and can easily be avoided. > Classical IP subnet approach: > ***************************** > In the case that you are treating the MANET as a coherent logical > IP subnet, then 'A' and 'B' are true gateways. > In order to access Internet services, some subset of > the nodes in the MANET will > set their default route to 'A' while other nodes will set their > default route to 'B'. When the partition occurs, the MANET nodes > will readjust their default roures just fine if necessary by > detecting a change in the router advertisements they are receiving. > Correspondent nodes out in the Internet will *still* have valid > address cachings for the MANET nodes, and service advertisments > from the MANET will *still* point to the same IPv4 addresses. But > the problem, of course, is that the subnet itself is partitioned > and MANET nodes which were formerly reachable through 'A' may no > longer be reachable through 'A' even though Internet routing > suggests otherwise. > > An easy fix for this is for 'A' and 'B' to exchange MANET topology > information over their Internet interfaces, since the MANET partition > presumably did not affect reachability between 'A' and 'B' over the > Internet. Then, for any node 'x' that is no longer reachable from > 'A' but still reachable from 'B', 'A' can automatically tunnel > messages addressed to 'x' over the Internet to 'B'. This obviously > introduces triangle routing, but it provides a simple fix for > reachablility. Yes, in fact tunneling topology information across the fixed network between border routers is exactly the approach we took with the Mobile Mesh Border Gateway Protocol. > > Just because the subnet is partitioned by a lack of connectivity below > > IP does not mean that the MANET is necessarily partitioned. Yet the > > attempt to try to hide the topology of the subnet from IP precludes > > the possibility of healing the partition by leveraging connectivity at > > the IP layer (unless the thingy below IP provides reachability > > information, but, this would require IP to use host routes so then > > there'd be little reason to do subnets since route aggregation will > > not be realized). Had all forwarding been done at the IP layer, there > > would not be this accidental partitioning. > > I'm not sure I followed the case you are referring to above. Are > you referring to one of the partition instances I mentioned above, > or are you considering some other case of partitioning? Actually, I was referring to a more general form of your case #2. That is, the subnet is partitioned (ie. a connected graph can not be drawn that contains all the *interfaces* of the subnet) but the network is not partitioned (ie. a connected graph can be drawn that contains all the *nodes* of the network). In this case, forwarding packets below IP is not sufficient to heal the subnet partition. The only way to heal this case of partitioning is to forward at IP, and this would require host routes rather than network routes. This means there's little reason to do subnets since the goal of achieving route aggregation will not be realized. I don't see any advantages to forwarding below IP, only shortcomings. Are there advantages that you have not mentioned? Kevin "Fred L. Templin" wrote: > > Kevin, > > Certainly no offense taken on my end; this has been interesting > and illuminating discussion in my view. Some follow-up thoughts > on what you've said: > > Kevin Grace wrote: > > > > "Fred L. Templin" wrote: > > > My view is that > > > the MANET should look just like a connected Ethernet segment; every > > > node on the network uses the same logical IP subnet prefix but there > > > may be multiple hops through the same logical IP subnet required to > > > reach some nodes. In order to support this view, I advocate relaxing > > > the notion that MANET routers are "routers" in the traditional sense. > > > Instead, they do something that is not quite routing and not quite > > > bridging but something in between. > > > > Forwarding packets below the IP layer in an attempt to hide the fact > > that not all interfaces on a subnet are directly connected will create > > problems when the subnet becomes partitioned. No longer will it be > > true that the subnet interfaces can be reached via a single network > > route, though this was the original goal of utilizing subnets. > > This is a good point, but in terms of connecting a MANET to the > Internet - either as a stub network or a transit network - I'm not > convinced the situation is any better/worse whether the MANET is > treated as a coherent subnet or just a collection of independent > hosts with their own unique /32 network numbers. The cases for > a partition are: > > 1) Some of the nodes retain reachability to a gateway that > connects the MANET to the Internet, while others wander > off and are left with no gateway to the Internet. > > 2) The MANET has two or more gateways to the Internet. (Let's > focus on two such gateways and call them 'A' and 'B'.) When > the MANET partitions, there is no longer MANET-level > reachability between 'A' and 'B', with some nodes in the > MANET only able to reach 'A' and others only able to reach > 'B'. > > In situation 1), nothing can be done to help the wanderers in any > case; they are simply adrift in the wilderness unless and until > they either return to their home MANET or find another MANET to > graft onto. Situation 2) is where the differences lie, and I see > challenges for both of the approaches we have discussed: > > Classical IP Router approach: > ***************************** > In the case that you are treating the MANET as a collection of > independent routers; each with its own /32 network prefix, then > 'A' and 'B' are not really Internet gateways. Instead, they are > NAT boxes that convert addresses coming from the MANET into IPv4 > addresses that make topological sense for the particular point > of attachment to the Internet. From the Internet's perspective, > 'A' and 'B' appear to be simple (albeit active!) hosts; not > gateways to complex networks. > > In order to access Internet services, some subset of the nodes in > the MANET will "bind" to 'A' while other nodes will "bind" to 'B'. > When the partition occurs, nodes that were "bound" to 'A' and > retain reachability to 'A' will still operate just fine. (Same > as for nodes "bound" to 'B'). But, suppose some node 'x' that was > bound to 'A' loses touch with 'A' when the partition occurs but > still has connectivity to 'B'. First of all, any existing sessions > between 'x' and nodes out on the Internet would break, since the > NAT translation for 'x' cached in the correspondent nodes out in > the Internet would *still* be 'A', and 'x' is no longer reachable > through 'A'. Also, since no subnet-level service discovery support > exists for the dissemination of such things as Router Advertisements > in the model you advocate, you would need to do something special > to get 'x' to realize that it should cease treating 'A' as its > bound gateway for new sessions and begin treating 'B' as its > bound gateway. Another problem occurs for MANET servers that are > advertised out to the Internet by 'A' and 'B'. If 'A' advertises > a service that is provided by node 'x' within the MANET, but 'x' > loses contact with 'A' when the partition occurs, then the service > will be unreachable until the partition is repaired. > > Classical IP subnet approach: > ***************************** > In the case that you are treating the MANET as a coherent logical > IP subnet, then 'A' and 'B' are true gateways. In order to access Internet services, some subset of > the nodes in the MANET will > set their default route to 'A' while other nodes will set their > default route to 'B'. When the partition occurs, the MANET nodes > will readjust their default roures just fine if necessary by > detecting a change in the router advertisements they are receiving. > Correspondent nodes out in the Internet will *still* have valid > address cachings for the MANET nodes, and service advertisments > from the MANET will *still* point to the same IPv4 addresses. But > the problem, of course, is that the subnet itself is partitioned > and MANET nodes which were formerly reachable through 'A' may no > longer be reachable through 'A' even though Internet routing > suggests otherwise. > > An easy fix for this is for 'A' and 'B' to exchange MANET topology > information over their Internet interfaces, since the MANET partition > presumably did not affect reachability between 'A' and 'B' over the > Internet. Then, for any node 'x' that is no longer reachable from > 'A' but still reachable from 'B', 'A' can automatically tunnel > messages addressed to 'x' over the Internet to 'B'. This obviously > introduces triangle routing, but it provides a simple fix for > reachablility. Another possibility is for one of 'A' or 'B' to > re-number their MANET interface, cease advertising their original > subnet prefix out to the Internet, and begin advertising the *new* > subnet prefix out to the Internet. Then, the situation reduces to > Mobile IP. In other words, the nodes associated with whichever > gateway did the renumbering would detect a prefix change via > router advertisments and adopt a care-of address out of the new > prefix. A final possibility would be for one or both of 'A' and > 'B' to cease acting like a true Internet router and start doing > NAT on behalf of their associated MANET nodes. But, I've already > expressed my misgivings about this sort of approach. > > > Just because the subnet is partitioned by a lack of connectivity below > > IP does not mean that the MANET is necessarily partitioned. Yet the > > attempt to try to hide the topology of the subnet from IP precludes > > the possibility of healing the partition by leveraging connectivity at > > the IP layer (unless the thingy below IP provides reachability > > information, but, this would require IP to use host routes so then > > there'd be little reason to do subnets since route aggregation will > > not be realized). Had all forwarding been done at the IP layer, there > > would not be this accidental partitioning. > > I'm not sure I followed the case you are referring to above. Are > you referring to one of the partition instances I mentioned above, > or are you considering some other case of partitioning? > > > It does not appear to me that subnets are appropriate for MANET's. And > > if the purpose of doing forwarding below IP is solely to support > > subnets, then I don't see a need to forward below IP. > > > > I hope I have not offended anyone with these comments...these are just > > my humble opinions... > > I maintain my viewpoint that the classical IPv4 subnet paradigm > provides a more natural fit for the Internet, and what is going on > in MANETs is *not* classical IPv4 routing in its true sense. The > stereotypical MANET "router" configuration is something like a > laptop with a single IEEE 802.11 interface attached. When the node > is called upon to "route", it receives a packet on its IEEE 802.11 > interface and then turns around and send it right back out the > *same* interface it came in on! This is *not* Internet routing in > the traditional sense; in fact, on most implementations you have > to explicitly disable ICMP Redirects in order to support this > paradigm in the first place. > > Fred > templin@erg.sri.com From owner-manet@itd.nrl.navy.mil Wed Apr 4 05:12:22 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA11805 for ; Wed, 4 Apr 2001 05:12:22 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA28675 for manet-outgoing; Wed, 4 Apr 2001 02:49:05 -0400 (EDT) Received: from sfo.erg.sri.com (sfo.erg.sri.com [128.18.100.4] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id CAA28665 for ; Wed, 4 Apr 2001 02:49:03 -0400 (EDT) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id LAA12875; Tue, 3 Apr 2001 11:42:03 -0700 (PDT) Message-ID: <3ACA19F2.6F760715@erg.sri.com> Date: Tue, 03 Apr 2001 11:44:02 -0700 From: "Fred L. Templin" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil CC: templin@erg.sri.com Subject: Re: Challenges for the MANET addressing model References: <52vgp585pp.fsf@sean.ebone.net> <3ABFA01D.7C23A7CD@erg.sri.com> <3ABFEF56.93D9723F@erg.sri.com> <3AC492DD.8E990380@mitre.org> <3AC4BB89.7889297D@erg.sri.com> <3AC4D7A9.7DFB461A@mitre.org> <3AC50C17.C3B2BE41@erg.sri.com> <3AC56AB2.AB35342D@mitr <3AC59736.59616C49@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Charlie, I just sent a reply to Kevin's most recent message that also addresses some of the points you are making here. But, I'll comment on a few of the specific items you brought out as well: Charlie Perkins wrote: > I'd be just as happy if 255.255.255.255 were forwarded to all manet nodes. > Either that, or maybe we should change AODV so that some sort of > "all-nodes-multicast" address should be used for propagating RREQ > messages. So, it seems you perceive the need for service discovery protocols in which messages would be forwarded beyond a single hop in cases in which the IETF literature claims they MUST NOT be forwarded. The literature is clear in stating that the all-1's broadcast ("limited broadcast") MUST NOT be forwarded to other networks. So, if you are assigning /32 prefixes to your interfaces then it is effectively a violation to even send all-1's broadcasts to your single hop neighbors! My main goal in initiating this discussion was to try to figure out a way for service discovery protocols to work across multiple hops, and it appears that there is no standard that would support multi-hopping either the all-1's broadcast or the low-numbered multicasts addresses within a MANET. > > > Anyway, I'm not saying that the approach you are suggesting is > > > invalid; I'm just saying that it bends the existing rules for > > > host and router implementations. It seems to me that some rules > > > will have to be bent in order for MANETs to play in the global > > > Internet. But, I think we need to look at the "pain vs. gain" > > > tradeoffs for the various alternatives. > > Agreed, and I think that typically the tradeoff is best if we can > identify and conform to natural models of operation. Here, > recognizing the natural differences between wireless and Ethernet > could easily lead to the conclusion that indeed wireless links > DO enable one-hop connectivity to multiple different subnets. Let me toss out an interesting example and see how you think this fits in with natural models of operation. Suppose you wanted to line up two or more RIP routers along the periphery of a MANET so that the MANET would have multiple points of connection to the Internet. (Let's assume that the MANET has been arranged so that it is feasible to advertise an aggregatable prefix, since the MANET properly contains the set of nodes which share that prefix.) Then, the RIP routers would need to exchange information with each other in order to maintain consistency. The way this is ordinarily done is by the RIP routers sending messages to the "All_Routers_Multicast" address on their common attachment network. But, if that common attachment network is a MANET then the "All_Routers_Multicast" messages will go no further than a single hop. What do we say about such a configuration? Do we say that it just isn't supported on MANET? Or, do we re-write the rules for how "All_Routers_Multicast" should be handled on MANETs? > > > Instead, they do something that is not quite routing and not quite > > > bridging but something in between. Perhaps the truth lies somewhere > > > in the middle of these two viewpoints - or perhaps there is no one > > > universal truth? > > The truth is that wired network links have a much more restricted > kind of connectivity than wireless network links do. We should try > to remodel subnet (including /32) connectivity in order to find the > most natural way to fit into the IP internetworking scheme. I agree. In order to bring this remodeling into the general Internetworking lexicon, however, I think it needs to be reflected either through supplemental text in existing IETF standards documents or new standards-tract documents that emerge from this working group. > Regards, > Charlie P. Thanks, Fred Templin templin@erg.sri.com From owner-manet@itd.nrl.navy.mil Wed Apr 4 05:20:17 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA11955 for ; Wed, 4 Apr 2001 05:20:17 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA28676 for manet-outgoing; Wed, 4 Apr 2001 02:49:07 -0400 (EDT) Received: from sfo.erg.sri.com (sfo.erg.sri.com [128.18.100.4] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id CAA28667 for ; Wed, 4 Apr 2001 02:49:03 -0400 (EDT) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id LAA11576; Tue, 3 Apr 2001 11:02:45 -0700 (PDT) Message-ID: <3ACA10BC.5D326AA7@erg.sri.com> Date: Tue, 03 Apr 2001 11:04:44 -0700 From: "Fred L. Templin" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil CC: templin@erg.sri.com Subject: Re: Challenges for the MANET addressing model References: <52vgp585pp.fsf@sean.ebone.net> <3ABFA01D.7C23A7CD@erg.sri.com> <3ABFEF56.93D9723F@erg.sri.com> <3AC492DD.8E990380@mitre.org> <3AC4BB89.7889297D@erg.sri.com> <3AC4D7A9.7DFB461A@mitre.org> <3AC50C17.C3B2BE41@erg.sri.com> <3AC56AB2.AB35342D@mitre.org> <3AC8DC33.668F957@erg.sri.com> <3AC9D88C.F5397E9E@mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Kevin, Kevin Grace wrote: > > Hi Fred, > > > Classical IP Router approach: > > ***************************** > > In the case that you are treating the MANET as a collection of > > independent routers; each with its own /32 network prefix, then > > 'A' and 'B' are not really Internet gateways. Instead, they are > > NAT boxes that convert addresses coming from the MANET into IPv4 > > addresses that make topological sense for the particular point > > of attachment to the Internet. From the Internet's perspective, > > 'A' and 'B' appear to be simple (albeit active!) hosts; not > > gateways to complex networks. > > There's no requirement for NAT...I merely suggested it as a quick and > very dirty way of allowing MANET nodes with arbitrary addresses to > gain connectivity to nodes outside the MANET. A better approach is to > assign MANET node addresses from known address blocks and advertise > routes to these spaces on the border router interfaces that reside on > the "fixed" network. So, you seem to be agreeing then that the ability to advertise an aggregated prefix (or prefixes) out to the Internet is a better approach from the standpoint of attaching a MANET as a stub network or transit network to the Internet. This is one of the most important aspects of what I have been saying. In terms of the nodes that have arbitrary addresses then, the approach I advocate is MobileIP. In other words, the machine(s) that connect the MANET to the Internet support the MobileIP home agent/foreign agent paradigm on behalf of nodes with "foreign" IPv4 prefixes with respect to the point of attachement to the Internet. > > In order to access Internet services, some subset of the nodes in > > the MANET will "bind" to 'A' while other nodes will "bind" to 'B'. > > When the partition occurs, nodes that were "bound" to 'A' and > > retain reachability to 'A' will still operate just fine. (Same > > as for nodes "bound" to 'B'). But, suppose some node 'x' that was > > bound to 'A' loses touch with 'A' when the partition occurs but > > still has connectivity to 'B'. First of all, any existing sessions > > between 'x' and nodes out on the Internet would break, since the > > NAT translation for 'x' cached in the correspondent nodes out in > > the Internet would *still* be 'A', and 'x' is no longer reachable > > through 'A'. Also, since no subnet-level service discovery support > > exists for the dissemination of such things as Router Advertisements > > in the model you advocate, you would need to do something special > > to get 'x' to realize that it should cease treating 'A' as its > > bound gateway for new sessions and begin treating 'B' as its > > bound gateway. Another problem occurs for MANET servers that are > > advertised out to the Internet by 'A' and 'B'. If 'A' advertises > > a service that is provided by node 'x' within the MANET, but 'x' > > loses contact with 'A' when the partition occurs, then the service > > will be unreachable until the partition is repaired. > > Yes, NAT has problems when there is more than one border router > running NAT. But, again, NAT is not a requirement and can easily be > avoided. By allocating IP addresses out of an aggregated IP subnet prefix or prefixes as you mentioned above; correct? So, you do seem to agree that advertising aggregatable prefixes from within the MANET (i.e. supporting logical IP subnets from within the MANET) is a good thing. > > Classical IP subnet approach: > > ***************************** > > In the case that you are treating the MANET as a coherent logical > > IP subnet, then 'A' and 'B' are true gateways. > > In order to access Internet services, some subset of > > the nodes in the MANET will > > set their default route to 'A' while other nodes will set their > > default route to 'B'. When the partition occurs, the MANET nodes > > will readjust their default roures just fine if necessary by > > detecting a change in the router advertisements they are receiving. > > Correspondent nodes out in the Internet will *still* have valid > > address cachings for the MANET nodes, and service advertisments > > from the MANET will *still* point to the same IPv4 addresses. But > > the problem, of course, is that the subnet itself is partitioned > > and MANET nodes which were formerly reachable through 'A' may no > > longer be reachable through 'A' even though Internet routing > > suggests otherwise. > > > > An easy fix for this is for 'A' and 'B' to exchange MANET topology > > information over their Internet interfaces, since the MANET partition > > presumably did not affect reachability between 'A' and 'B' over the > > Internet. Then, for any node 'x' that is no longer reachable from > > 'A' but still reachable from 'B', 'A' can automatically tunnel > > messages addressed to 'x' over the Internet to 'B'. This obviously > > introduces triangle routing, but it provides a simple fix for > > reachablility. > > Yes, in fact tunneling topology information across the fixed network > between border routers is exactly the approach we took with the Mobile > Mesh Border Gateway Protocol. It is interesting that we have independently reached the same conclusion on this. If we have both reached the same conclusion, (which I came to without a great deal of thought invested) then I'm sure others have or will come to this conclusion as well. Perhaps this argues for a MANET document that specifies how things should be done in the general case... > > > Just because the subnet is partitioned by a lack of connectivity below > > > IP does not mean that the MANET is necessarily partitioned. Yet the > > > attempt to try to hide the topology of the subnet from IP precludes > > > the possibility of healing the partition by leveraging connectivity at > > > the IP layer (unless the thingy below IP provides reachability > > > information, but, this would require IP to use host routes so then > > > there'd be little reason to do subnets since route aggregation will > > > not be realized). Had all forwarding been done at the IP layer, there > > > would not be this accidental partitioning. > > > > I'm not sure I followed the case you are referring to above. Are > > you referring to one of the partition instances I mentioned above, > > or are you considering some other case of partitioning? > > > Actually, I was referring to a more general form of your case #2. That > is, the subnet is partitioned (ie. a connected graph can not be drawn > that contains all the *interfaces* of the subnet) but the network is > not partitioned (ie. a connected graph can be drawn that contains all > the *nodes* of the network). In this case, forwarding packets below IP > is not sufficient to heal the subnet partition. The only way to heal > this case of partitioning is to forward at IP, and this would require > host routes rather than network routes. This means there's little > reason to do subnets since the goal of achieving route aggregation > will not be realized. You may be mis-understanding what I'm saying regarding the level at which I advocate MANET forwarding. I advocate fowarding based on IPv4 host routes; NOT MAC addresses or the like. I also support multiple interfaces and thus support the case of the MANET being spanned by a graph that contains all nodes but not necessarily all interfaces. But, most of the time, forwarding based on IPv4 host routes causes a forwarding hop to occur *within* what would ordinarily appear to be a logical IP subnet. I have yet to find any written text that calls this IPv4 routing in the classical sense. One thing I am taking away from this discussion is the possibility of assigning /32 prefixes to MANET interfaces, instead of a "normal" prefix like a /24 or something. But, I still have yet to find anything written that would call forwarding based on /32 prefixes "IP routing" in its truest sense. > I don't see any advantages to forwarding below IP, only > shortcomings. Are there advantages that you have not mentioned You seemed to agree that supporting the notion of one or more logical IP subnets being properly contained within a MANET is a good thing. But, if you don't tackle the subject of how the all-1's broadcast address and the low-numbered multicast addresses should be propagated, then you won't be able to support service discovery protocols. Examples: - Router advertisements and router solicitations won't be multi-hopped. So, a MANET node that is multiple hops away from a gateway to the Internet will not be able to automatically discover that gateway in the normal fashion; instead, you will be forced to use static routes or you will need to propagate the RA; RS messages by piggybacking them onto the MANET routing protocol messages themselves. - Same comment as above for agent advertisements/agent solicitations. If you want to do MobielIP, then you will have to do something special to support mobile nodes that are more than one hop away from the home/foreign agent - Other service discovery protocols that rely on subnet level broadcast and multicast services. There are many of these; not supporting the notion of a logical IP subnet breaks applications that depend on low-numbered multicasts and all-1's broadcasts spanning the entire subnet. Again, piggy- backing these messages onto the MANET routing protocol is a possible solution if you don't want to support the notion of a logical IP subnet. But, you would need to support every potential service discovery protocol that might come up. I feel now having said these things and having heard what you've said that the truth lies somewhere in between the "classical IPv4 router approach" (in which every node is a /32 subnet unto itself) and the "classical IPv4 subnet approach" (in which every node in the MANET is a member of an aggregatable IPv4 subnet). I believe now that a MANET may contain one or more independent logical IPv4 subnets as well as a number of "outliers" that are essentially foreign nodes that are visiting the MANET from IPv4 prefixes that either have a native point of attachment elsewhere on the Internet or no native point of attachmemt to the Interent at all. But, my original questions that prompted this entire discussion remain: what should we do with the all-1's broadcast address and the low-numbered multicast addresses within the logical IPv4 subnets contained within a MANET? If we don't do anything more than drop them after a single hop, then important service discovery protocols such as those I've discussed above are defeated. This can only lead to folks taking non-standard and proprietary approaches to support service discovery if we can't come up with answers within MANET. Fred Templin templin@erg.sri.com From owner-manet@itd.nrl.navy.mil Wed Apr 4 16:49:22 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01572 for ; Wed, 4 Apr 2001 16:49:22 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA15417 for manet-outgoing; Wed, 4 Apr 2001 14:33:46 -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 OAA15408; Wed, 4 Apr 2001 14:33:42 -0400 (EDT) Message-Id: <5.0.1.4.2.20010404100749.02ab7b98@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Wed, 04 Apr 2001 14:35:32 -0400 To: "Fred L. Templin" , manet@itd.nrl.navy.mil From: Joe Macker Subject: Re: Challenges for the MANET addressing model In-Reply-To: <3ACA19F2.6F760715@erg.sri.com> References: <52vgp585pp.fsf@sean.ebone.net> <3ABFA01D.7C23A7CD@erg.sri.com> <3ABFEF56.93D9723F@erg.sri.com> <3AC492DD.8E990380@mitre.org> <3AC4BB89.7889297D@erg.sri.com> <3AC4D7A9.7DFB461A@mitre.org> <3AC50C17.C3B2BE41@erg.sri.com> <3AC56AB2.AB35342D@mitr <3AC59736.59616C49@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 11:44 AM 4/3/2001 -0700, Fred L. Templin wrote: >Charlie, > >I just sent a reply to Kevin's most recent message that also >addresses some of the points you are making here. But, I'll >comment on a few of the specific items you brought out as well: > >Charlie Perkins wrote: > > > I'd be just as happy if 255.255.255.255 were forwarded to all manet nodes. > > Either that, or maybe we should change AODV so that some sort of > > "all-nodes-multicast" address should be used for propagating RREQ > > messages. > >So, it seems you perceive the need for service discovery protocols >in which messages would be forwarded beyond a single hop in cases >in which the IETF literature claims they MUST NOT be forwarded. >The literature is clear in stating that the all-1's broadcast >("limited broadcast") MUST NOT be forwarded to other networks. >So, if you are assigning /32 prefixes to your interfaces then it >is effectively a violation to even send all-1's broadcasts to >your single hop neighbors! Fred: I see the first point re. multi-hopping, but why would this be a problem for single hop neighbors? I think this is a terminology interpretation issue and doesn't violate the intention. While some wireless link layers have a semi-broadcast nature (a set of connectionless adjacencies that are dynamic), there are still a set of logical links connecting neighbors. I would interpret the above, for single-hop neighbors, as if I initiate the packet on my local link interface I am not FORWARDING it. Yes, someone could probably make all this terminology clearer for wireless, semi-broadcast cases. And there are peculiarities we have to deal with in such cases. BTW, for scalable and heterogeneous operation (just like as in OSPF) it would be desirable to define manet operation for multiple link types (e.g., broadcast, PtoP, semi-broadcast (the oddball)). A manet area may contain multiple link types, with certain nodes having multiple physical interfaces running the routing protocol. A semi-broadcast radio interface being one of those classes of interfaces and the class we are typically talking about with 802.11 DCF. Also how do people feel about using "all-manet-routers" or probably more exactly "all-protocolx-routers" multicast addresses when desireable for handling special behavioral/parsing approaches of protocolx? I started some discussion re. this at the meeting, but it was cut short. -Joe From owner-manet@itd.nrl.navy.mil Thu Apr 5 14:02:31 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09884 for ; Thu, 5 Apr 2001 14:02:30 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA08258 for manet-outgoing; Thu, 5 Apr 2001 11:39:27 -0400 (EDT) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA08253 for ; Thu, 5 Apr 2001 11:39:24 -0400 (EDT) Received: from chip (DHCP044-044.BBN.COM [128.89.44.44]) by po1.bbn.com (8.9.1/8.9.1) with SMTP id LAA15770; Thu, 5 Apr 2001 11:39:24 -0400 (EDT) Message-Id: <3.0.3.32.20010405103921.0074a960@po1.bbn.com> X-Sender: celliott@po1.bbn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 05 Apr 2001 10:39:21 -0400 To: manet@itd.nrl.navy.mil From: Chip Elliott Subject: MANET & IP Layering Cc: Chip Elliott Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk MANET Folks, I have enjoyed reading the recent thread on exactly how a MANET "link" or "subnet" should be treated in the IP architecture. Fred Templin did a masterful job of clearly laying out the issues, and we all owe him a round of thanks. His writings would be an excellent foundation for an Internet Draft on the subject. In my own view, it is by no means obvious yet whether a MANET network is better treated as a sub-network with its own routing and forwarding layers, or whether everything should be brought up to the IP layer. I know that a number of people on this list do have a firm belief in this area, namely, that it should or must be handled at the IP layer. The arguments in favor of this view have been well-stated and I won't repeat them here. Rather, I'd like to bring up what seems to me to be the main argument in the other direction. I would argue that the IP worldview has a remarkably limited set of "links" or "subnets" that it can handle well: * Point to point links * Shared broadcast links (eg classic Ethernets) The assumption that all links fit into one of these two broad categories permeates the Internet architecture. It crops up in the notion of "broadcast" and "multicast" addresses, indeed, but also in the semantics of address resolution, service discovery, router election & redundancy, etc etc. Unfortunately, as Fred has pointed out, the basic RF channel model doesn't fall into either of these categories. Thus there are in essence two ways to deal with this fact: 1. Extend the IP semantics 2. Make the MANET "link" or "subnet" appear to fit into one of the categories My own belief is that the chances of success with Option 1 are pretty low, but that Option 2 has been used repeatedly in the Internet and seems to work pretty well. Let me explain by a few examples. A few years back, ATM wrestled with exactly the same problems. An ATM cloud is neither a point-to-point link nor a shared broadcast network. The IETF put a fair amount of work into treating ATM via Option 1 above, eg, by defining a special form of address resolution for IP / ATM, etc. This was good work, and done by skillful people. However, in my view, in the end all this work can to naught, and today people employ ATM links as classic point-to-point links at the IP layer. In short, a lot of people tried introducing a new kind of IP link or subnet, and in the end the IP architecture proved too resistant. Ethernet provides a telling contrast. Modern Ethernet is by no means a "shared broadcast" channel as it was back in the coax days. Many modern Ethernet "clouds" employ all kinds of switches & link-layer routing protocols, etc. Yet the Ethernet community has been very careful to preserve the old-fashioned Ethernet semantics, so that a modern Ethernet fits very neatly into the Internet architecture (as either a point to point link, or as a shared broadcast medium when seen from the IP layer). The result has been that many generations of Ethernet technology have slid very neatly into the Internet with nary a ripple. Although it can seem odd and redundant to have routing running at two distinct layers (IP and link layer), in fact such schemes have been employed literally for decades and do work OK in practice. I've mentioned Ethernet above, and the fact that Ethernet switches do their own routing and forwarding between different Ethernet segments. Other obvious examples are SONET, frame relay, IP-in-IP tunnels, the new IEEE/IETF Resilient Packet Ring technology, and so forth. In conclusion, let me remind you that I'm not arguing that MANET routing and forwarding (etc) *must* be done below the IP level. Rather, there are fairly strong arguments both for and against that proposition. Personally I think this is an area where we, the MANET community, still have not achieved the necessary level of clarity. Cheers, Chip Elliott Principal Scientist, BBN From owner-manet@itd.nrl.navy.mil Thu Apr 5 22:37:35 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19912 for ; Thu, 5 Apr 2001 22:37:34 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA23088 for manet-outgoing; Thu, 5 Apr 2001 20:32:03 -0400 (EDT) Received: from sfo.erg.sri.com (sfo.erg.sri.com [128.18.100.4] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id UAA23079 for ; Thu, 5 Apr 2001 20:32:00 -0400 (EDT) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id RAA12005; Thu, 5 Apr 2001 17:29:52 -0700 (PDT) Message-ID: <3ACD0E81.F872A3F1@erg.sri.com> Date: Thu, 05 Apr 2001 17:32:01 -0700 From: "Fred L. Templin" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil CC: templin@erg.sri.com Subject: Re: MANET & IP Layering References: <3.0.3.32.20010405103921.0074a960@po1.bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Chip, I enjoyed reading your note, and I agree that we are still not completely converged on all aspects of this subject. I must say that I've had my eyes opened in a number of areas from the discussions, but I think that there is still much left to be explored in more detail. Fred Templin templin@erg.sri.com From owner-manet@itd.nrl.navy.mil Fri Apr 6 14:23:13 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16461 for ; Fri, 6 Apr 2001 14:23:12 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA06108 for manet-outgoing; Fri, 6 Apr 2001 11:21:22 -0400 (EDT) Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA06100 for ; Fri, 6 Apr 2001 11:21:19 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id LAA10248; Fri, 6 Apr 2001 11:21:13 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id LAA15857; Fri, 6 Apr 2001 11:21:12 -0400 (EDT) Received: from kgrace.mitre.org (129.83.41.112) by mailhub1.mitre.org with SMTP id 6131174; Fri, 06 Apr 2001 11:20:35 -0400 Message-ID: <3ACDDF91.70B12B9D@mitre.org> Date: Fri, 06 Apr 2001 11:24:01 -0400 From: Kevin Grace Organization: The MITRE Corporation X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chip Elliott CC: manet@itd.nrl.navy.mil Subject: Re: MANET & IP Layering References: <3.0.3.32.20010405103921.0074a960@po1.bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi Chip, Thanks for taking the time to express your opinions. I do have differing views on some points; comments below... Chip Elliott wrote: > Unfortunately, as Fred has pointed out, the basic RF channel > model doesn't fall into either of these categories. Thus there > are in essence two ways to deal with this fact: > > 1. Extend the IP semantics > 2. Make the MANET "link" or "subnet" appear to fit > into one of the categories > > My own belief is that the chances of success with Option 1 > are pretty low, but that Option 2 has been used repeatedly in > the Internet and seems to work pretty well. I'd argue that there is a third option: Work with existing IP semantics and build the "missing pieces" on top of IP. Some existing semantics are still applicable in a MANET environment, some are not and those should therefore be avoided. For example, sending to the limited broadcast address 255.255.255.255 has traditionally meant that all directly connected interfaces which hear the transmission should handle the receive packet but not forward it. This is a very useful feature that is still very appropriate to RF channels. In fact, some of the MANET routing protocols rely on this feature. On the other hand, sending to a subnet directed broadcast address (eg. 192.168.1.255) has traditionally meant that a transmission will be received by all interfaces having addresses belonging to the subnet. Moreover, it has been assumed that such a transmission could efficiently be delivered by unicasting it from the source (if the source did not reside on the destination subnet) until it reached a node with an interface residing on the destination subnet which would then forward it using a single link layer broadcast. Unfortunately, we know that in general, this final link layer broadcast is insufficient to reach all the subnet interfaces...and this is the dilemma that we have all been discussing. I suggest features like this one which do not naturally fit for RF channels be avoided. As Fred has pointed out, some existing protocols/applications rely upon subnet broadcasts, though I question that the number of such protocols is so large that the only reasonable alternative is to do link layer forwarding. For example, you and Fred have both indicated that router advertisements rely on subnet broadcasts yet this is only true of "wired" routing protocols...certainly these protocols are not appropriate for MANETs! Address resolution was also mentioned as a problem; yet ARP and RARP work fine in MANETs too. Certainly there will be some apps/protocols that rely on subnet broadcast that we'll want to operate in a MANET environment (though the vast majority do not; consider ftp, telnet, http, ping, etc.), but its not clear that there are more than a handful. And if that's the case, then it appears that modifying them for MANET operation may be a tenable solution. Also, it does not appear that subnet broadcast are uniquely qualified for "service discovery" like operations. "Service discovery" like things can easily be implemented with a simple advertisement protocol running on a multicast group. This building on top of IP seems a much more viable option than trying to extend IP's semantics. > In conclusion, let me remind you that I'm not arguing that > MANET routing and forwarding (etc) *must* be done below the > IP level. Rather, there are fairly strong arguments both for > and against that proposition. Personally I think this is an > area where we, the MANET community, still have not achieved > the necessary level of clarity. > Hmmm...let me try to summarize the arguments as I see them: IP forwarding: General solution for *all* media Able to utilize all links, regardless of media type, to overcome partitions Readily available Open Source implementations Promotes heterogeneity Precludes use of subnets...requires mods to a few apps/protocols Below IP forwarding: Specific solution for a specific media Unable to utilize all links, only those of the same media type, to overcome partitions No readily available Open Source implementations Promotes homogeneity Enables subnets to be utilized Does not appear to me to be a close call...of course everyone is entitled to their own opinion :-) Kevin From owner-manet@itd.nrl.navy.mil Fri Apr 6 21:32:38 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24204 for ; Fri, 6 Apr 2001 21:32:37 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA18377 for manet-outgoing; Fri, 6 Apr 2001 19:17:13 -0400 (EDT) Received: from sfo.erg.sri.com (sfo.erg.sri.com [128.18.100.4] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id TAA18370 for ; Fri, 6 Apr 2001 19:17:10 -0400 (EDT) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id QAA04877; Fri, 6 Apr 2001 16:14:59 -0700 (PDT) Message-ID: <3ACE4E62.C7F0A044@erg.sri.com> Date: Fri, 06 Apr 2001 16:16:50 -0700 From: "Fred L. Templin" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil CC: templin@erg.sri.com Subject: Re: MANET & IP Layering References: <3.0.3.32.20010405103921.0074a960@po1.bbn.com> <3ACDDF91.70B12B9D@mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Kevin, Just some follow-up comments on you meesage: Kevin Grace wrote: > As Fred has pointed out, some existing protocols/applications rely > upon subnet broadcasts, though I question that the number of such > protocols is so large that the only reasonable alternative is to do > link layer forwarding. For example, you and Fred have both indicated > that router advertisements rely on subnet broadcasts yet this is only > true of "wired" routing protocols...certainly these protocols are not > appropriate for MANETs! Address resolution was also mentioned as a > problem; yet ARP and RARP work fine in MANETs too. Actually, I have not spoken of subnet-directed broadcasts in any of my messages, but I do agree they present an interesting set of challenges for MANETs. What I have spoken of are service discovery protocols that utilize the all-1's broadcast address and/or the low-numbered IP multicast addresses in the range from 224.0.0.0 thru 224.0.0.255. Router advertisements rely on this latter form, as told from the following text in RFC 1256: => AdvertisementAddress => The IP destination address to be used for multicast => Router Advertisements sent from the interface. The => only permissible values are the all-systems multicast => address, 224.0.0.1, or the limited-broadcast address, => 255.255.255.255. (The all-systems address is preferred => wherever possible, i.e., on any link where all => listening hosts support IP multicast.) => => Default: 224.0.0.1 if the router supports IP multicast => on the interface, else 255.255.255.255 The problem with the low-numbered multicasts is that all of the literature claims they are only supposed to go a single hop *regardless* of the value in the IP_TTL header field, which means that a MANET node that is more than one hop away from a sender won't hear the sender's RA's - unless we introduce special new legislation for MANETs. What would ideally work for low-numbered IPv4 multicasts in MANETs would be a combination of setting the IP_TTL to something other than 1 along with MANET-specific administrative scoping rules (e.g. "Don't forward beyond the edge of the MANET"). But, this would require modifications to a significant number of Internet standards documents as well as all of the host/router software out there that implement them. > Also, it does not appear that subnet broadcast are uniquely qualified > for "service discovery" like operations. "Service discovery" like > things can easily be implemented with a simple advertisement protocol > running on a multicast group. This building on top of IP seems a much > more viable option than trying to extend IP's semantics. Yes, this is basically what I have been saying in my messages. But still, the problem is the single-hop nature of the all-1's broadcast address and the low numbered multicast group addresses used by service discovery protocols. You may not think there are *lots* of service discovery protocols that require our attention in MANETs, but there are certainly some *very important* ones, such as agent advertisements in MobileIPv4. As told in RFC 2002, MobileIPv4 agent advertisements basically ride on top of RFC 1256 router advertisements, meaning they will only travel 1 hop in a MANET. But, I think it would be of paramount importance to allow a node from a foreign MANET that enters the local MANET to detect the presence of a MobileIP foreign agent with whom to associate; whether/not the foreign agent is multiple MANET hops away. You went on to list tradeoffs between the "strictly structured" vs. "totally unstructured" viewpoints for the IPv4 addresses used by nodes in a MANET, and perhaps this was with reference to something Chip said in his message. As I've been saying in my messages, however, I think the truth lies somewhere in the middle between the two extremes. To be sure, a MANET *must* present itself as a coherent aggregatable IPv4 prefix (or collection of IPv4 prefixes) if it is to be connected as a stub network or transit network to the Internet. And, I think we all agreed that NAT is not a very attractive alternative to accomplish this. To that end, some sort of "loosely structured" coordination should probably be done within the MANET. Whether this means some sort of router affiliation based method for doleing out IPv4 addresses from one or more common IPv4 prefixes or whatever is probably open to interpretation. Fred templin@erg.sri.com From owner-manet@itd.nrl.navy.mil Sat Apr 7 21:55:41 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20068 for ; Sat, 7 Apr 2001 21:55:40 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA27255 for manet-outgoing; Sat, 7 Apr 2001 19:36:48 -0400 (EDT) Received: from smtpproxy2.mitre.org (smtpproxy2.mitre.org [128.29.154.90]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id TAA27250 for ; Sat, 7 Apr 2001 19:36:45 -0400 (EDT) Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4]) by smtpproxy2.mitre.org (8.9.3/8.9.3) with ESMTP id TAA08868; Sat, 7 Apr 2001 19:36:15 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv2.mitre.org (8.9.3/8.9.3) with ESMTP id TAA09053; Sat, 7 Apr 2001 19:36:14 -0400 (EDT) Received: from mbppp167.mitre.org (129.83.69.167) by mailhub2.mitre.org with SMTP id 6287832; Sat, 07 Apr 2001 19:36:11 -0400 Message-ID: <3ACFA3BC.5A40DD0B@mitre.org> Date: Sat, 07 Apr 2001 19:33:16 -0400 From: Kevin Grace X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1} (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fred L. Templin" CC: manet@itd.nrl.navy.mil Subject: Re: MANET & IP Layering References: <3.0.3.32.20010405103921.0074a960@po1.bbn.com> <3ACDDF91.70B12B9D@mitre.org> <3ACE4E62.C7F0A044@erg.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit "Fred L. Templin" wrote: > Kevin Grace wrote: > > As Fred has pointed out, some existing protocols/applications rely > > upon subnet broadcasts... > > Actually, I have not spoken of subnet-directed broadcasts in any > of my messages, but I do agree they present an interesting set of > challenges for MANETs. Apologies for the poor recollection of the conversation... > The problem with the low-numbered multicasts is that all of > the literature claims they are only supposed to go a single hop > *regardless* of the value in the IP_TTL header field, which means > that a MANET node that is more than one hop away from a sender > won't hear the sender's RA's - unless we introduce special new > legislation for MANETs. What would ideally work for low-numbered > IPv4 multicasts in MANETs would be a combination of setting the > IP_TTL to something other than 1 along with MANET-specific > administrative scoping rules (e.g. "Don't forward beyond the > edge of the MANET"). But, this would require modifications to a > significant number of Internet standards documents as well as > all of the host/router software out there that implement them. There's a broadcast storm problem waiting to bite anyone who blindly resends a broadcast/multicast, hence the restriction on forwarding. It's possible to prevent the storm by maintaining a cache at every node which remembers recently transmitted/forwarded broadcast/multicast packets; kind of ugly but certainly doable. Instead of forwarding broadcast/low-numbered multicasts, it's possible to utilize a higher numbered multicast group which will be forwarded using traditional rules. This would preserve traditional limited broadcast/low-numbered multicast rules and would likely be more efficient than the alternative of flooding. It's clear there is more than one way to approach this problem; whether we try to preserve apps/protocols and modify IP to allow broadcast/low-numbered multicasts to be forwarded or whether we instead try to modify the apps/protocols and preserve IP, is a good question. I think it might be useful to identify the set of apps/protocols that we want in a MANET environment which are challenged. That might help bound the work required by the latter approach. Kevin From owner-manet@itd.nrl.navy.mil Sun Apr 8 12:37:33 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10790 for ; Sun, 8 Apr 2001 12:37:32 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA01213 for manet-outgoing; Sun, 8 Apr 2001 10:30:03 -0400 (EDT) Received: from eesun1.tamu.edu (eesun1.tamu.edu [165.91.243.35]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA01206 for ; Sun, 8 Apr 2001 10:30:00 -0400 (EDT) Received: from localhost (ksbakshi@localhost) by eesun1.tamu.edu (8.11.2/8.11.2) with ESMTP id f38ETgh26043 for ; Sun, 8 Apr 2001 09:29:42 -0500 (CDT) X-Authentication-Warning: eesun1.tamu.edu: ksbakshi owned process doing -bs Date: Sun, 8 Apr 2001 09:29:42 -0500 (CDT) From: Kinshuk Bakshi X-Sender: ksbakshi@eesun1.tamu.edu To: Manet Mailing List Subject: ns-create topology with unidirectional links Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hello all, Here is my (stupid) question: How can I emulate a unidirectional link between a chosen pair of mobile nodes, using the NS framework? I am trying to provide support for unidirectional links in the DSR routing protocol, and also accounting for them at the lower (MAC) layers. Please excuse this email if it is out of context. Thanks Kinshuk Bakshi -------------- M.E. Computer Engineering, Aggie Class of 2001 ---------------------------------------------- 401 Stasney #213 Home:(979)260-3287 College STation, TX 77840 Email:ksbakshi@ee.tamu.edu --------------------- ---------------------------- http://www.cs.tamu.edu/people/ksb7690/ From owner-manet@itd.nrl.navy.mil Sun Apr 8 16:23:38 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12172 for ; Sun, 8 Apr 2001 16:23:38 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA02694 for manet-outgoing; Sun, 8 Apr 2001 14:25:32 -0400 (EDT) Received: from hstnl.eng.fiu.edu (hstnl.eng.fiu.edu [131.94.163.238]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA02689 for ; Sun, 8 Apr 2001 14:25:29 -0400 (EDT) From: jd@hstnl.eng.fiu.edu Received: from localhost (jd@localhost) by hstnl.eng.fiu.edu (8.11.0/8.11.0) with ESMTP id f38IHme19364 for ; Sun, 8 Apr 2001 14:17:48 -0400 Date: Sun, 8 Apr 2001 14:17:48 -0400 (EDT) To: manet@itd.nrl.navy.mil Subject: trace file evluation of ns simulation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk hi all, i needed some help to evluate the trace files produced by some wireless simulations whiich i have done, could anyone tell me how i could calculate the fraction of packets delivered to the destination, and the routing load. thanks -jd. ------------------------------------------------------------- Jaydeep Punde Department of ECE, FIU "I'm a nobody, & nobody is perfect, therefore i'm perfect :-) ------------------------------------------------------------- From owner-manet@itd.nrl.navy.mil Sun Apr 8 22:19:03 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14552 for ; Sun, 8 Apr 2001 22:19:02 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA04597 for manet-outgoing; Sun, 8 Apr 2001 19:37:07 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id TAA04592 for ; Sun, 8 Apr 2001 19:37: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.0) with ESMTP id QAA24516; Sun, 8 Apr 2001 16:35:51 -0700 (PDT) Message-Id: <200104082335.QAA24516@pit.erg.sri.com> To: manet@itd.nrl.navy.mil cc: ogier@erg.sri.com Subject: Re: MANET & IP Layering Date: Sun, 08 Apr 2001 16:35:51 -0700 From: Richard Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk I would like to add some thoughts to this interesting discussion on MANET & IP layering. Some of what I say may repeat or agree or disagree with some things that Fred, Chip, and Kevin have said, but I hope this message will offer some new points. Comments are welcome. It seems to me that an IP-based MANET network can be used in either of the following ways: 1. At the internetwork layer, as an automonous system (AS) 2. At the subnetwork layer, as a subnet in an AS As a subnet, similar to IP over ATM, or more generally IP over NBMA [RFC 2491], we have IP over MANET (where a MANET is IP-based). In this case, the MANET can emulate the service provided to the internetwork layer by a conventional broadcast subnet. This emulation would utilize an efficient MANET broadcast/multicast mechanism. For example, a packet sent by an IP router over an ATM (or MANET) subnet *appears* to travel one hop, even though it could actually be traveling several hops. For packets generated *within* a MANET, the existing IP rules can be followed, e.g., do not forward packets with the limited broadcast (255.255.255.255) or all-systems multicast (244.0.0.1) address. Packets generated by the internetwork layer with these addresses should *appear* to be sent only one hop from the internetwork layer's perspective, even though they are actually sent multiple hops from the MANET's perspective. One way to accomplish this is to encapsulate the internetwork-layer IP packet by attaching a MANET-layer IP header. For example, this attached header could translate the limited broadcast or all-systems multicast address to the subnet-directed broadcast address for the MANET, so that it is broadcast (using an efficient MANET broadcast mechanism as Kevin suggested) to all nodes in the MANET regardless of the number of hops. The TTL of the the MANET-layer IP header would be decremented at each hop, while the TTL of the original IP header stays the same. A subnet-directed broadcast originating from outside the MANET would be broadcast to all nodes in the MANET, perhaps using the same address. In this case, it may not be necessary to attach a MANET-layer IP header (but it may be necessary to modify the TTL). As another example, an OSPF Hello packet generated by an internetwork router (normally sent a single hop to the multicast address AllSPFRouters) can be multicast within the MANET to all gateway routers belonging to that group (regardless of the number of hops required). (Of course, we would like to avoid the redundancy of sending both OSPF Hello packets and MANET Hello packets within the MANET, but that is another topic.) Regarding addressing, I agree that all nodes in a MANET subnet should have the same IP network/subnet prefix. In fact, this is a requirement of a logical IP subnet (LIS), which is commonly used to model an NBMA network (e.g., for IP over ATM). It is also possible for two MANETs to overlap, in which case the nodes common to both MANET's need to have both prefixes. If a MANET is partitioned, each connected component should be reconfigured so that the different components use different (perhaps longer) network prefixes. These prefixes can perhaps be determined by the gateway/border router that is selected as home/foreign agent. This problem was addressed (for a different context) by SRI's Reconstitution Protocol (RP) developed in the late 80's. Regarding router/agent advertisements, I assume these would be sent by internetwork gateway routers to announce their presence to MANET routers/hosts. I agree that these advertisements contain important information, but instead of broadcasting these messages to all MANET nodes, an alternative (better or worse?) is to convey this information in MANET control messages (e.g., similar to the gateway announcement messages proposed in the OLSR extensions draft). Richard From owner-manet@itd.nrl.navy.mil Mon Apr 9 15:26:35 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14705 for ; Mon, 9 Apr 2001 15:26:35 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA17302 for manet-outgoing; Mon, 9 Apr 2001 12:59:38 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA17297 for ; Mon, 9 Apr 2001 12:59:34 -0400 (EDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.0) with ESMTP id JAA24994; Mon, 9 Apr 2001 09:58:25 -0700 (PDT) Message-Id: <200104091658.JAA24994@pit.erg.sri.com> To: manet@itd.nrl.navy.mil cc: ogier@erg.sri.com Subject: Re: MANET & IP Layering Date: Mon, 09 Apr 2001 09:58:25 -0700 From: Richard Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk I wanted to add one more thought to my previous message. (I have not yet seen any response to my previous message, but it usually takes a few hours for me to receive email sent to the manet list.) A third way to use a MANET is to emulate an OSPF area. Thus, a MANET routing protocol would be used within the area instead of OSPF, but would provide the same information to Area 0 as would OSPF. This seems doable, but of course this only works for OSPF (but maybe it can be generalized). A virtual path can be set up across the MANET/OSPF area if necessary. An advantage of this approach is that it is not necessary to encapsulate an internetwork-level IP packet into a MANET-level IP packet (assuming both use IPv4). I also want to point out that I am just giving general ideas. Many details need to be worked out, and there could easily be errors in what I have said. Richard ------- Forwarded Message Message-Id: <200104082335.QAA24516@pit.erg.sri.com> To: manet@itd.nrl.navy.mil cc: ogier@erg.sri.com Subject: Re: MANET & IP Layering Date: Sun, 08 Apr 2001 16:35:51 -0700 From: Richard Content-Type: text Content-Length: 3903 I would like to add some thoughts to this interesting discussion on MANET & IP layering. Some of what I say may repeat or agree or disagree with some things that Fred, Chip, and Kevin have said, but I hope this message will offer some new points. Comments are welcome. It seems to me that an IP-based MANET network can be used in either of the following ways: 1. At the internetwork layer, as an automonous system (AS) 2. At the subnetwork layer, as a subnet in an AS As a subnet, similar to IP over ATM, or more generally IP over NBMA [RFC 2491], we have IP over MANET (where a MANET is IP-based). In this case, the MANET can emulate the service provided to the internetwork layer by a conventional broadcast subnet. This emulation would utilize an efficient MANET broadcast/multicast mechanism. For example, a packet sent by an IP router over an ATM (or MANET) subnet *appears* to travel one hop, even though it could actually be traveling several hops. For packets generated *within* a MANET, the existing IP rules can be followed, e.g., do not forward packets with the limited broadcast (255.255.255.255) or all-systems multicast (244.0.0.1) address. Packets generated by the internetwork layer with these addresses should *appear* to be sent only one hop from the internetwork layer's perspective, even though they are actually sent multiple hops from the MANET's perspective. One way to accomplish this is to encapsulate the internetwork-layer IP packet by attaching a MANET-layer IP header. For example, this attached header could translate the limited broadcast or all-systems multicast address to the subnet-directed broadcast address for the MANET, so that it is broadcast (using an efficient MANET broadcast mechanism as Kevin suggested) to all nodes in the MANET regardless of the number of hops. The TTL of the the MANET-layer IP header would be decremented at each hop, while the TTL of the original IP header stays the same. A subnet-directed broadcast originating from outside the MANET would be broadcast to all nodes in the MANET, perhaps using the same address. In this case, it may not be necessary to attach a MANET-layer IP header (but it may be necessary to modify the TTL). As another example, an OSPF Hello packet generated by an internetwork router (normally sent a single hop to the multicast address AllSPFRouters) can be multicast within the MANET to all gateway routers belonging to that group (regardless of the number of hops required). (Of course, we would like to avoid the redundancy of sending both OSPF Hello packets and MANET Hello packets within the MANET, but that is another topic.) Regarding addressing, I agree that all nodes in a MANET subnet should have the same IP network/subnet prefix. In fact, this is a requirement of a logical IP subnet (LIS), which is commonly used to model an NBMA network (e.g., for IP over ATM). It is also possible for two MANETs to overlap, in which case the nodes common to both MANET's need to have both prefixes. If a MANET is partitioned, each connected component should be reconfigured so that the different components use different (perhaps longer) network prefixes. These prefixes can perhaps be determined by the gateway/border router that is selected as home/foreign agent. This problem was addressed (for a different context) by SRI's Reconstitution Protocol (RP) developed in the late 80's. Regarding router/agent advertisements, I assume these would be sent by internetwork gateway routers to announce their presence to MANET routers/hosts. I agree that these advertisements contain important information, but instead of broadcasting these messages to all MANET nodes, an alternative (better or worse?) is to convey this information in MANET control messages (e.g., similar to the gateway announcement messages proposed in the OLSR extensions draft). Richard ------- End of Forwarded Message From owner-manet@itd.nrl.navy.mil Mon Apr 9 15:47:36 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15149 for ; Mon, 9 Apr 2001 15:47:35 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA17485 for manet-outgoing; Mon, 9 Apr 2001 13:06:23 -0400 (EDT) Received: from sfo.erg.sri.com (sfo.erg.sri.com [128.18.100.4]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA17480 for ; Mon, 9 Apr 2001 13:06:20 -0400 (EDT) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id KAA15534; Mon, 9 Apr 2001 10:03:50 -0700 (PDT) Message-ID: <3AD1EC0D.ABE2B2D6@erg.sri.com> Date: Mon, 09 Apr 2001 10:06:21 -0700 From: "Fred L. Templin" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil CC: templin@erg.sri.com Subject: Re: MANET & IP Layering References: <3.0.3.32.20010405103921.0074a960@po1.bbn.com> <3ACDDF91.70B12B9D@mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Kevin, Another point about your earlier message: Kevin Grace wrote: > Address resolution was also mentioned as a > problem; yet ARP and RARP work fine in MANETs too. I think there needs to be an asterisk after the words "work fine". On the surface, ARP is just a means to bind an IEEE 802.11 MAC address resolution to an IPv4 address. And, I agree that this function does work fine in a MANET. But at the core, ARP is an on-demand neighbor discovery protocol and in that regard it embodies some fundamental assumptions that don't mesh well with MANETs. When node A sends an ARPOP_REQUEST asking to resolve the IPv4 address B into a MAC address, B will assume the bi-directional link A<->B is up if B receives A's message and as such B will create an ARP table entry for A. This assumption is fine on a connected multiple-access broadcast network, but in a MANET there will be many instances in which B is hearing A's messages but A is *not* hearing B's messages. In these cases, the link is really asymmetric from A->B, but B won't detect this at the ARP level. This problem is complicated by the fact that ARP cache entries are aged based on criteria that have nothing to do with the topology of the MANET. Namely, the ARP entry B created for A will stay around for a timeout period based on the most recent message B has sent to A. So, especially in a MANET with a high degree of mobility, cached ARP entries for asymmetric links can interfere with communications if there is no synergy between the MANET routing protocol and the ARP cache. Fred templin@erg.sri.com From owner-manet@itd.nrl.navy.mil Tue Apr 10 02:42:11 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08886 for ; Tue, 10 Apr 2001 02:42:10 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id AAA00349 for manet-outgoing; Tue, 10 Apr 2001 00:04:19 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id AAA00344 for ; Tue, 10 Apr 2001 00:04:16 -0400 (EDT) Received: (from templin@localhost) by pit.erg.sri.com (8.9.3+Sun/8.9.0) id VAA25785; Mon, 9 Apr 2001 21:03:01 -0700 (PDT) Date: Mon, 9 Apr 2001 21:03:01 -0700 (PDT) From: "Fred L. Templin" Message-Id: <200104100403.VAA25785@pit.erg.sri.com> To: manet@itd.nrl.navy.mil Cc: rogier@best.com, sastry@erg.sri.com, templin@erg.sri.com Subject: Re: MANET & IP layering Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hello, Richard Ogier and I spent a good bit of time discussing this and, along with the helpful input received from others on the mailing list, we think we have converged on a common viewpoint for IPv4 in MANETs. Additionally, Richard has come up with what we both feel may be a good general solution for handling limited broadcasts and the low-numbered multicasts (addresses within the range of 224.0.0.0 through 224.0.0.255) in the context of service discovery protocol operation in MANETs. Our viewpoint on the operation of IPv4 in MANETs is as follows: 1. Within the MANET routing protocol, the IPv4 address assigned to each MANET node is essentially treated as an independent node ID. That is, there is no requirement for a common prefix for IPv4 forwarding between nodes within the MANET. 2. From the outside, the MANET must present itself to the rest of the Internet as a set of one or more aggregatable IPv4 prefixes. 3. In order to accomplish #2, some sort of subnet convergence should occur - perhaps through some sort of gateway affiliation protocol - such that one or more logical IPv4 subnets (LIS) appear to reside within the MANET when viewed from the outside. In terms of the remaining issue I have been citing (i.e. how to get the low-numbered multicasts to span multiple hops within the MANET), Richard's idea entails IP-in-IP encapsulation for IPv4 packets sent to the limited broadcast address and low-numbered multicast addresses, with the outer IPv4 header containing a *routable* IPv4 multicast destination address that is reserved with IANA for MANET operation. For example, if an IPv4 multicast address such as: 224.0.1.173 were reserved with IANA as an "All_MANET_Nodes" multicast address, this address could be used as the IPv4 destination address in the encapsulation header. Then, using an efficient multicast routing protocol designed for MANETs, such encapsulated messages could be forwared through the MANET based on TTL-based hop counts, administrative scoping rules, or a combination of both. While this idea appears to be a good fit for the service discovery protocol probelm we have been discussing, we also think it might be a good solution whenever an internet-level router performs multicast over the MANET subnet, i.e., the MANET subnet emulates a conventional broadcast subnet by providing multicast. A significant advantage of this approach over either changing the rules for IPv4 forwarding for the low-numbered multicasts or changing service discovery applications to use routable IPv4 multicast addresses is that this *may* be possible by simply setting system configuration parameters for a "tunnel interface" on existing hosts and routers. In other words, this approach *may* be possible with little/no modification to existing applications and/or host and router systems software. Richard's idea was motivated in part by the literature that describes IP encapsulation over ATM, and so there is relevant precendence for this approach within the Internetworking framework. Comments? Fred and Richard From owner-manet@itd.nrl.navy.mil Tue Apr 10 04:02:11 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09534 for ; Tue, 10 Apr 2001 04:02:10 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id BAA01305 for manet-outgoing; Tue, 10 Apr 2001 01:31:10 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id BAA01297 for ; Tue, 10 Apr 2001 01:31:05 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by boreas.isi.edu (8.11.2/8.11.2) with SMTP id f3A5V0521180; Mon, 9 Apr 2001 22:31:00 -0700 (PDT) Date: Mon, 9 Apr 2001 22:31:00 -0700 (PDT) From: Ya Xu To: jd@hstnl.eng.fiu.edu cc: manet@itd.nrl.navy.mil Subject: Re: trace file evluation of ns simulation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Monitor how many data are sent from the src, and how many are received in the dst On Sun, 8 Apr 2001 jd@hstnl.eng.fiu.edu wrote: > > hi all, > > i needed some help to evluate the trace files produced by some wireless > simulations whiich i have done, could anyone tell me how i could calculate > the fraction of packets delivered to the destination, and the routing > load. > > thanks > -jd. > > > > ------------------------------------------------------------- > > Jaydeep Punde > Department of ECE, FIU > > > "I'm a nobody, & nobody is perfect, therefore i'm perfect :-) > > > ------------------------------------------------------------- > From owner-manet@itd.nrl.navy.mil Tue Apr 10 04:09:11 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09544 for ; Tue, 10 Apr 2001 04:02:14 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id BAA01261 for manet-outgoing; Tue, 10 Apr 2001 01:28:42 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id BAA01256 for ; Tue, 10 Apr 2001 01:28:40 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by boreas.isi.edu (8.11.2/8.11.2) with SMTP id f3A5Se520908; Mon, 9 Apr 2001 22:28:40 -0700 (PDT) Date: Mon, 9 Apr 2001 22:28:40 -0700 (PDT) From: Ya Xu To: Kinshuk Bakshi cc: Manet Mailing List Subject: Re: ns-create topology with unidirectional links In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk what do you mean by "link" in wireless network On Sun, 8 Apr 2001, Kinshuk Bakshi wrote: > Hello all, > > Here is my (stupid) question: > How can I emulate a unidirectional link between a chosen > pair of mobile nodes, using the NS framework? I am trying to provide > support for unidirectional links in the DSR routing protocol, and also > accounting for them at the lower (MAC) layers. > > Please excuse this email if it is out of context. > > Thanks > > Kinshuk Bakshi > -------------- > M.E. Computer Engineering, Aggie Class of 2001 > ---------------------------------------------- > 401 Stasney #213 Home:(979)260-3287 > College STation, TX 77840 Email:ksbakshi@ee.tamu.edu > --------------------- ---------------------------- > http://www.cs.tamu.edu/people/ksb7690/ > From owner-manet@itd.nrl.navy.mil Tue Apr 10 13:05:26 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21174 for ; Tue, 10 Apr 2001 13:05:25 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA09643 for manet-outgoing; Tue, 10 Apr 2001 10:15:32 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA09632 for ; Tue, 10 Apr 2001 10:15:25 -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 HAA03186; Tue, 10 Apr 2001 07:14:09 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3AEE6D13415; Tue, 10 Apr 2001 07:14:06 -0700 X-mProtect: Tue, 10 Apr 2001 07:14:06 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdSLvZdn; Tue, 10 Apr 2001 07:13:56 PDT Message-ID: <3AD31525.71E5B0D3@iprg.nokia.com> Date: Tue, 10 Apr 2001 07:13:57 -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: "Fred L. Templin" CC: manet@itd.nrl.navy.mil, rogier@best.com, sastry@erg.sri.com Subject: Re: MANET & IP layering References: <200104100403.VAA25785@pit.erg.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hello Fred, > 1. Within the MANET routing protocol, the IPv4 address assigned > to each MANET node is essentially treated as an independent > node ID. That is, there is no requirement for a common prefix > for IPv4 forwarding between nodes within the MANET. Agreed -- but, we should _allow_ for regions to have a common prefix. > 2. From the outside, the MANET must present itself to the rest > of the Internet as a set of one or more aggregatable IPv4 > prefixes. This has the disadvantage of excluding any other wireless node that happens to arrive with an IP address not represented by the aggregated prefixes. However, if a manet node can use Mobile IP with a home agent in the infrastructure, the need for advertising its prefix evaporates. > 3. In order to accomplish #2, some sort of subnet convergence > should occur - perhaps through some sort of gateway affiliation > protocol - such that one or more logical IPv4 subnets (LIS) > appear to reside within the MANET when viewed from the outside. I'm willing to agree that manet gateways should be ABLE to advertise subnets (as long as it's sensible to do so), but I don't believe we should make the restriction that all manet nodes fit within the advertised subnet aggregation. > In terms of the remaining issue I have been citing (i.e. how > to get the low-numbered multicasts to span multiple hops within > the MANET), Richard's idea entails IP-in-IP encapsulation for IPv4 > packets sent to the limited broadcast address and low-numbered > multicast addresses, with the outer IPv4 header containing a > *routable* IPv4 multicast destination address that is reserved > with IANA for MANET operation. Maybe it would be better to have an "all-nodes" multicast address, and use two other methods to restrict distribution: 1) setting TTL < network diameter, and 2) allowing gateway router policy to avoid forwarding along certain (say, wired) interfaces. I'd _really_ hate to go down the road of partitioning the Internet address space into manet/non-manet prefixes or multicast addresses. > While > this idea appears to be a good fit for the service discovery > protocol probelm we have been discussing, I'm interested in service discovery within manet, but I don't recollect the discussion on the mailing list. Did I miss it? Regards, Charlie P. From owner-manet@itd.nrl.navy.mil Tue Apr 10 13:05:40 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21195 for ; Tue, 10 Apr 2001 13:05:38 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA09647 for manet-outgoing; Tue, 10 Apr 2001 10:15:35 -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 KAA09629; Tue, 10 Apr 2001 10:15:23 -0400 (EDT) Message-Id: <5.0.1.4.2.20010410095534.01ef6838@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 10 Apr 2001 10:16:48 -0400 To: "Fred L. Templin" , manet@itd.nrl.navy.mil From: Joe Macker Subject: Re: MANET & IP layering Cc: rogier@best.com, sastry@erg.sri.com, templin@erg.sri.com In-Reply-To: <200104100403.VAA25785@pit.erg.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 09:03 PM 4/9/2001 -0700, Fred L. Templin wrote: >Hello, > >Richard Ogier and I spent a good bit of time discussing this and, >along with the helpful input received from others on the mailing >list, we think we have converged on a common viewpoint for IPv4 in >MANETs. Additionally, Richard has come up with what we both feel >may be a good general solution for handling limited broadcasts and >the low-numbered multicasts (addresses within the range of 224.0.0.0 >through 224.0.0.255) in the context of service discovery protocol >operation in MANETs. > >Our viewpoint on the operation of IPv4 in MANETs is as follows: > > 1. Within the MANET routing protocol, the IPv4 address assigned > to each MANET node is essentially treated as an independent > node ID. That is, there is no requirement for a common prefix > for IPv4 forwarding between nodes within the MANET. Right. > 2. From the outside, the MANET must present itself to the rest > of the Internet as a set of one or more aggregatable IPv4 > prefixes. Sounds like good practice... Host routes should be still o.k. for some applications (e.g., edge system mobile agents. e.g., mobile IP), but if you can present the manet cloud as aggregatable to the rest of the world great!. >In terms of the remaining issue I have been citing (i.e. how >to get the low-numbered multicasts to span multiple hops within >the MANET), Richard's idea entails IP-in-IP encapsulation for IPv4 >packets sent to the limited broadcast address and low-numbered >multicast addresses, with the outer IPv4 header containing a >*routable* IPv4 multicast destination address that is reserved >with IANA for MANET operation. Don't forget ... control information (e.g., OSPF LSUs) can be still flooded with low-numbered multicast and/or one hop unicast addresses since the flooding,etc is handled logically at the protocol level (not at the IP level) and replicated as needed... this also allows for better aggregation of control messages and specialized forwarding rules as needed, defined per protocol).... OSPF and other algorithms do a number of interesting things while using only single hop association addresses. You may still want the above, just pointing out there is another way to think about it if the concern is forwarding routing control messages. User data forwarding is another story, but I think it is important not to confuse the two areas of application. >For example, if an IPv4 multicast address such as: > > 224.0.1.173 > >were reserved with IANA as an "All_MANET_Nodes" multicast address, >this address could be used as the IPv4 destination address in the >encapsulation header. Then, using an efficient multicast routing >protocol designed for MANETs, such encapsulated messages could be >forwared through the MANET based on TTL-based hop counts, >administrative scoping rules, or a combination of both. While >this idea appears to be a good fit for the service discovery >protocol probelm we have been discussing, we also think it might >be a good solution whenever an internet-level router performs >multicast over the MANET subnet, i.e., the MANET subnet emulates >a conventional broadcast subnet by providing multicast. > >A significant advantage of this approach over either changing >the rules for IPv4 forwarding for the low-numbered multicasts >or changing service discovery applications to use routable IPv4 >multicast addresses is that this *may* be possible by simply >setting system configuration parameters for a "tunnel interface" >on existing hosts and routers. In other words, this approach >*may* be possible with little/no modification to existing >applications and/or host and router systems software. Richard's >idea was motivated in part by the literature that describes >IP encapsulation over ATM, and so there is relevant precendence >for this approach within the Internetworking framework. > >Comments? > >Fred and Richard From owner-manet@itd.nrl.navy.mil Wed Apr 11 20:51:45 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05664 for ; Wed, 11 Apr 2001 20:51:45 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA24138 for manet-outgoing; Wed, 11 Apr 2001 17:42:03 -0400 (EDT) Received: from monza.eurecom.fr (monza.eurecom.fr [193.55.113.133]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA24132 for ; Wed, 11 Apr 2001 17:42:00 -0400 (EDT) Received: from eurecom.fr (sancerre.eurecom.fr [193.55.114.199]) by monza.eurecom.fr (Postfix) with ESMTP id 05B4718DF5; Wed, 11 Apr 2001 23:41:59 +0200 (MET DST) Message-ID: <3AD4CFA7.FCD1F187@eurecom.fr> Date: Wed, 11 Apr 2001 23:41:59 +0200 From: Shiyi Wu X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Kinshuk Bakshi Cc: manet@itd.nrl.navy.mil Subject: Re: ns-create topology with unidirectional links References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Kinshuk Bakshi wrote: > Hello all, > > Here is my (stupid) question: > How can I emulate a unidirectional link between a chosen > pair of mobile nodes, using the NS framework? I am trying to provide > support for unidirectional links in the DSR routing protocol, and also > accounting for them at the lower (MAC) layers. > > Please excuse this email if it is out of context. > > Thanks > > Kinshuk Bakshi It's an interesting question. Just to now all simulations using NS2 which i know suppose the wireless links are symetric. To create un-symetric link between a pair of mobile nodes, I think there are two methods: 1. using sectional antenna instead of omni-directional antenna. You should implement sectional antenna in ns2 (like CMU implements omni-directional antenna in ns2). It will be very useful if we study the performance when mobile nodes equipe sectional antenna to reduce interference. 2. You can give different transmission power to different nodes so that nodes have different coverage diameter. But pay attention, when we use IEEE802.11, it requires symetric links!! Hope it can help you Shiyi From owner-manet@itd.nrl.navy.mil Fri Apr 13 05:29:36 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03993 for ; Fri, 13 Apr 2001 05:29:35 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA28829 for manet-outgoing; Fri, 13 Apr 2001 02:44:04 -0400 (EDT) Received: from hstnl.eng.fiu.edu (hstnl.eng.fiu.edu [131.94.163.238]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id CAA28824 for ; Fri, 13 Apr 2001 02:44:01 -0400 (EDT) From: jd@hstnl.eng.fiu.edu Received: from localhost (jd@localhost) by hstnl.eng.fiu.edu (8.11.0/8.11.0) with ESMTP id f3D5biB01085; Fri, 13 Apr 2001 01:37:44 -0400 Date: Fri, 13 Apr 2001 01:37:44 -0400 (EDT) To: Ya Xu cc: manet@itd.nrl.navy.mil Subject: Re: trace file evluation of ns simulation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk can i monitor the flow of traffic in a wireless network by using a RED queue, the way it can be done in wired simulations. thanks -jd -- ------------------------------------------------------------- Jaydeep Punde Department of ECE, FIU "I'm a nobody, & nobody is perfect, therefore i'm perfect :-) ------------------------------------------------------------- From owner-manet@itd.nrl.navy.mil Fri Apr 13 15:44:10 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16811 for ; Fri, 13 Apr 2001 15:44:10 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA09843 for manet-outgoing; Fri, 13 Apr 2001 13:04:46 -0400 (EDT) Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA09838 for ; Fri, 13 Apr 2001 13:04:44 -0400 (EDT) Received: from dilbert.cs.tamu.edu (IDENT:1623@dilbert [128.194.133.100]) by cs.tamu.edu (8.11.0/8.11.0) with ESMTP id f3DH4bi12785 for ; Fri, 13 Apr 2001 12:04:45 -0500 (CDT) Received: from localhost (jennyw@localhost) by dilbert.cs.tamu.edu (8.11.0/8.11.0) with ESMTP id f3DH4a302808 for ; Fri, 13 Apr 2001 12:04:37 -0500 (CDT) X-Authentication-Warning: dilbert.cs.tamu.edu: jennyw owned process doing -bs Date: Fri, 13 Apr 2001 12:04:36 -0500 (CDT) From: Jennifer Walter X-Sender: jennyw@dilbert To: manet@itd.nrl.navy.mil Subject: POMC Call for papers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk CALL FOR PAPERS POMC 2001 ========= Workshop on Principles of Mobile Computing August 29-30, 2001, Newport, Rhode Island, U.S.A. http://www.cs.tamu.edu/faculty/vaidya/pomc pending sponsorship by ACM SIGACT PURPOSE: 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 one-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 PODC 2001. 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. PAPER SUBMISSION: 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 * security * scheduling * media access techniques * quality-of-service issues * sensor networks * complexity analysis of algorithms for mobile environments Please consult any member of the organizing committee if you are uncertain whether your paper falls within the scope of the workshop. Submissions should be up to 10 pages in length with reasonable margins and line spacing. To submit, please e-mail either postscript or PDF file to pomc01@cs.tamu.edu (this e-mail address should become active by April 15, 2001), or fill the electronic submission form at http://lsewww.epfl.ch/POMC2001/submission.html . Important Dates: - Paper Submissions Due: May 15, 2001 - Notification of Acceptance: June 15, 2001 - Camera-ready Version Due: June 28, 2001 Authors of accepted papers are expected to present their work at the workshop. ORGANIZING COMMITTEE Andre Schiper (Ecole Polytechnique Federale de Lausanne, Switzerland) andre.schiper@epfl.ch Nitin H. Vaidya (Texas A&M University, USA) vaidya@cs.tamu.edu Jennifer L. Welch (Texas A&M University, USA) welch@cs.tamu.edu From owner-manet@itd.nrl.navy.mil Fri Apr 13 19:00:40 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20095 for ; Fri, 13 Apr 2001 19:00:40 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA14923 for manet-outgoing; Fri, 13 Apr 2001 16:43:36 -0400 (EDT) Received: from ns0.utdallas.edu (ns0.utdallas.edu [129.110.10.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA14918 for ; Fri, 13 Apr 2001 16:43:32 -0400 (EDT) Received: from inca.utdallas.edu (inca.utdallas.edu [129.110.16.10]) by ns0.utdallas.edu (Postfix) with ESMTP id 2C0F71A0475 for ; Fri, 13 Apr 2001 15:43:29 -0500 (CDT) Received: from localhost (sanket@localhost) by inca.utdallas.edu (8.9.1/8.9.1) with ESMTP id PAA23933 for ; Fri, 13 Apr 2001 15:43:28 -0500 (CDT) X-Authentication-Warning: inca.utdallas.edu: sanket owned process doing -bs Date: Fri, 13 Apr 2001 15:43:28 -0500 (CDT) From: Sanket Nesargi To: Mobile Ad-hoc Networks Subject: Service Discovery In MANETs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, Also, on MANETs and IP Layering, in terms of service discovery, we believe that the model of acquiring service would depend upon whether the MANET is operating isolated from the rest of the Internet, or connected to it. In case of the former, there is no central point ( a fixed node) from where service can be acquired - pointing to distributed models of service discovery (IP addresses, DNS resolution etc). In such a scenario, to allow nodes to join an existing n/w and discover existing services, it would make more sense for them to be allocated addresses out of a particular chunk. Mobile nodes, in their native mode of operation, could be using private IP addresses, and hence, there is a potential for IP address conflict when such nodes join a MANET. Perhaps, this (address allocation/conflict resolution) could also be a part of the service discovery phase, where nodes get configured with new addresses. In case the MANET is connected to the Internet too, this approach allows the advantage of route aggregation, since routes to all nodes inside the MANET could be advertised via the interface connected to the Internet. As mentioned in an earlier mail in the thread, allowing nodes to use their own IP addresses would require the use of Mobile IP by them (which can be avoided by allowing addresses off a common chunk) Regards, - Sanket --------------------------------------------------------------------- Standing on a hill in my mountain of dreams, telling myself its not as hard as it seems - Led Zeppelin Sanket S. Nesargi Distributed Systems Lab University of Texas at Dallas, http://www.utdallas.edu/~sanket Richardson TX 75082 --------------------------------------------------------------------- From owner-manet@itd.nrl.navy.mil Fri Apr 13 19:14:32 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20356 for ; Fri, 13 Apr 2001 19:14:31 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA14736 for manet-outgoing; Fri, 13 Apr 2001 16:34:04 -0400 (EDT) Received: from ns0.utdallas.edu (ns0.utdallas.edu [129.110.10.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA14728 for ; Fri, 13 Apr 2001 16:34:01 -0400 (EDT) Received: from inca.utdallas.edu (inca.utdallas.edu [129.110.16.10]) by ns0.utdallas.edu (Postfix) with ESMTP id 597111A0B31 for ; Fri, 13 Apr 2001 15:34:01 -0500 (CDT) Received: from localhost (sanket@localhost) by inca.utdallas.edu (8.9.1/8.9.1) with ESMTP id PAA23749 for ; Fri, 13 Apr 2001 15:34:00 -0500 (CDT) X-Authentication-Warning: inca.utdallas.edu: sanket owned process doing -bs Date: Fri, 13 Apr 2001 15:34:00 -0500 (CDT) From: Sanket Nesargi To: Mobile Ad-hoc Networks Subject: Ns and IP_BROADCAST Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, We had been working on some issues on MANET configuration and ran into questions regarding broadcast and multicast (a lot of which have been answered in the discussion on MANET and IP Layering). In the current implementation of the routing protocols in ns, any packet with the destination address IP_BROADCAST (255.255.255.255) and a port number other than the router port (255) is not received at even the one hop neighbors of the originator (we were using ns2.1b6a for our simulations). Depending upon the routing protocol used, the packet either gets dropped or crashes the software. We had to make modifications to ensure reception at atleast the one hop neighbors. I guess the actual semantics of to which all nodes this packet gets delivered to would depend upon the consensus reached on how such destination addresses need to be handled. Also, when ARP requests are broadcast, since the IP header is absent, and the broadcast in question is a layer 2 broadcast, it should be responded to only by the one hop neighbors (since, in any case, host routes need to be maintained for all nodes inside the MANET). If the link between the ARP source and target is unidirectional (A -> B), the ARP response (the target L2 address of which is A's L2 address), would not be delivered to A. Hence, ARP would fail in any case (unless something like L2TP based protocols are used to overcome this). This leads us to believe that additional effort would be required to achieve synergy between the routing protocols and ARP cache in the presence of unidirectional links. Thanks, Sanket --------------------------------------------------------------------- Standing on a hill in my mountain of dreams, telling myself its not as hard as it seems - Led Zeppelin Sanket S. Nesargi Distributed Systems Lab University of Texas at Dallas, http://www.utdallas.edu/~sanket Richardson TX 75082 --------------------------------------------------------------------- From owner-manet@itd.nrl.navy.mil Mon Apr 16 04:17:08 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01574 for ; Mon, 16 Apr 2001 04:17:07 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id BAA02159 for manet-outgoing; Mon, 16 Apr 2001 01:23:17 -0400 (EDT) Received: from samrat.cisco.com (samrat.cisco.com [192.135.241.27]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id BAA02154 for ; Mon, 16 Apr 2001 01:23:13 -0400 (EDT) Received: from cisco.com ([192.135.239.133]) by samrat.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA06370 for ; Mon, 16 Apr 2001 10:53:13 +0530 (IST) Message-ID: <3ADA80EE.8F0B6F7A@cisco.com> Date: Mon, 16 Apr 2001 10:49:42 +0530 From: Satish Reddy Organization: CISCO X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mobile Ad-hoc Networks Subject: new to manet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit hello, i am new to the manet group and would like to know info regarding manet.i would like to know where exactly(which device) does this aodv protocol fit in.i mean does it fit in btc or bsc or msc.....any more information if can be provided i would be very thanfull. satish From owner-manet@itd.nrl.navy.mil Mon Apr 16 07:33:15 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02366 for ; Mon, 16 Apr 2001 07:33:14 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id EAA03471 for manet-outgoing; Mon, 16 Apr 2001 04:49:24 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id EAA03466 for ; Mon, 16 Apr 2001 04:49:21 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA06775 for ; Mon, 16 Apr 2001 04:49:23 -0400 (EDT) Received: from ii0015exch001u.wins.lucent.com (h135-254-248-252.lucent.com [135.254.248.252]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA06728 for ; Mon, 16 Apr 2001 04:49:13 -0400 (EDT) Received: by II0015EXCH001U with Internet Mail Service (5.5.2650.21) id <23F8MXWZ>; Mon, 16 Apr 2001 14:18:55 +0530 Message-ID: From: "Rajan, Hridesh (Hridesh)" To: "'Satish Reddy'" Cc: "'manet@itd.nrl.navy.mil'" Subject: RE: new to manet Date: Mon, 16 Apr 2001 14:18:53 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hello Satish, The information regarding Mobile Adhoc Networks can be obtained from various sources. I am listing few below: Official Homepage of the MANET working group at IETF: http://www.ietf.org/html.charters/manet-charter.html Homepage of the MANET Working Group: http://tonnant.itd.nrl.navy.mil/manet/manet_home.html Charles E. Perkins, "Ad Hoc Networking",ISBN: 0-201-30976-9, Publishers: ADDISON-WESLEY This list is by no means complete and other addition to this list is welcome. About the AODV protocol and the place where it fits in the network. I would like to advise you to please go through the basic concepts of MANETS and then try to see whether the Network Elements which you are trying to fit AODV in really exist in the MANET context or not. best regards, Hridesh > -----Original Message----- > From: Satish Reddy [mailto:asatishr@cisco.com] > Sent: Monday, April 16, 2001 10:50 AM > To: Mobile Ad-hoc Networks > Subject: new to manet > > > hello, > i am new to the manet group and would like to know info regarding > manet.i would like to know where exactly(which device) does this aodv > protocol fit in.i mean does it fit in btc or bsc or msc.....any more > information if can be provided i would be very thanfull. > satish > From owner-manet@itd.nrl.navy.mil Mon Apr 16 15:41:11 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12461 for ; Mon, 16 Apr 2001 15:41:10 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA14391 for manet-outgoing; Mon, 16 Apr 2001 12:40:56 -0400 (EDT) Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA14386 for ; Mon, 16 Apr 2001 12:40:51 -0400 (EDT) Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA29123 for ; Mon, 16 Apr 2001 12:40:51 -0400 (EDT) Received: from ii0015exch001u.wins.lucent.com (h135-254-248-252.lucent.com [135.254.248.252]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA29090 for ; Mon, 16 Apr 2001 12:40:50 -0400 (EDT) Received: by II0015EXCH001U with Internet Mail Service (5.5.2650.21) id <23F8M76P>; Mon, 16 Apr 2001 22:10:47 +0530 Message-ID: From: "Rajan, Hridesh (Hridesh)" To: "'asatishr@cisco.com'" Cc: "Manet (E-mail)" Subject: RE: where exactly does AODV protocol fit in? Date: Mon, 16 Apr 2001 22:10:46 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hello Satish, Let me first give you a brief idea of Mobile Ad Hoc Networks.An Adhoc Mobile Network is an autonomous system of mobile routers (and associated hosts) connected by wireless links--the union of which form an arbitrary graph. The routers are free to move randomly and organize themselves arbitrarily; thus, the network's wireless topology may change rapidly and unpredictably. Such a network may operate in a standalone fashion, or may be connected to the larger Internet. In contrast with the cellular wireless networks(GSM, AMPS etc.) these networks do not interact using a base station(BSS in case of GSM), all the packet routing is collabaratively done. So any routing algortihm that is ment for these networks essentially works in the mobile hosts themselves. In other words mobile hosts themselves acts as a router. Hope this helps. For other information you can refer to my article available on the URL http://hrideshwww.tripod.com/MANET.html which gives a brief introduction to the issues in these networks. regards, Hridesh > -----Original Message----- > From: Satish Reddy [mailto:asatishr@cisco.com] > Sent: Monday, April 16, 2001 4:21 PM > To: hridesh@lucent.com > Subject: where exactly does AODV protocol fir in? > > > hello, > first i would like to thank you for your support in my > queries.i have > been through the sites that you have refered to.but still none of them > specifies which physical device does this AODV protocol sit > in.is it in > the routers or the mobile hosts itself or is it in the centralized > controller.it would be of great help if you can make this point clear. > thanking you once again for your support > satish > From owner-manet@itd.nrl.navy.mil Mon Apr 16 20:29:30 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15612 for ; Mon, 16 Apr 2001 20:29:29 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA24687 for manet-outgoing; Mon, 16 Apr 2001 18:08:17 -0400 (EDT) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id SAA24682 for ; Mon, 16 Apr 2001 18:08:14 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA29006 for ; Mon, 16 Apr 2001 18:08:15 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA06672 for ; Mon, 16 Apr 2001 18:08:15 -0400 (EDT) Received: from humbads.mit.edu (HUMBADS.MIT.EDU [18.250.0.182]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id SAA00542 for ; Mon, 16 Apr 2001 18:08:14 -0400 (EDT) Message-Id: <5.0.2.1.0.20010416154924.03229250@h.imap.itd.umich.edu> X-Sender: humbads@h.imap.itd.umich.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 16 Apr 2001 18:08:24 -0400 To: manet@itd.nrl.navy.mil From: Shailesh Humbad Subject: geographic protocols In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hello everyone, Does anyone know of any MANET routing protocols or systems specifically geared towards vehicles on the highways and roads? They should take advantage of at least one of the following: geographic position information, known road layouts, known likelihoods of node density, or fixed position 'helper' nodes? I'm trying to argue in my thesis that a MANET would be both feasible on congested roadways, and suitable for mitigating the congestion. Not a new concept, but the protocols I've seen so far seem very theoretical and not applied, and I question if they would work on a network of 100,000 nodes. GPSR (Greedy Perimeter Stateless Routing) combined with a location service seems most feasible, but I wonder if there is further application specific work. Please pardon me if I'm missing something; I would appreciate your comments. Regards, Shailesh From owner-manet@itd.nrl.navy.mil Tue Apr 17 06:02:18 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04830 for ; Tue, 17 Apr 2001 06:02:17 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id DAA02141 for manet-outgoing; Tue, 17 Apr 2001 03:07:14 -0400 (EDT) Received: from samrat.cisco.com (samrat.cisco.com [192.135.241.27]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id DAA02136 for ; Tue, 17 Apr 2001 03:07:09 -0400 (EDT) Received: from psanghadpc ([192.135.239.206]) by samrat.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id MAA03896 for ; Tue, 17 Apr 2001 12:37:09 +0530 (IST) Message-ID: <099f01c0c70d$b05ea9b0$ceef87c0@psanghadpc> Reply-To: "Pranav" From: "Pranav" To: "Manet \(E-mail\)" References: Subject: Re: where exactly does AODV protocol fit in? Date: Tue, 17 Apr 2001 12:41:56 +0530 Organization: Cisco 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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi Hridesh, The URL you sent is very good, it cleared most of my doubts. But still I have some questions, Presently, does this protocol exist in live network( mobile host) ? Has this protocol relationship with 3G hosts ? Regards, Pranav. ----- Original Message ----- From: "Rajan, Hridesh (Hridesh)" To: Cc: "Manet (E-mail)" Sent: Monday, April 16, 2001 10:10 PM Subject: RE: where exactly does AODV protocol fit in? > Hello Satish, > > Let me first give you a brief idea of Mobile Ad Hoc > Networks.An Adhoc Mobile Network is an autonomous system > of mobile routers (and associated hosts) connected by > wireless links--the union of which form an arbitrary graph. > The routers are free to move randomly and organize > themselves arbitrarily; thus, the network's wireless > topology may change rapidly and unpredictably. Such a > network may operate in a standalone fashion, or may be > connected to the larger Internet. > > In contrast with the cellular wireless networks(GSM, > AMPS etc.) these networks do not interact using a > base station(BSS in case of GSM), all the packet > routing is collabaratively done. > > So any routing algortihm that is ment for these networks > essentially works in the mobile hosts themselves. In other > words mobile hosts themselves acts as a router. > > Hope this helps. For other information you can refer to > my article available on the URL > http://hrideshwww.tripod.com/MANET.html which gives a brief > introduction to the issues in these networks. > > regards, > Hridesh > > > -----Original Message----- > > From: Satish Reddy [mailto:asatishr@cisco.com] > > Sent: Monday, April 16, 2001 4:21 PM > > To: hridesh@lucent.com > > Subject: where exactly does AODV protocol fir in? > > > > > > hello, > > first i would like to thank you for your support in my > > queries.i have > > been through the sites that you have refered to.but still none of them > > specifies which physical device does this AODV protocol sit > > in.is it in > > the routers or the mobile hosts itself or is it in the centralized > > controller.it would be of great help if you can make this point clear. > > thanking you once again for your support > > satish > > > From owner-manet@itd.nrl.navy.mil Tue Apr 17 09:44:19 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07555 for ; Tue, 17 Apr 2001 09:44:18 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA04575 for manet-outgoing; Tue, 17 Apr 2001 06:34:33 -0400 (EDT) Received: from x86unx3.comp.nus.edu.sg (x86unx3.comp.nus.edu.sg [137.132.90.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id GAA04568 for ; Tue, 17 Apr 2001 06:33:57 -0400 (EDT) Received: from decunx.comp.nus.edu.sg (root@decunx-m.comp.nus.edu.sg [137.132.90.9]) by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with ESMTP id SAA29550 for ; Tue, 17 Apr 2001 18:35:36 +0800 (GMT-8) Received: from sun450-88.comp.nus.edu.sg (liqiming@sun450.comp.nus.edu.sg [137.132.88.4]) by decunx.comp.nus.edu.sg (8.8.5/8.8.5) with ESMTP id SAA04224 for ; Tue, 17 Apr 2001 18:33:51 +0800 (SST) Date: Tue, 17 Apr 2001 18:33:47 +0800 (GMT-8) From: Li Qiming To: MANET Subject: scenario generator Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi all. I have written a scenario generator for MANETs. The generator assumes that a scenario is specified by * a rectangular area, start and stop time; * groups of nodes, where each group may have a center; * the movement of each group is described by the mobility model for the center (if any) and the mobility model for group members relative to the center. The mobility models that have been implemented include random waypoint, pursuit and brownian motion. Nodes can accelerate. I would like to get a feel for the MANET community's interest in this scenario generator. The code is available at http://www.comp.nus.edu.sg/~liqiming/fyp/scengen/index.html The package includes three sample scenario files, as well as (a slightly modified) ad-hockey for viewing the generated Tcl files (which are input for NS-2). Please feel free to download the code and give it a spin. Your feedback (especially on whether and how I should develop the generator further) is most welcome. Regards, Qiming Li From owner-manet@itd.nrl.navy.mil Wed Apr 18 11:15:23 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12608 for ; Wed, 18 Apr 2001 11:15:22 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA09929 for manet-outgoing; Wed, 18 Apr 2001 08:47:26 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA09924 for ; Wed, 18 Apr 2001 08:47:23 -0400 (EDT) From: philippe.jacquet@inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.11.1/8.10.0) with SMTP id f3IClNf12868 for ; Wed, 18 Apr 2001 14:47:23 +0200 (MET DST) Message-Id: <3.0.1.32.20010418145533.00c831c0@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Wed, 18 Apr 2001 14:55:33 +0200 To: manet@itd.nrl.navy.mil Subject: AODV Black list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk It seems to me that BLACKLIST_TIMEOUT parameter value proposed in AODV draft is far too short. If more than RREQ_RETRIES (2) unidirectional nodes have to be eliminated, then the first node will get out black-list before last node enters. Am I correct? A--B--C--D1--E--F--G -------->D2 -------->D3 Bidirectional routes will never be established from A to E, F,... Philippe From owner-manet@itd.nrl.navy.mil Wed Apr 18 11:18:08 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12705 for ; Wed, 18 Apr 2001 11:18:07 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA08878 for manet-outgoing; Wed, 18 Apr 2001 08:04:13 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA08873 for ; Wed, 18 Apr 2001 08:04:10 -0400 (EDT) From: philippe.jacquet@inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.11.1/8.10.0) with SMTP id f3IC49f12308; Wed, 18 Apr 2001 14:04:09 +0200 (MET DST) Message-Id: <3.0.1.32.20010418141219.00c07e20@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Wed, 18 Apr 2001 14:12:19 +0200 To: Shailesh Humbad , manet@itd.nrl.navy.mil Subject: Re: geographic protocols In-Reply-To: <5.0.2.1.0.20010416154924.03229250@h.imap.itd.umich.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id IAA08874 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by itd.nrl.navy.mil id IAA08878 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA12705 Dear Shailesh, There are two issues for the use of ad hoc networking on roads. First issue is the organisation of the network which is illimited in theory. In this case clustering, hierarchical addressing are welcome. Geographic and road references could be useful here. Second issue is the relative speed of mobile nodes that can make very unstable links. One way to cope with this could be to give different subnetwork allocations to each car flows (up and down) or to have special protocol optimization regarding fast moving nodes. But maybe it is a secondary issue. Philippe A 18:08 16/04/01 -0400, Shailesh Humbad a écrit : >Hello everyone, > >Does anyone know of any MANET routing protocols or systems specifically geared towards vehicles on the highways and roads? They should take advantage of at least one of the following: geographic position information, known road layouts, known likelihoods of node density, or fixed position 'helper' nodes? I'm trying to argue in my thesis that a MANET would be both feasible on congested roadways, and suitable for mitigating the congestion. Not a new concept, but the protocols I've seen so far seem very theoretical and not applied, and I question if they would work on a network of 100,000 nodes. GPSR (Greedy Perimeter Stateless Routing) combined with a location service seems most feasible, but I wonder if there is further application specific work. Please pardon me if I'm missing something; I would appreciate your comments. > >Regards, >Shailesh > > From owner-manet@itd.nrl.navy.mil Wed Apr 18 14:26:17 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15237 for ; Wed, 18 Apr 2001 14:26:16 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA16126 for manet-outgoing; Wed, 18 Apr 2001 11:24:30 -0400 (EDT) Received: from malonne.lifl.fr (malonne.lifl.fr [134.206.10.29]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA16108 for ; Wed, 18 Apr 2001 11:24:26 -0400 (EDT) Received: from lifl.lifl.fr (lifl.lifl.fr [134.206.10.18]) by malonne.lifl.fr (8.9.3/jtpda-5.3.3) with ESMTP id RAA09072 for ; Wed, 18 Apr 2001 17:22:19 +0200 (MET DST) Received: from chimay.lifl.fr (mail@chimay [134.206.11.15]) by lifl.lifl.fr (8.9.3/jtpda-5.3.3) with ESMTP id RAA12208 for ; Wed, 18 Apr 2001 17:24:14 +0200 (MET DST) Received: from cartigny (helo=localhost) by chimay.lifl.fr with local-esmtp (Exim 3.12 #1 (Debian)) id 14ptlp-00020v-00 for ; Wed, 18 Apr 2001 17:21:29 +0200 Date: Wed, 18 Apr 2001 17:21:29 +0200 (CEST) From: "Julien.Cartigny" cc: manet@itd.nrl.navy.mil Subject: Re: geographic protocols In-Reply-To: <3.0.1.32.20010418141219.00c07e20@menetou.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by itd.nrl.navy.mil id LAA16111 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by itd.nrl.navy.mil id LAA16126 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA15237 I saw a MIT's paper about this idea: "CarNet: A Scalable Ad Hoc Wireless Network System" by R. Morris and J. Jannotti and J. Li and D. Decouto and F. Kaasho ek http://citeseer.nj.nec.com/morris00carnet.html On Wed, 18 Apr 2001 philippe.jacquet@inria.fr wrote: > Dear Shailesh, > > There are two issues for the use of ad hoc networking on roads. > > First issue is the organisation of the network which is illimited in > theory. In this case clustering, hierarchical addressing are welcome. > Geographic and road references could be useful here. > > Second issue is the relative speed of mobile nodes that can make very > unstable links. One way to cope with this could be to give different > subnetwork allocations to each car flows (up and down) or to have special > protocol optimization regarding fast moving nodes. But maybe it is a > secondary issue. > > Philippe > > A 18:08 16/04/01 -0400, Shailesh Humbad a écrit : > >Hello everyone, > > > >Does anyone know of any MANET routing protocols or systems specifically > geared towards vehicles on the highways and roads? They should take > advantage of at least one of the following: geographic position > information, known road layouts, known likelihoods of node density, or > fixed position 'helper' nodes? I'm trying to argue in my thesis that a > MANET would be both feasible on congested roadways, and suitable for > mitigating the congestion. Not a new concept, but the protocols I've seen > so far seem very theoretical and not applied, and I question if they would > work on a network of 100,000 nodes. GPSR (Greedy Perimeter Stateless > Routing) combined with a location service seems most feasible, but I wonder > if there is further application specific work. Please pardon me if I'm > missing something; I would appreciate your comments. > > > >Regards, > >Shailesh > > > > > ------------------------------------------------------------------ CARTIGNY Julien These d'informatique dans l'equipe RD2P a l'universite de Lille 1 (Phd of Computer Science at the University of Lille 1 / France) "Rosebud" - Citizen Kane/Orson Wells From owner-manet@itd.nrl.navy.mil Wed Apr 18 15:05:08 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16165 for ; Wed, 18 Apr 2001 15:05:08 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA17762 for manet-outgoing; Wed, 18 Apr 2001 12:08:58 -0400 (EDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA17751 for ; Wed, 18 Apr 2001 12:08:55 -0400 (EDT) Received: from didley (didley [128.111.49.133]) by letters.cs.ucsb.edu (8.9.3+Sun/8.9.3) with ESMTP id JAA08399 for ; Wed, 18 Apr 2001 09:08:55 -0700 (PDT) Date: Wed, 18 Apr 2001 09:08:55 -0700 (PDT) From: "Elizabeth M. Royer" X-Sender: eroyer@didley To: manet@itd.nrl.navy.mil Subject: AODV implementations? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, We are trying to get an accurate list of AODV implementations, either currently under development or already completed. If you have an AODV implementation, could you please send me your name and affiliation, as well as the current status of the work? Thanks, Elizabeth ps: my new email address: eroyer@cs.ucsb.edu From owner-manet@itd.nrl.navy.mil Wed Apr 18 19:20:51 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19525 for ; Wed, 18 Apr 2001 19:20:50 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA27888 for manet-outgoing; Wed, 18 Apr 2001 16:42:54 -0400 (EDT) Date: Wed, 18 Apr 2001 16:42:54 -0400 (EDT) Message-Id: <200104182042.QAA27888@itd.nrl.navy.mil> From: "Jeff Boleng" To: "Julien.Cartigny" Cc: manet@itd.nrl.navy.mil Reply-To: Subject: RE: geographic protocols MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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.50.4133.2400 In-Reply-To: Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by itd.nrl.navy.mil id QAA27888 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA19525 The current IEEE Communications magazine (April 2001, Vol 39. No. 4) has a relevant article as well: Broadband Communications on the Highways of Tomorrow Charles D. Gavrilovich, Jr. -----Original Message----- From: owner-manet@itd.nrl.navy.mil [mailto:owner-manet@itd.nrl.navy.mil]On Behalf Of Julien.Cartigny Sent: Wednesday, April 18, 2001 9:21 AM Cc: manet@itd.nrl.navy.mil Subject: Re: geographic protocols I saw a MIT's paper about this idea: "CarNet: A Scalable Ad Hoc Wireless Network System" by R. Morris and J. Jannotti and J. Li and D. Decouto and F. Kaasho ek http://citeseer.nj.nec.com/morris00carnet.html On Wed, 18 Apr 2001 philippe.jacquet@inria.fr wrote: > Dear Shailesh, > > There are two issues for the use of ad hoc networking on roads. > > First issue is the organisation of the network which is illimited in > theory. In this case clustering, hierarchical addressing are welcome. > Geographic and road references could be useful here. > > Second issue is the relative speed of mobile nodes that can make very > unstable links. One way to cope with this could be to give different > subnetwork allocations to each car flows (up and down) or to have special > protocol optimization regarding fast moving nodes. But maybe it is a > secondary issue. > > Philippe > > A 18:08 16/04/01 -0400, Shailesh Humbad a écrit : > >Hello everyone, > > > >Does anyone know of any MANET routing protocols or systems specifically > geared towards vehicles on the highways and roads? They should take > advantage of at least one of the following: geographic position > information, known road layouts, known likelihoods of node density, or > fixed position 'helper' nodes? I'm trying to argue in my thesis that a > MANET would be both feasible on congested roadways, and suitable for > mitigating the congestion. Not a new concept, but the protocols I've seen > so far seem very theoretical and not applied, and I question if they would > work on a network of 100,000 nodes. GPSR (Greedy Perimeter Stateless > Routing) combined with a location service seems most feasible, but I wonder > if there is further application specific work. Please pardon me if I'm > missing something; I would appreciate your comments. > > > >Regards, > >Shailesh > > > > > ------------------------------------------------------------------ CARTIGNY Julien These d'informatique dans l'equipe RD2P a l'universite de Lille 1 (Phd of Computer Science at the University of Lille 1 / France) "Rosebud" - Citizen Kane/Orson Wells From owner-manet@itd.nrl.navy.mil Wed Apr 18 22:56:52 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22673 for ; Wed, 18 Apr 2001 22:56:52 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA02892 for manet-outgoing; Wed, 18 Apr 2001 20:41:08 -0400 (EDT) Received: from sfo.erg.sri.com (sfo.erg.sri.com [128.18.100.4]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id UAA02885 for ; Wed, 18 Apr 2001 20:41:05 -0400 (EDT) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id RAA18321; Wed, 18 Apr 2001 17:37:50 -0700 (PDT) Message-ID: <3ADE3422.DF77335@erg.sri.com> Date: Wed, 18 Apr 2001 17:41:06 -0700 From: "Fred L. Templin" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil Subject: Re: MANET & IP layering References: <200104100403.VAA25785@pit.erg.sri.com> <3AD31525.71E5B0D3@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Charlie, Sorry for the delay in responding to you; please find some comments/questions for your message below: "Charles E. Perkins" wrote: > > Hello Fred, > > > 1. Within the MANET routing protocol, the IPv4 address assigned > > to each MANET node is essentially treated as an independent > > node ID. That is, there is no requirement for a common prefix > > for IPv4 forwarding between nodes within the MANET. > > Agreed -- but, we should _allow_ for regions to have a common prefix. Yes, I agree. My language was vague - I was not intending to imply that common prefixes should be disallowed within the MANET. > > 2. From the outside, the MANET must present itself to the rest > > of the Internet as a set of one or more aggregatable IPv4 > > prefixes. > > This has the disadvantage of excluding any other wireless node that > happens to arrive with an IP address not represented by the > aggregated prefixes. > > However, if a manet node can use Mobile IP with a home agent in > the infrastructure, the need for advertising its prefix evaporates. I was more or less expecting the mobile nodes would associate with a Mobile IPv4 Foreign Agent when they join the MANET. I am under the impression that, when a Mobile node receives a care-of-address from a foreign agent in the MANET it is visiting, the care-of-address assignment is under the control of either the foreign agent or something like DHCP. So, the care-of-address would likely appear as belonging to an aggregatable IPv4 advertisment from the perspective of the Internet if the foreign agent and/or DHCP server are configured in a coherent fashion. I suppose another alternative is some sort of NAT to turn the mobile node's home address into something that makes topological sense for the MANET's attachment point to the Internet. Can you think of any legitimate cases in which a foreign node should be allowed to send an IPv4 packet from the MANET to the Internet such that the IPv4 source address in the packet does *not* belong to an aggregatable prefix which can be traced back to the MANET? > > 3. In order to accomplish #2, some sort of subnet convergence > > should occur - perhaps through some sort of gateway affiliation > > protocol - such that one or more logical IPv4 subnets (LIS) > > appear to reside within the MANET when viewed from the outside. > > I'm willing to agree that manet gateways should be ABLE to advertise > subnets (as long as it's sensible to do so), but I don't believe > we should make the restriction that all manet nodes fit within the > advertised subnet aggregation. > > > In terms of the remaining issue I have been citing (i.e. how > > to get the low-numbered multicasts to span multiple hops within > > the MANET), Richard's idea entails IP-in-IP encapsulation for IPv4 > > packets sent to the limited broadcast address and low-numbered > > multicast addresses, with the outer IPv4 header containing a > > *routable* IPv4 multicast destination address that is reserved > > with IANA for MANET operation. > > Maybe it would be better to have an "all-nodes" multicast > address, and use two other methods to restrict distribution: > > 1) setting TTL < network diameter, and > > 2) allowing gateway router policy to avoid forwarding along > certain (say, wired) interfaces. Yes, this is the same basic model we had in mind. We agree that using the TTL to effectively establish a network diameter is one possible configuration option. In terms of 2), this is basically the same thing I was trying to imply in my original note when I referred to "administrative scoping" for multicasts. Again, this is one possible configuration option. > I'd _really_ hate to go down the road of partitioning the > Internet address space into manet/non-manet prefixes > or multicast addresses. No - we are not proposing any sort of split such as this. The problem we are attempting to address is, for IPv4 packets sent to the all-1's broadcast and low-numbered multicast addresses (those in the range from 224.0.0.0 - 224.0.0.255), there may be cases in which you would like the packets to travel more than one hop - even though the IETF standards all specify that such packets should not be forwarded. In some instances, you might wish for these packets to be forward based on a hop count in the TTL or some form of administrative scoping rules or both, as we agreed above. The particular instance we are concerned with is networks that are formed by a collection of nodes with IEEE 802.11 interfaces in ad hoc mode such that the graph of the topology is not fully connected at the data link level. As such, the data link broadcast messages sent by a node reach only a proper subset of the nodes on the topology. We are torn between the notion of whether this model represents just a special case of an NBMA network, or a new class unto itself - perhaps a term such as "Limited Broadcast, Multiple Access (LBMA)" would be appropriate. The IEEE 802.11 example is just one such instance, and we agree that such networks are not necessarily specific to MANETs. Therefore, we are not proposing any MANET-specific language. The idea my colleague Richard Ogier has proposed is a form of IPv4-in-IPv4 encapsulation in which the destination address in both the inner and outer headers is a multicast address. The address in the outer header will be an IANA assigned number from the range of *forwardable* IPv4 multicast addresses (those between 224.0.1.0 - 239.255.255.255) and the address in the inner header will be the all-1's broadcast address or a low numbered multicast address. (There may be application for other IPv4 address forms beyond the particular case we are concerned with.) We are hoping that this will allow services such as router advertisements and Mobile IP agent advertisements to reach mobile nodes that are more than one hop away from the sending node on such LBMA networks. The plan would be to register a single assigned number with IANA for MANET/LBMA multicasting as we have described it above. (There may be other uses for such an assigned number beyond the cases discussed so far in this thread.) We think that this may allow existing applications and IPv4 protocol stacks to function without modification since configuration parameters can be set up on nodes that access the LBMA network to enable this sort of IPv4-in-IPv4 encapsulation. > > While > > this idea appears to be a good fit for the service discovery > > protocol probelm we have been discussing, > > I'm interested in service discovery within manet, but I don't > recollect the discussion on the mailing list. Did I miss it? The term "service discovery" crept into this thread as the discussion evolved - I believe I may have been at fault for this. I was more or less using that term to colloquially refer to the class of applications that send/receive messages using the all-1's broadcast address or one of the low-numbered IPv4 multicast addresses. Sorry for any confusion this may have caused. Comments? Fred Templin templin@erg.sri.com From owner-manet@itd.nrl.navy.mil Thu Apr 19 04:20:44 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08622 for ; Thu, 19 Apr 2001 04:20:43 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id BAA06634 for manet-outgoing; Thu, 19 Apr 2001 01:32:15 -0400 (EDT) Received: from mail.rz.uni-ulm.de (sirius-giga.rz.uni-ulm.de [134.60.246.36]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id BAA06629 for ; Thu, 19 Apr 2001 01:32:12 -0400 (EDT) Received: from informatik.uni-ulm.de (seychelles.informatik.uni-ulm.de [134.60.70.20]) by mail.rz.uni-ulm.de (8.9.3/8.9.3) with ESMTP id HAA10239; Thu, 19 Apr 2001 07:32:09 +0200 (MEST) Message-ID: <3ADE784A.C4A0A57F@informatik.uni-ulm.de> Date: Thu, 19 Apr 2001 07:31:54 +0200 From: Frank Kargl Organization: University of Ulm, Germany X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: de,en MIME-Version: 1.0 To: "Elizabeth M. Royer" CC: manet@itd.nrl.navy.mil Subject: Re: AODV implementations? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Dear Elizabeth, "Elizabeth M. Royer" wrote: > We are trying to get an accurate list of AODV implementations, > either currently under development or already completed. > If you have an AODV implementation, could you please send me > your name and affiliation, as well as the current status of > the work? We are currently starting a diploma thesis with one of our students with the assignement to realize a modular adhoc routing daemon for linux. It is planned that at least aodv, dsr and olsr are to be implemented. Other protocols should be easily integratable into the framework. Part of the work will be a real-world test of the different protocols with a network consisting of about 20 mobile nodes (we dont have more notebooks available ;-). Expect results in 4-5 months from now. Affiliation: Frank Kargl Dep. of Multimedia Computing University of Ulm 89069 Ulm Germany Regards ... Frank -- ----------------------------------------------------------------------- Frank Kargl Multimedia Computing, University of Ulm, Germany Mail:frank.kargl@informatik.uni-ulm.de http://www.uni-ulm.de/~fkargl/ ----------------------------------------------------------------------- Use the SOURCE, Luke ! I feel a great disturbance in the SOURCE. But beware of the Microsoft side of the SOURCE ! From owner-manet@itd.nrl.navy.mil Fri Apr 20 19:16:51 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19726 for ; Fri, 20 Apr 2001 19:16:51 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA28488 for manet-outgoing; Fri, 20 Apr 2001 16:54:03 -0400 (EDT) Received: from Xenon.Stanford.EDU (Xenon.Stanford.EDU [171.64.66.201]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA28483 for ; Fri, 20 Apr 2001 16:54:00 -0400 (EDT) Received: from chekist (rains-00-28s-2.Stanford.EDU [128.12.185.89]) by Xenon.Stanford.EDU (8.9.1/8.9.1) with SMTP id NAA04290 for ; Fri, 20 Apr 2001 13:54:01 -0700 (PDT) Message-ID: <000801c0c9dc$02c18940$59b90c80@Stanford.EDU> From: "Eugene Fartkin" To: Subject: participation guarantees Date: Fri, 20 Apr 2001 13:53:21 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C0C9A1.4355FBC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C0C9A1.4355FBC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello everyone. I was wondering if anyone knows good place to look for some work done in = the area of participation guarantees for Ad Hoc network (ways to assure = that node route traffic other then their own)? Also I am wondering if any work was done on economic model for = participants of Ad Hoc network? Thank you. Best regards. Eugene Fratkin ------=_NextPart_000_0005_01C0C9A1.4355FBC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello everyone.
I was wondering if anyone knows good = place to look=20 for some work done in the area of participation guarantees for Ad Hoc = network=20 (ways to assure that node route traffic other then their = own)?
Also I am wondering if any work was = done on=20 economic model for participants of Ad Hoc network?
Thank you.
Best regards.
Eugene = Fratkin
------=_NextPart_000_0005_01C0C9A1.4355FBC0-- From owner-manet@itd.nrl.navy.mil Tue Apr 24 04:44:26 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05027 for ; Tue, 24 Apr 2001 04:44:26 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA17350 for manet-outgoing; Tue, 24 Apr 2001 02:09:45 -0400 (EDT) Received: from m018.com ([210.112.11.138]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id CAA17345 for ; Tue, 24 Apr 2001 02:09:42 -0400 (EDT) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Tue, 24 Apr 2001 14:54:59 +0900 Received: from itd.nrl.navy.mil ([132.250.83.3]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 17 Apr 2001 18:08:37 +0900 Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id DAA02141 for manet-outgoing; Tue, 17 Apr 2001 03:07:14 -0400 (EDT) Received: from samrat.cisco.com (samrat.cisco.com [192.135.241.27]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id DAA02136 for ; Tue, 17 Apr 2001 03:07:09 -0400 (EDT) Received: from psanghadpc ([192.135.239.206]) by samrat.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id MAA03896 for ; Tue, 17 Apr 2001 12:37:09 +0530 (IST) Message-ID: <099f01c0c70d$b05ea9b0$ceef87c0@psanghadpc> Reply-To: "Pranav" From: "Pranav" To: "Manet \(E-mail\)" References: Subject: Re: where exactly does AODV protocol fit in? Date: Tue, 17 Apr 2001 12:41:56 +0530 Organization: Cisco 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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi Hridesh, The URL you sent is very good, it cleared most of my doubts. But still I have some questions, Presently, does this protocol exist in live network( mobile host) ? Has this protocol relationship with 3G hosts ? Regards, Pranav. ----- Original Message ----- From: "Rajan, Hridesh (Hridesh)" To: Cc: "Manet (E-mail)" Sent: Monday, April 16, 2001 10:10 PM Subject: RE: where exactly does AODV protocol fit in? > Hello Satish, > > Let me first give you a brief idea of Mobile Ad Hoc > Networks.An Adhoc Mobile Network is an autonomous system > of mobile routers (and associated hosts) connected by > wireless links--the union of which form an arbitrary graph. > The routers are free to move randomly and organize > themselves arbitrarily; thus, the network's wireless > topology may change rapidly and unpredictably. Such a > network may operate in a standalone fashion, or may be > connected to the larger Internet. > > In contrast with the cellular wireless networks(GSM, > AMPS etc.) these networks do not interact using a > base station(BSS in case of GSM), all the packet > routing is collabaratively done. > > So any routing algortihm that is ment for these networks > essentially works in the mobile hosts themselves. In other > words mobile hosts themselves acts as a router. > > Hope this helps. For other information you can refer to > my article available on the URL > http://hrideshwww.tripod.com/MANET.html which gives a brief > introduction to the issues in these networks. > > regards, > Hridesh > > > -----Original Message----- > > From: Satish Reddy [mailto:asatishr@cisco.com] > > Sent: Monday, April 16, 2001 4:21 PM > > To: hridesh@lucent.com > > Subject: where exactly does AODV protocol fir in? > > > > > > hello, > > first i would like to thank you for your support in my > > queries.i have > > been through the sites that you have refered to.but still none of them > > specifies which physical device does this AODV protocol sit > > in.is it in > > the routers or the mobile hosts itself or is it in the centralized > > controller.it would be of great help if you can make this point clear. > > thanking you once again for your support > > satish > > > From owner-manet@itd.nrl.navy.mil Tue Apr 24 13:20:28 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10938 for ; Tue, 24 Apr 2001 13:20:26 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA25444 for manet-outgoing; Tue, 24 Apr 2001 10:46:55 -0400 (EDT) Received: from bob.dera.gov.uk (bob.dera.gov.uk [192.5.29.90]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA25436 for ; Tue, 24 Apr 2001 10:46:50 -0400 (EDT) Received: by bob.dera.gov.uk; (8.8.8/1.3/10May95) id PAA00807; Tue, 24 Apr 2001 15:50:27 +0100 (BST) Received: (qmail 29452 invoked from network); 24 Apr 2001 15:41:13 -0000 Received: from gauntlet.mail.dera.gov.uk (172.16.9.10) by baton.dera.gov.uk with SMTP; 24 Apr 2001 15:41:13 -0000 Received: by gauntlet.mail.dera.gov.uk; id PAA27960; Tue, 24 Apr 2001 15:37:54 GMT Received: from unknown(10.71.64.31) by gauntlet.mail.dera.gov.uk via smap (3.2) id xma027740; Tue, 24 Apr 01 15:37:05 GMT Received: from FRN-MAIL-3.dera.gov.uk (unverified) by mailguard.dera.gov.uk (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 24 Apr 2001 15:53:01 +0100 Received: by frn-mail-3.dera.gov.uk with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Apr 2001 15:45:56 +0100 Message-ID: <25649633ECEAD411AE9900508BCF86958ED33E@mal-mail-2.dera.gov.uk> From: Webber Neil To: "'MANET' (E-mail)" Subject: Old papers Date: Tue, 24 Apr 2001 15:45:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi all, In the early days of the group, were there any papers/studies into the mobility capabilities of OSPF and BGP? I'm especially interested in the weaknesses that crop up that MANET protocols are designed to cope with, and any accuracy/efficiency data that might be available. Regards Neil Neil C Webber Communications Dept. DERA Malvern -- The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. From owner-manet@itd.nrl.navy.mil Thu Apr 26 08:30:14 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00751 for ; Thu, 26 Apr 2001 08:30:14 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA14589 for manet-outgoing; Thu, 26 Apr 2001 05:31:24 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id FAA14584 for ; Thu, 26 Apr 2001 05:31:21 -0400 (EDT) From: Leping.Huang@nokia.com Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3Q9VRS02158 for ; Thu, 26 Apr 2001 12:31:28 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 26 Apr 2001 12:31:19 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Thu, 26 Apr 2001 12:31:19 +0300 Message-ID: <6468108794D6D311AB850008C72B5EA40468A658@toeis01nok> To: manet@itd.nrl.navy.mil Subject: ask for help Date: Thu, 26 Apr 2001 09:18:55 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-2022-jp" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, all: I am a newcomer in ad hoc networks. I am searching papers and discussions concering QoS control/scheduling in ad hoc networks. I have read some RFC of MANET, it seems most of the discussion is concentrated in routing algorithm. I think it must be already a hot topic in MANET, but i just go to the wrong place to search. Can u give me some information/help about where i can find discussions on QoS control in ad hoc networks. best regards leping@Nokia From owner-manet@itd.nrl.navy.mil Thu Apr 26 13:25:53 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13216 for ; Thu, 26 Apr 2001 13:25:51 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA21224 for manet-outgoing; Thu, 26 Apr 2001 10:38:45 -0400 (EDT) Received: from snail.ecs.umass.edu (snail.ecs.umass.edu [128.119.91.94]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA21219 for ; Thu, 26 Apr 2001 10:38:41 -0400 (EDT) Received: from cheer (ganz1.ecs.umass.edu [128.119.85.178]) by snail.ecs.umass.edu (8.11.2/8.11.2) with SMTP id f3QEcgI19173 for ; Thu, 26 Apr 2001 10:38:43 -0400 (EDT) Message-ID: <008701c0ce5e$c198acf0$56070707@cheer> From: "qi xue" To: References: <6468108794D6D311AB850008C72B5EA40468A658@toeis01nok> Subject: Time complexity of routing in manet? Date: Thu, 26 Apr 2001 10:39:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, Does any one knows where I can find some good papers about the complexity analysis of routing protocols in manet? e.g. AODV or DSR. Thanks! xq From owner-manet@itd.nrl.navy.mil Thu Apr 26 17:41:08 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23257 for ; Thu, 26 Apr 2001 17:41:08 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA27698 for manet-outgoing; Thu, 26 Apr 2001 14:03:46 -0400 (EDT) Received: from babbage.ececs.uc.edu (mail.ececs.uc.edu [129.137.8.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA27684 for ; Thu, 26 Apr 2001 14:03:43 -0400 (EDT) Received: from scorpio.ececs.uc.edu (scorpio.ececs.uc.edu [129.137.9.162]) by babbage.ececs.uc.edu (8.10.2/8.10.2) with ESMTP id f3QI3gw11562; Thu, 26 Apr 2001 14:03:45 -0400 (EDT) Received: from localhost (guptanis@localhost) by scorpio.ececs.uc.edu (8.9.3/8.9.1) with ESMTP id OAA11798; Thu, 26 Apr 2001 14:03:42 -0400 X-Authentication-Warning: scorpio.ececs.uc.edu: guptanis owned process doing -bs Date: Thu, 26 Apr 2001 14:03:42 -0400 (EDT) From: Nishant Gupta To: Leping.Huang@nokia.com cc: manet@itd.nrl.navy.mil Subject: Re: ask for help In-Reply-To: <6468108794D6D311AB850008C72B5EA40468A658@toeis01nok> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk hi leping There was a discussion on QoS in MANET on this list sometime in Feb. You can check out the archives to get the links of the papers on the same. Check out mails between 18-24 May. If you are not able to find them, i can forward them to you. I am working on QoS for MANETS and would welcome any question that you may have. Nishant On Thu, 26 Apr 2001 Leping.Huang@nokia.com wrote: > Hi, all: > > I am a newcomer in ad hoc networks. > > I am searching papers and discussions concering QoS control/scheduling in ad > hoc networks. > > I have read some RFC of MANET, it seems most of the discussion is > concentrated in routing algorithm. > > I think it must be already a hot topic in MANET, but i just go to the wrong > place to search. > > Can u give me some information/help about where i can find discussions on > QoS control in ad hoc networks. > > > best regards > > leping@Nokia > > > > -- Nishant Gupta http://www.ececs.uc.edu/~guptanis QOTD: "I've always wanted to work in the Federal Mint. And then go on strike. To make less money." From owner-manet@itd.nrl.navy.mil Thu Apr 26 17:48:59 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23398 for ; Thu, 26 Apr 2001 17:48:59 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA26861 for manet-outgoing; Thu, 26 Apr 2001 13:38:12 -0400 (EDT) Received: from babbage.ececs.uc.edu (mail.ececs.uc.edu [129.137.8.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA26850 for ; Thu, 26 Apr 2001 13:37:56 -0400 (EDT) Received: from scorpio.ececs.uc.edu (scorpio.ececs.uc.edu [129.137.9.162]) by babbage.ececs.uc.edu (8.10.2/8.10.2) with ESMTP id f3QHbrw10855; Thu, 26 Apr 2001 13:37:54 -0400 (EDT) Received: from localhost (guptanis@localhost) by scorpio.ececs.uc.edu (8.9.3/8.9.1) with ESMTP id NAA11762; Thu, 26 Apr 2001 13:37:53 -0400 X-Authentication-Warning: scorpio.ececs.uc.edu: guptanis owned process doing -bs Date: Thu, 26 Apr 2001 13:37:53 -0400 (EDT) From: Nishant Gupta To: Leping.Huang@nokia.com cc: manet@itd.nrl.navy.mil Subject: Re: ask for help In-Reply-To: <6468108794D6D311AB850008C72B5EA40468A658@toeis01nok> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk hi leping There was a discussion on QoS in MANET on this list sometime in Feb. You can check out the archives to get the links of the papers on the same. Check out mails between 18-24 May. If you are not able to find them, i can forward them to you. I am working on QoS for MANETS and would welcome any question that you may have. Nishant On Thu, 26 Apr 2001 Leping.Huang@nokia.com wrote: > Hi, all: > > I am a newcomer in ad hoc networks. > > I am searching papers and discussions concering QoS control/scheduling in ad > hoc networks. > > I have read some RFC of MANET, it seems most of the discussion is > concentrated in routing algorithm. > > I think it must be already a hot topic in MANET, but i just go to the wrong > place to search. > > Can u give me some information/help about where i can find discussions on > QoS control in ad hoc networks. > > > best regards > > leping@Nokia > > > > -- Nishant Gupta http://www.ececs.uc.edu/~guptanis From owner-manet@itd.nrl.navy.mil Fri Apr 27 02:09:22 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15311 for ; Fri, 27 Apr 2001 02:09:21 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id XAA09474 for manet-outgoing; Thu, 26 Apr 2001 23:04:09 -0400 (EDT) Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id XAA09469 for ; Thu, 26 Apr 2001 23:04:05 -0400 (EDT) Received: from ceskyw2k1 (soc-89-168.comp.nus.edu.sg [137.132.89.168]) by leonis.nus.edu.sg (8.10.0/8.10.0) with SMTP id f3R33qI00683; Fri, 27 Apr 2001 11:03:52 +0800 (SST) Message-ID: <00f301c0cec6$d6904740$a8598489@ceskyw2k1> Reply-To: "HE Jun" From: "HE Jun" To: "Nishant Gupta" Cc: References: Subject: Re: ask for help Date: Fri, 27 Apr 2001 11:04:55 +0800 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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Nishant : I'm also interesting in Qos in MANET. I searched the arvhives but couldn't find then links. Can you kindly mail them to me ? Thanks a lot He Jun ----- Original Message ----- From: "Nishant Gupta" To: Cc: Sent: Friday, April 27, 2001 2:03 AM Subject: Re: ask for help > hi leping > There was a discussion on QoS in MANET on this list sometime in Feb. You > can check out the archives to get the links of the papers on the > same. Check out mails between 18-24 May. If you are not able to find them, > i can forward them to you. > > I am working on QoS for MANETS and would welcome any question that you may > have. > > Nishant > > > On Thu, 26 Apr 2001 Leping.Huang@nokia.com wrote: > > > Hi, all: > > > > I am a newcomer in ad hoc networks. > > > > I am searching papers and discussions concering QoS control/scheduling in ad > > hoc networks. > > > > I have read some RFC of MANET, it seems most of the discussion is > > concentrated in routing algorithm. > > > > I think it must be already a hot topic in MANET, but i just go to the wrong > > place to search. > > > > Can u give me some information/help about where i can find discussions on > > QoS control in ad hoc networks. > > > > > > best regards > > > > leping@Nokia > > > > > > > > > > -- > Nishant Gupta > http://www.ececs.uc.edu/~guptanis > > QOTD: > "I've always wanted to work in the Federal Mint. And then go on > strike. To make less money." > From owner-manet@itd.nrl.navy.mil Fri Apr 27 09:05:47 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27390 for ; Fri, 27 Apr 2001 09:05:46 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA13320 for manet-outgoing; Fri, 27 Apr 2001 05:50:09 -0400 (EDT) Received: from cupidon.inria.fr (cupidon.inria.fr [128.93.5.23]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id FAA13315 for ; Fri, 27 Apr 2001 05:49:52 -0400 (EDT) Received: (qmail 19699 invoked by uid 11205); 27 Apr 2001 09:49:14 -0000 From: Laurent Viennot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15081.16538.402310.628937@cupidon.inria.fr> Date: Fri, 27 Apr 2001 11:49:14 +0200 (CEST) To: "qi xue" CC: manet@itd.nrl.navy.mil Subject: Time complexity of routing in manet? In-Reply-To: <008701c0ce5e$c198acf0$56070707@cheer> References: <6468108794D6D311AB850008C72B5EA40468A658@toeis01nok> <008701c0ce5e$c198acf0$56070707@cheer> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Reply-To: Laurent.Viennot@inria.fr Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit You can check http://www.inria.fr/rrrt/rr-3965.html for a first step toward analysis of overhead in manet protocols. laurent qi xue writes: > Hi all, > > Does any one knows where I can find some good papers about the complexity > analysis of routing protocols in manet? > e.g. AODV or DSR. > > Thanks! > > xq > From owner-manet@itd.nrl.navy.mil Fri Apr 27 15:55:46 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13888 for ; Fri, 27 Apr 2001 15:55:46 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA23976 for manet-outgoing; Fri, 27 Apr 2001 13:10:20 -0400 (EDT) Received: from web11507.mail.yahoo.com (web11507.mail.yahoo.com [216.136.172.39]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id NAA23968 for ; Fri, 27 Apr 2001 13:10:17 -0400 (EDT) Message-ID: <20010427171018.60319.qmail@web11507.mail.yahoo.com> Received: from [63.70.255.242] by web11507.mail.yahoo.com; Fri, 27 Apr 2001 10:10:18 PDT Date: Fri, 27 Apr 2001 10:10:18 -0700 (PDT) From: Phani Syam Yadavalli Subject: Re: ask for help To: manet@itd.nrl.navy.mil In-Reply-To: <00f301c0cec6$d6904740$a8598489@ceskyw2k1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Nishant can you please send it to me too? Thank you in advance. Phani --- HE Jun wrote: > Hi, Nishant : > > I'm also interesting in Qos in MANET. I searched the > arvhives but couldn't > find then links. Can you kindly mail them to me ? > > Thanks a lot > > He Jun > ----- Original Message ----- > From: "Nishant Gupta" > To: > Cc: > Sent: Friday, April 27, 2001 2:03 AM > Subject: Re: ask for help > > > > hi leping > > There was a discussion on QoS in MANET on this > list sometime in Feb. You > > can check out the archives to get the links of the > papers on the > > same. Check out mails between 18-24 May. If you > are not able to find them, > > i can forward them to you. > > > > I am working on QoS for MANETS and would welcome > any question that you may > > have. > > > > Nishant > > > > > > On Thu, 26 Apr 2001 Leping.Huang@nokia.com wrote: > > > > > Hi, all: > > > > > > I am a newcomer in ad hoc networks. > > > > > > I am searching papers and discussions concering > QoS control/scheduling > in ad > > > hoc networks. > > > > > > I have read some RFC of MANET, it seems most of > the discussion is > > > concentrated in routing algorithm. > > > > > > I think it must be already a hot topic in MANET, > but i just go to the > wrong > > > place to search. > > > > > > Can u give me some information/help about where > i can find discussions > on > > > QoS control in ad hoc networks. > > > > > > > > > best regards > > > > > > leping@Nokia > > > > > > > > > > > > > > > > -- > > Nishant Gupta > > http://www.ececs.uc.edu/~guptanis > > > > QOTD: > > "I've always wanted to work in the Federal Mint. > And then go on > > strike. To make less money." > > > __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-manet@itd.nrl.navy.mil Sat Apr 28 02:40:43 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11010 for ; Sat, 28 Apr 2001 02:40:43 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id XAA04374 for manet-outgoing; Fri, 27 Apr 2001 23:46:35 -0400 (EDT) Received: from babbage.ececs.uc.edu (ldap.ececs.uc.edu [129.137.8.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id XAA04369 for ; Fri, 27 Apr 2001 23:46:31 -0400 (EDT) Received: from scorpio.ececs.uc.edu (scorpio.ececs.uc.edu [129.137.9.162]) by babbage.ececs.uc.edu (8.10.2/8.10.2) with ESMTP id f3S3kTw17344; Fri, 27 Apr 2001 23:46:29 -0400 (EDT) Received: from localhost (guptanis@localhost) by scorpio.ececs.uc.edu (8.9.3/8.9.1) with ESMTP id XAA13850; Fri, 27 Apr 2001 23:46:29 -0400 X-Authentication-Warning: scorpio.ececs.uc.edu: guptanis owned process doing -bs Date: Fri, 27 Apr 2001 23:46:29 -0400 (EDT) From: Nishant Gupta To: amabdal@cs.com cc: manet@itd.nrl.navy.mil Subject: Re: QoS in Manet In-Reply-To: <359A5208.758F8752.001D7BBA@cs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi Many of you have asked for the papers so I have compiled a list of the papers that I have with me and posted it on my website. You can refer from there. I would appreciate if you could send me the soft copy or the URL if you have for one of the papers that I have on the list but don't have a soft copy for them. http://www.ececs.uc.edu/~guptanis/qos.htm nishant On Fri, 27 Apr 2001 amabdal@cs.com wrote: > Hi Nishant, > > I started working on QoS in MANET. Could you pls. tell me where I can find papers about this topic, or if they are available to you I would appreciate if you could E-mail them to me. > > Thanks, > Ahmed Abd El Al > -- Nishant Gupta http://www.ececs.uc.edu/~guptanis A Chicago salesman was about to check into a St. Louis hotel when he noticed a very charming woman staring admiringly at him. He walked over and spoke with her for a few minutes, then returned to the front desk, where they checked in as Mr. and Mrs. After a very pleasurable three-day stay, the man approached the front desk and told the clerk he was checking out. In a few minutes, he was handed a bill for $2500. "There must be some mistake," the salesman said. "I've been here for only three days." "Yes, sir," the clerk replied. "But your wife has been here a month and a half." From owner-manet@itd.nrl.navy.mil Mon Apr 30 06:48:13 2001 Received: from itd.nrl.navy.mil ([132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04136 for ; Mon, 30 Apr 2001 06:48:13 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id DAA22877 for manet-outgoing; Mon, 30 Apr 2001 03:26:59 -0400 (EDT) Received: from m018.com ([210.112.11.138]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id DAA22849 for ; Mon, 30 Apr 2001 03:23:33 -0400 (EDT) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 30 Apr 2001 16:11:15 +0900 Received: from itd.nrl.navy.mil ([132.250.83.3]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 17 Apr 2001 21:46:29 +0900 Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA04575 for manet-outgoing; Tue, 17 Apr 2001 06:34:33 -0400 (EDT) Received: from x86unx3.comp.nus.edu.sg (x86unx3.comp.nus.edu.sg [137.132.90.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id GAA04568 for ; Tue, 17 Apr 2001 06:33:57 -0400 (EDT) Received: from decunx.comp.nus.edu.sg (root@decunx-m.comp.nus.edu.sg [137.132.90.9]) by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with ESMTP id SAA29550 for ; Tue, 17 Apr 2001 18:35:36 +0800 (GMT-8) Received: from sun450-88.comp.nus.edu.sg (liqiming@sun450.comp.nus.edu.sg [137.132.88.4]) by decunx.comp.nus.edu.sg (8.8.5/8.8.5) with ESMTP id SAA04224 for ; Tue, 17 Apr 2001 18:33:51 +0800 (SST) Date: Tue, 17 Apr 2001 18:33:47 +0800 (GMT-8) From: Li Qiming To: MANET Subject: scenario generator Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi all. I have written a scenario generator for MANETs. The generator assumes that a scenario is specified by * a rectangular area, start and stop time; * groups of nodes, where each group may have a center; * the movement of each group is described by the mobility model for the center (if any) and the mobility model for group members relative to the center. The mobility models that have been implemented include random waypoint, pursuit and brownian motion. Nodes can accelerate. I would like to get a feel for the MANET community's interest in this scenario generator. The code is available at http://www.comp.nus.edu.sg/~liqiming/fyp/scengen/index.html The package includes three sample scenario files, as well as (a slightly modified) ad-hockey for viewing the generated Tcl files (which are input for NS-2). Please feel free to download the code and give it a spin. Your feedback (especially on whether and how I should develop the generator further) is most welcome. Regards, Qiming Li