Hi all,
I finally found some time to go through everything marked with a JWD TODO
from Lotte's email on 4th April. I know there have already been some
comments, so I apologise if I am re-iterating things that have already been
updated!
I've listed all the TODOs I found (although there's a couple I haven't
commented on).
Here goes.....
*Valid route A route that can be used for forwarding. (the deleted
part should be defined in Route Error Generation section JWD TODO: why
there? If you hink it's a bit too verbose at that place, Local Route Set
{#rte} has an in-depth definition what a valid route is and isn't )*
I agree, the extra explanation doesn't need to go here. The deleted bit was:
which has been confirmed as having a bidirectional link to the next hop,
and has not timed out or been made invalid by a route error.
"Local Route Set" is the right place for this information, and the
explanation already there is fine. I vote to remove this bit from the
Terminology, and not insert anywhere else. If the reader wants extra info,
maybe include a reference to "Local Route Set" section with the terminology
entries for Valid route and Invalid route, e.g. "Further information can be
found in Section __".
*---*
*Unreachable Address*
* An address reported in a Route Error message. (the deleted part
should be defined in Route Error Generation section JWD TODO)*
The deleted part was:
either the address on a LocalRoute which became Invalid, or the destination
address of an IP packet that could not be forwarded because a valid
LocalRoute to the destination is not known, and will not be requested.
I think this got added based on some previous comments, but I agree it is
unnecessary in Terminology. I think the RERR Generation section is already
pretty clear on what to use for "unreachable address" and all the
circumstances involved. I vote to remove the bit Justin suggested, and not
insert it anywhere else.
---
*3. Applicability Statement*
*(Wireless properties of the network is not mentioned at all and this is
quite important as I’m pretty sure AODVv2 for used in a wired network would
be a bad idea JWD TODO)*
How about changing the first sentence from:
The AODVv2 routing protocol is a reactive routing protocol.
to:
The AODVv2 routing protocol is a reactive routing protocol intended for use
in mobile ad hoc wireless networks.
---
* AODVv2 is designed for stub or disconnected mobile ad hoc networks, i.e.,
non-transit networks or those not connected to the internet. AODVv2 can,
however, be configured to perform gateway functions when attached to
external networks, as discussed in Section 9. (some mention of limitations
of the provided approach is required. No default gateways,
drawbacks/overhead of using AODVv2 network to connect to the Internet using
provided approach JWD TODO)*
---
*AODVv2 provides for message integrity and security against replay attacks
by using integrity check values, timestamps and sequence numbers, as
described in Section 13. If security associations can be established,
encryption can be used for AODVv2 messages to ensure that only trusted
routers participate in routing operations.*
*(There is an issue with trust being limited to single hops and no way to
verify information more than one hop away JWD TODO)*
Ongoing discussion.
---
*AODVv2 supports routers with multiple interfaces and multiple IP addresses
per interface. (this should be disallowed as it can form non valid routes
with uni-directional links JWD TODO) *
I think that it can form non-valid routes with unidirectional links, **if**
multiple interfaces use the same IP address (and I think we included an
interface identifier and some rules about which interface a message should
be sent on, to get around this issue). I think our statement is now valid.
---
*4.2. Router Client Table*
*What’s the difference between a table and a list why are we using one over
the other?JWD TODO)*
Are we renaming as much as possible to be Sets? This could easily be Router
Client Set. Also we have InterfaceSet, we could have Neighbor Set, we have
Local Route Set, can change to Multicast Route Message Set and RERR Set.
---
*5. Metrics: (consider adding a maximum single hop value JWD TODO)*
What was the consensus on this, before the discussion erupted into a number
of metric issues? It would exclude poor links from route discovery,
potentially with route discovery failing even though a route did exist. I
vote not to have a maximum single hop value, i.e. no maximum link cost.
---
*6.3. Neighbor Table Update*
*If an RREP_Ack is not received within the expected time (what is the
expected time? list the entry we are checking assuming in the Multicast
Route Message Tablet? outline it. JWD TODO: The MRMT is not the right
place, but I'm nt sure if we're descrivng timers for this anywhere? shoud
we?)*
Version 14 now says: "within RREP_Ack_SENT_TIMEOUT" but doesn't refer to
how we know this time is up. The RREP we are expecting to be acked would be
in the MRMT, wouldnt it, since it would have been multicast? So we would be
testing "If an RREP_Ack is not received in response to a multicast RREP,
within RREP_Ack_SENT_TIMEOUT of the time the RREP was sent," and if we need
to be more explicit "within RREP_Ack_SENT_TIMEOUT of the Timestamp of the
Multicast Route Message Entry corresponding to the RREP,"... but that is
hideously wordy.
Also I guess we need to state that there should be a timer running, so that
when it expires we can set the neighbor as blacklisted. Do timers need
their own list? That's too implementation specific, surely?
---
*When a link to a neighbor is determined to be broken, the NeighborTable
entry SHOULD be removed.(What does this mean? How would one determine a
link to a neighbor to be broken….suggest removing it JWD TODO)*
I guess this is an external signal. Do we remove this statement, or expand
it further? e.g. "If a link to a neighbor is determined to be broken
according to a signal from an external process..." I think its useful to
indicate when an entry would be deleted. Otherwise, do we keep the entry
forever, in case the link ever becomes bidirectional?
---
*Lowest priority SHOULD be given to RERR messages generated in response to
RREP messages which cannot be regenerated. In this case the route request
will be retried at a later point.*
*(It’s not clear to me how this priority works. Do the messages just get
dropped when tsome threshold for max number of messages is reached? Is
there some queuing method because if their isn’t I don’t see how priority
would work at all, as the choices are drop or send. This whole section
seems out of place as we have’t talked about generating messages. I’d
suggest moving or removing JWD DONE partially ([master e9927a8] redo
priority definition))*
Did we decide that when we hit a certain limit, we then remove queued
messages of lower priorities, so that we can instead queue messages of
higher priorities? And if the queue is full of higher priority messages,
drop (or avoid creation of) any new messages?
e.g. some suggested text ready for comments/criticisms.
"To implement the congestion control, a queue length is set. If the queue
is full, in order to queue a new message, a message of lower priority must
be removed from the queue. If this is not possible, the new message MUST be
discarded. The queue should be sorted in order of message priority."
Or is there a less "this is how you MUST implement it" sort of statement we
could use instead like "its up to an implentor to decide if and how to do
this?"
---
*RREQ_Gen awaits reception of a Route Reply message (RREP) containing a
route toward TargAddr. (is there some table that lists routes that are
being waited on? JWD TODO) *
Is it enough that the RREQ message will still be in the MRMT?
Is it better to slightly re-write, maybe like this: "RREQ_Gen awaits
reception of a Route Reply message (RREP) corresponding to the RREQ. This
RREP contains a route toward TargAddr, which is installed at RREQ_Gen,
completing the route discovery procedure."
Similar to above...do we need to state explicitly that there should be a
timer running, so that when it expires we can retry the route discovery? Do
timers need their own list? That's too implementation specific, surely?
---
*7.1.3. RREQ Regeneration*
*There might be a problem with very short validity times on very low metric
routes in that they will be selected regardless of the time. Not a problem
but something that could cause issues. Perhaps some minimum time should be
mandated. JWD TODO)*
I'm happy either way. I think Charlie mentioned it in a recent email too.
If we mandate a minimum time, what should it be? This then needs to be
mentioned throughout the draft in multiple generation/regeneration
sections, stating that the message should not be regenerated if the
validity time is less than the minimum.
---
*7.1.1. RREQ Generation*
*and all generation/regeneration sections*
* If the limit for the rate of AODVv2 control message generation has*
* been reached, no message SHOULD be generated. If approaching the*
* limit, the message should be sent if the priorities in Section 6.5*
* allow it.*
*(There is no defined behavior here. Approaching the limit? Section 6.5
outlines which messages are more important but now how to decide to allow
them to be transmitted or not. JWD TODO)*
Fixed as above?
---
*7.2.3. RREP Regeneration*
*The router MAY choose not to regenerate the RREP, in the same way it MAY
choose not to regenerate an RREQ (see Section 7.1.3), though this could
decrease connectivity in the network or result in non-optimal paths.*
*(This seems like a bad idea to do on the reverse path. It would be a good
way to attack a network Forward RREQ and drop all RREP. JWD DONE?)*
If there is a router which doesnt forward a RREP, but does send back an Ack
toward TargAddr, then the next hop router would not blacklist this router.
And the RREP doesnt reach RREQ_Gen, so a new RREQ will go out and the same
will happen again. RREQ_Gen will eventually give up.
If we state that a router which doesnt forward a message must not send
acknowledgements, and that if you forward a RREQ you MUST forward a
corresponding RREP, that fixes it, right? Except for if you have reached
your congestion limit in between these two events? But then something crazy
is going on anyway. Hopefully on the retry the congestion has reduced? Or,
on the retry the RREQ probably wouldnt be forwarded by this router,
therefore would discover another path.
I think I agree with Justin. If we receive a RREP it pretty much means we
sent the RREQ, so we should do our best to regenerate the RREP. Let's not
allow "The router MAY choose not to regenerate the RREP"....
---
*7.2.3. RREP Regeneration*
* 4. If the link to the next hop router toward OrigAddr is not known*
* to be bidirectional, include the AckReq with the address of the*
* intended next hop router*
*(THere needs to be some sort of table which is updated with timer
associated with this AckReq JWD TODO)*
In this case the RREP was multicast, so should be in the MRMT, along with a
timestamp.
Same as above...do we need to state explicitly that there should be a timer
running, so that when it expires we can set the neighbor as blacklisted? Do
timers need their own list? That's too implementation specific, surely?
---
*7.3.2. RREP_Ack Reception*
* Upon receiving an RREP_Ack, an AODVv2 router performs the following*
* steps:*
* 1. Update the Neighbor Table according to Section 6.3*
* * If the sender has Neighbor.State set to Blacklisted after
the** update,
ignore this RREQ for further processing.*
*(Shouldn’t this check come before updating? The only way the
Neighbor.State is set to Blacklisted is that its already Blacklisted and
there is no need to update the Neighbor Table. JWD TODO)*
I think 6.3 says whether to update the state from blacklisted (if the reset
time has been reached). Because otherwise we didnt specifically mandate a
timer which updates that entry to stop the neighbour being blacklisted. The
fact that the neighbor *remains* blacklisted after checking the reset time,
that is what's important in step 1.
---
*8.1.2. Message TLV Block*
and all other message TLV block sections
* An RREQ contains no Message TLVs.*
*(this ins’t mandatory, right? Just AODVv2 doesn’t define any message TLVs
for use with RREQ JWD TODO?)*
Did we suggest updating to something like "This draft specifies/requires no
Message TLVs for this message type"?
---
*8.3.3. Address Block*
* An RREP_Ack contains no Address Block.*
*(Mandatory or just not defined? Guessing mandatory on this one. JWD TODO)*
Any address block would be ignored by the current draft. Again something
like "This draft requires no Address Block for this message type"?
Same for the Address Block TLV Block for the RREP_Ack.
---
* When a LocalRoute is expunged, any precursor list associated with it** MUST
also be expunged.*
*(I feel like this is underspecified and would be better served in a
separate document like Intermediate RREP. Is there anything wrong with
leaving the behavior required a MAY and describing that behavior in another
draft? JWD TODO)*
Are we ok to remove extensions to future separate drafts?
To enable precursor lists, maybe we need something in RERR
generation/regeneration sections to state that a RERR "SHOULD" be
multicast, rather than MUST (for the RERR without PktSource). This allows
other ways of sending the RERR (such as unicast to specific precursors),
according to RFC 2119's meaning of SHOULD, I think?
To enable expanding rings multicast we either need to reintroduce
msg-hop-limit and msg-hop-count, or define a new hop_count TLV. Then I
think where we have statements like "MAY decide not to regenerate the
RREQ", this covers the use of expanding rings multicast as an extension.
For iRREP, we already have an extension draft. I'm hazy on the details, is
there anything we need to state in our draft to allow this extension?
For message aggregation delay, that's a 5444 option. That's probably
something we would configure in whatever multiplexer we might use. Not sure
its worth writing an extension for AODVv2 for that.
---
*(is MAX_SEQNUM_LIFETIME the only parameter which MUST be configured the
same across the network? JWD TODO: yes?)*
Other timers are active interval, max idletime, max blacklist time, rtemsg
entry time, rreq wait time, rrep ack sent timeout and rreq holddown time.
I'd say ACTIVE_INTERVAL and MAX_IDLETIME should be configured the same
across the network too...just because if they affect one hop in an
established route, they affect all hops.
Charlie wrote the bit about what happens if constants are different on
different routers, I think this got pasted from there (11.2). Should we do
the same for timers? Seems like common sense really:
- Routers with lower values for ACTIVE_INTERVAL + MAX_IDLETIME will
invalidate routes more quickly and free resources used to maintain them.
This can affect bursty traffic flows which have quiet periods longer than
ACTIVE_INTERVAL + MAX_IDLETIME. A route which has timed out due to
perceived inactivity is not reported. When the bursty traffic resumes, it
would cause a RERR to be generated, and the traffic itself would be
dropped. This route would be removed from all upstream routers, even if
those upstream routers had larger ACTIVE_INTERVAL or MAX_IDLETIME values. A
new route discovery would be required to re-establish the route, causing
extra routing protocol traffic and disturbance to the bursty traffic.
- Routers with lower values for MAX_BLACKLIST_TIME would allow neighboring
routers to participate in route discovery sooner than routers with higher
values. This could result in failed route discoveries if un-blacklisted
links are still uni-directional. Since RREQs are retried, this would not
affect success of route discovery unless this value was so small as to
un-blacklist the router before the RREQ is retried. This value need not be
consistent across the network since it is used for maintaining a 1-hop
blacklist. However it MUST be greater than RREQ_WAIT_TIME.
*[and probably a good idea to be at least a multiple of RREQ_WAIT_TIME?]*
- Routers with lower values for RERR_TIMEOUT may create more RERR messages
than routers with higher values. This value should be large enough that a
RERR will reach all routers using the route reported within it before the
timer expires, so that no further data traffic will arrive, and no
duplicated RERR messages will be generated.
- Routers with lower values for RteMsg_ENTRY_TIME may not consider received
redundant multicast route messages as redundant, and may regenerate these
messages unnecessarily.
- Routers with lower values for RREQ_WAIT_TIME may send more frequent RREQ
messages and wrongly determine that a route does not exist, if the delay in
receiving an RREP is greater than this interval.
- Routers with lower values for RREP_Ack_SENT_TIMEOUT may wrongly determine
links to neighbors to be unidirectional if an RREP_Ack is delayed longer
than this timeout.
- Routers with lower values for RREQ_HOLDDOWN_TIME will retry failed route
discoveries sooner than routers with higher values. This may be an
advantage if the network topology is frequently changing, or may
unnecessarily cause more routing protocol traffic.
---
o RREP_RETRIES: Routers with lower values are more likely to
blacklist neighbors when there is a
Um... where did the rest of this sentence go? Must be my fault! Draft 11
says this:
RREP_RETRIES: Nodes with lower values are more likely to blacklist
neighbors when there is a temporary fluctuation in link quality.
---
Now for the RFC5444 usage draft...!
Kind regards,
Vicky.
