[aodvv2-discuss] Re: [manet] AODVv2 comments
- From: Stan Ratliff <ratliffstan@xxxxxxxxx>
- To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
- Date: Wed, 25 Mar 2015 08:35:32 -0500
Vicky,
+1
Regards,
Stan
Sent from my iPhone
> On Mar 25, 2015, at 6:21 AM, Victoria Mercieca <vmercieca0@xxxxxxxxx> wrote:
>
> Hi all,
>
> A couple of comments based on Justin Dean's points:
>
> On bidirectional connectivity:
>
> I think we aren't helping ourselves by starting section 6.2 with stuff about
> adjacencies and NHDP. I think we should cut this bit:
> "Neighboring routers MAY form an adjacency based on AODVv2 messages,
> other protocols (e.g. NDP [RFC4861] or NHDP [RFC6130]), or manual
> configuration. Loss of a routing adjacency may also be indicated
> similarly."
> and maybe insert it later in the section, though I dont think it's necessary,
> except for the references. Also remove
> "In the absence of other information
> about bidirectional connectivity"
> because I think its leading people to think that if they have NHDP they dont
> need to use our default AckReq approach, which leads to their comments "what
> if I do it this way and someone else does it another way".
>
> We need it to be clear that they use AckReq, unless something else has given
> them a signal. The way the section is written, its "unless you get
> information from somewhere else, you use AckReq" which is a subtle
> difference, but I think it's causing the confusion.
>
> Suggested text for first paragraph in Section 6.2:
> "AODVv2 routers SHOULD monitor connectivity to neighboring AODVv2 routers
> along active routes. If bidirectional connectivity does not exist, routers
> should not share routing information using AODVv2. The default approach for
> AODVv2 routers to monitor connectivity is to request acknowledgement of Route
> Reply messages. To achieve this, the RREP message includes an AckReq data
> element, to indicate that a RREP_Ack message is required in response. The
> receiver of the RREP will reply with a RREP_Ack message. Receipt of the
> acknowledgement proves that bidirectional connectivity exists. See Sections
> 9.2 and 9.4 for further details.
>
> Additionally, when routers perform other operations such as those from the
> list below, these can be used as extra indications of connectivity."
>
> Also, the bit that says
> "For example, receipt of a Neighborhood Discovery message would signal
> a connection to the sender. "
> Should it be clarified like this:
> "For example, receipt of a Neighborhood Discovery HELLO message with the
> receiving router listed as a neighbour is a signal of bidirectional
> connectivity." Connectivity isn't enough, we want bidirectional, and a
> message on its own is not a signal of bidirectional connectivity.
>
>
> On the message reception and "only from neighbors":
>
> Check 9.1.2 for RREQ. Is it correct to say "only from neighbours" there? Step
> 2 checks the blacklist. I think we can delete Step 1.
> 9.3.2 for RERR - we always process RERR even if it comes from a blacklisted
> router. Is that correct?
> 9.4.2 for RREP_Ack - should we always remove from the blacklist, even if we
> didnt request the RREP_Ack? If a router was to send an unsolicited RREP_Ack
> they could force removal of themselves from our blacklist. Should step 1 and
> 2 be the other way around?
>
> Regards,
> Vicky.
>
>> On Wed, Mar 25, 2015 at 2:46 AM, Charlie Perkins
>> <charles.perkins@xxxxxxxxxxxxx> wrote:
>> Hello Justin,
>>
>> Thanks for your comments. Here is some follow-up.
>>
>>> On 3/24/2015 12:32 PM, Justin Dean wrote:
>>> Overview: There are uses of unicast and multicast which (I don't think) are
>>> correct. The flow of information and messages might be similar to unicast
>>> and multicast but I believe that there is processing happening at each hop
>>> based on the flow of information. Disseminated throughout and forwarded
>>> would be more appropriate IMO.
>>
>> The use of the word "multicast" can properly be replaced by "disseminated".
>> However, the RREP is indeed unicast towards OrigAddr. The description makes
>> it clear that the message is regenerated at each hop.
>>
>>>
>>> Route maintenance consists of two operations.....(It's not clear what they
>>> are)
>>
>> Route maintenance consists of two operations: continuously
>> extending the lifetime of active routes, and invalidating
>> routes that cannot be used to forward packets.
>>>
>>> It's also a bit verbose for an overview, for example
>>>
>>> When a data packet is received to be forwarded
>>> but there is no valid route for the destination, then the AODVv2
>>> router of the source of the packet is notified via a Route Error
>>> (RERR) message. Each upstream router that receives the RERR marks
>>> the route as Invalid. Before such an upstream AODVv2 router could
>>> forward a packet to the same destination, it would have to perform
>>> route discovery again for that destination. RERR messages are also
>>> When a data packet is received to be forwarded, and no valid route exists,
>>> a error message is generated to inform upstream routers of the error. Route
>>> discovery would re-establish the route.
>>
>> I basically used your wording but included the idea that the RERR message
>> is used for this.
>>
>>
>>> (I'm jumping around a bit now) Bi-directional requirement and text in
>>> document isn't IMO sufficient (there are too many "optional" ways without
>>> guidance on how to configure them and what happens if things are miss
>>> configured.
>>
>> Mainly what goes wrong from the AODVv2 point of view is that RREQs
>> can get forwarded in circumstances that would never allow a RREP to be
>> returned to the router originating the RREQ. The AckReq / RREP_Ack
>> mechanism just has to protect against that.
>>
>>> What happens if I'm using AODVv2 with NHDP for neighbor
>>> discovery but another version is using the AckReq method.
>>
>> AckReq and RREP_Ack are mandated for implementation. We wanted to
>> allow for NHDP to be used if available. What's the best way to say that
>> without requiring NHDP for every implementation of AODVv2?
>>
>>> Do things
>>> break? I think they do based on 9.2.2 RREP Reception step "1. A router
>>> MUST handle RREPs only from neighbors. RREPs from nodes that are not
>>> neighbors MUST be disregarded." You won't be my neighbor via NHDP so
>>> I disregard it...Actually I don't see how AckReq method would work at
>>> all with this first step.
>>
>> Step 1 should simply be deleted. If a node is receiving
>> a RREP, the sender thinks it's a neighbor. The AckReq in the RREP would be
>> for the purpose of verifying bidirectional connectivity to the sender.
>>
>>> The change might be as easy as formally defining
>>> neighbor (i.e. an AODVv2 router without an address not on the blacklist
>>> from which a message was received), but I could be wrong...I'm wrong
>>> 9.4.2 RREP_Ack Reception has the same first step so if the address is in
>>> the blacklist it would get dropped before removing itself from the blacklist
>>> (if that definition was used).
>>
>> Similarly, step one in 9.4.2 can simply be deleted. There is no
>> specification
>> for regeneration of RREP_Ack, so compliant devices would not do such a
>> bad thing. Plus, RREP_Ack is generated with msg_hop_limit := 1.
>>
>> These verification steps would make more sense when RFC 5082 can be
>> employed.
>>
>>
>>> Another functionality issue with RREP_Ack method... Step 3. ..."the
>>> required RREP_Ack has been received (how is it known it's required nothing
>>> was recorded in the generation section on which Acks were requested in
>>> section RREP_Ack Generation) and cancels the associated timeout." (which
>>> timeout? assuming RREP_Ack_SENT_TIMEOUT but it should be specified) Also
>>> the neighbor gets added to the blacklist but won't the previous hops still
>>> have invalid upstream routes to the source?
>>
>> Section 9.2.1 has the following specification:
>> The AckReq data element indicates that an acknowledgement to the RREP
>> has been requested. If no corresponding RREP_Ack is received within
>> the RREP_Ack_SENT_TIMEOUT, the next hop is added to the blacklist as
>> discussed in Section 6.2.
>>
>> I will add some text to Step 3 cross-referencing this requirement:
>> " , in response to an AckReq data element that the
>> router included in a preceding RREP message as specified in Section
>> 9.2.1"
>>
>> This should clarify the need.
>>
>>
>>> 4. Applicability Statement
>>> "each AODVv2 router can also route on behalf of other non-routing nodes
>>> that are directly reachable via its network interfaces."
>>> and
>>> "When AODVv2 is
>>> the only protocol interacting with the forwarding table, AODVv2 MAY
>>> be configured to perform route discovery for all unknown unicast
>>> destinations."
>>> Means that all "gateway routers" will reply for EACH address request. Is
>>> my guess correct?
>>
>> Yes, that is correct. I added text for your observation.
>>
>>> Also how does the "Router Client and Client Networks" know where the AODVv2
>>> router addresses are reachable via the AODV router. I assume this has to be
>>> manually configured with a set of "known" aodv addresses or some sort of
>>> route injection.
>>
>> In the previous paragraph, it is stated:
>> Each AODVv2 router,
>> if serving router clients other than itself, SHOULD be configured with
>> information about the IP addresses of its clients, using any suitable
>> method.
>>
>> Doesn't this say what you requested?
>>
>>
>> Regards,
>> Charlie P.
>>
>> _______________________________________________
>> manet mailing list
>> manet@xxxxxxxx
>> https://www.ietf.org/mailman/listinfo/manet
>
Other related posts:
