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.