... errr... I don't know how that '?' got into the subject line, sorry
about that ...
Regards,
Charlie P.
On 6/9/2015 3:45 PM, Charlie Perkins wrote:
Hello folks,
Justin makes some good comments about the gateway operation. I think
we can refine these points for inclusion in the next version of the draft.
However, prohibiting the gateway from responding to RREQ would often
be problematic, especially if the gateway is the single point of commonality
between multiple otherwise disjoint subnetworks. I think this will be a
common topology, so we have to be careful about it. Even in less constrained
topologies, the gateway would often be a node along the shortest path
between two endpoints.
Also, we can specify good things that happen when gateways know all
about the ad hoc network, but this isn't always the case. The mechanism
by which the gateway might acquire the knowledge would be at issue.
This was another matter discussed in autoconf.
More later...
Regards,
Charlie P.
-------- Forwarded Message --------
Subject: Re: Comments about AODVv2 gateways?
Date: Tue, 9 Jun 2015 16:47:46 -0400
From: Justin Dean <bebemaster@xxxxxxxxx>
To: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
CC: Stan Ratliff <ratliffstan@xxxxxxxxx>
Reading the current 09 draft the only text regarding gateways is...
" AODVv2 can be configured to perform gateway functions when attached
to the internet. Such gateway routers will reply to each route
request generated inside the AODVv2 network as if they were
responsible for the target address, and may advertise the AODVv2
network to the internet using procedures out of scope for this
specification."
It doesn't actually specify HOW a gateway can be configured. I see two problems with the outline of the approach written here (replying to all route requests) First is that it's grossly inefficient as all gateways will end up replying to every new ip address an AODVv2 router wants to communicate with which also causes a manet network wide route request flood. The second problem is that it's broken as written as gateway nodes will in many cases subvert routes to internal MANET addresses with a reply with a better network. What's really needed is a network route that doesn't break how adovv2 works. That would take some work (I'll outline how I'd go about it) but there might be a way to "fix" the broken way described now and kick the can about how to do good gateway support later.
First gateway nodes MAY reply to route requests (not must), and SHOULD NOT reply to route requests if the route requested is known internal to the manet network. Furthermore gateway route replies should be marked as such in the route reply so that the routers know when to use the longer "worse" metric route to the true node and not the "gateway" route. This should be outlined in a section regarding generation of route replies in response to attached network routes (in gateway mode). There should also be text about how inefficient this is. There should also be a tlv in a route request message which proactivly allows for gateway nodes to reply. This would help limit the number of gateway replies and allow for better future expansion.
The longer better version: Gateway nodes would conceivably know which set of addresses are in the AODVv2 network. MANET as a stub network for example. Route replies generated by these gateway nodes in response to a matching network route would be with a network route not a single host route. There is a problem with this though in that default routes will match all addresses and all traffic will just be sent to the gateway node regardless if its internal to the MANET network or external. The fix for this is to add a "hole" network route which would trigger an AODVv2 route request. This "hole" would be included when appropriate (i.e. internet connected gateway nodes) in the route reply message. An example. I request 192.168.1.10. Gateway replies with default network route 0.0.0.0/0 <http://0.0.0.0/0>, and "hole" network route 192.168.1.0/255.255.255.0 <http://192.168.1.0/255.255.255.0>. I add the gateway route with the appropriate next hop and add the "hole" route with a next hop of loopback or some other virtual AODVv2 interface. Packets matching the 192.168.1.0/24 <http://192.168.1.0/24> will be sent to that interface and a normal AODVv2 route request can happen. Packets not matching that "hole" network route will be sent to the default gateway route without any further signaling. If the route request tlv to allow gateway replies is implimented then gateways would only have to reply if/when a router was requesting gateway replies, meaning this exchange would only have to happen once.
On Mon, Jun 8, 2015 at 1:18 PM, Charlie Perkins <charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello Justin,
If you have comments about what we should do to improve the
description of how AODVv2 handles gateways, please let us know
soon so that we can formulate resolutions to address your comments.
Regards,
Charlie P.
