Hello folks,
I also do not think that the AODVv2 draft should specify the IAR as a
default router. This can be done at a later time, by mechanisms not
specific to AODVv2.
For convenience, I append my earlier discussion with various bits of
rationale for resolving the remaining gateway issues that I was aware of.
The main points are:
- The gateway is NOT specified to be default router
- The interface to the Internet is *not* an element of the
AODVv2_INTERFACES list (so the gateway won't put AODVv2 messages on it)
The second sentence needs to be added to section 9. With these
restrictions, I believe multiple gateways also work as expected, and do
not require additional specification.
The gateway responds to RREQs as usual, either as a specific
destination, or as a router for the Internet. We have to decide what to
use for hop count to the Internet. (hop_count == 1) is a realistic
possibility. If the gateway has more specific information about hop
count to Internet destinations, it can use it.
Regards,
Charlie P.
-------- Forwarded Message --------
Subject: Re: Comments about AODVv2 gateways?
Date: Fri, 19 Jun 2015 11:44:13 -0700
From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
To: aodvv2-discuss@xxxxxxxxxxxxx <aodvv2-discuss@xxxxxxxxxxxxx>
CC: Justin Dean <bebemaster@xxxxxxxxx>
Hello Justin and all,
Follow-up about gateways... Notably, it's an issue that has generated a
great deal of discussion in the past, but as best I can tell a lot of
that previous discussion should not apply to the existing base
specification.
This discussion is under the assumption that the IAR (Internet AODVv2
Router) [below, called the "gateway"] is *not* configured to be a
default router for nodes within the MANET.
I will send another email to discuss that case. But first, I hope we
can agree that we don't have to solve that problem in order to get to
Last Call.
On 6/9/2015 1:47 PM, Justin Dean wrote:
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."
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.
