Opened 7 years ago
Last modified 7 years ago
#26 new defect
Specification of optional features
Reported by: | charliep@… | Owned by: | charliep@… |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | aodvv2 | Version: | |
Severity: | Active WG Document | Keywords: | |
Cc: |
Description
(Thomas Clausen) Related to the above point, an awful lot of the document is optional, as exemplified by the below:
To avoid repeated failure of Route Discovery, an AODVv2 router (HandlingRtr) handling a RREP message SHOULD attempt to verify connectivity to the next upstream router towards AODVv2 router originating an RREQ message. This MAY be done by including the Acknowledgement Request (AckReq) message TLV (see Section 15.2) in the RREP. Any unicast packet will satisfy the Acknowledgement Request, for example an ICMP REPLY message. If the verification is not received within UNICAST_MESSAGE_SENT_TIMEOUT, HandlingRtr SHOULD put the upstream neighbor in the blacklist.
So I have a (2119-languague) "SHOULD" telling me to "attempt to verify connectivity". Then a (again, 2119-language) "MAY" suggesting to accomplish that by sending an AckReq?.
It's a MAY - therefore, I know (as it's 2119-language) that I do not have to do that, send that message. But I still SHOULD "attempt to verify connectivity", so how do I do that?
It's not clear what it means that any "unicast packet will satisfy the Acknowledgement Request" (which I decided to not send, as that was a MAY), nor is it clear how the routing process will get access to any such unicast packet (assuming, that is, that said unicast packet isn't destined for that process).
Also, I am apparently supposed to receive a "verification" before some timeout. Search as I may, I have not found anything indicating where that "verification" is generated, I see no messages defined to this effect, nor any processing allowing me to infer it.
... from section 8.2:
AODVv2 routers SHOULD monitor connectivity to adjacent routers along active routes. This monitoring can be accomplished by one or several mechanisms, including: o Neighborhood discovery [RFC6130] o Route timeout o Lower layer trigger that a link is broken o TCP timeouts o Promiscuous listening o Other monitoring mechanisms or heuristics If a next-hop AODVv2 router has become unreachable, RERR_Gen follows the procedures specified in Section 8.3.2.
So, I will implement this protocol using RFC6130, since I happen to have an implementation of RFC6130 around. My next-door-neighbor, Francois, also implements this protocol - but he doesn't have an RFC6130 implementation around, and therefore uses "route timeout". As Francois and I both are lazy, of course, we implement only one mechanism each (this is allowed, according to the text).
Change History (1)
comment:1 Changed 7 years ago by charliep@…
- Owner changed from draft-ietf-manet-aodvv2@… to charliep@…