Hello Lotte,
Thanks for expanding my writeup! I agree that MetricType could be
added, but for Unreachable Destination packet triggers (i.e., not RERRs
for broken links), the MetricType is likely to be unknown. If
MetricType is added, then additional text is needed. The main
motivation for RERR message suppression is exactly to avoid having a
stream of packets to an unreachable destination to trigger a reverse
stream of RERR messages, so we have to make sure that works.
A few suggestions:
RteMsg.Timeout
RERR.AdressList
* RteMsg.AddressList == RERR.AdressList
Hi Charlie, hi all,
Am 28.03.2016 um 05:32 schrieb Charlie Perkins <charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>>:
Hello Lotte and all,
I can't find any email with text for the RERR table. So here's some new text for that purpose.
As we discussed, it is not important for interoperability.
Add a new subsection in section 4:
The transmission of each RERR message should be recorded
in a conceptual table called the RECENT_RERR_MESSAGE table that includes
the following entries:
- time for deletion = current_time + RERR_AGELIMIT
- Unreachable Addresses
- The destination address: either PktSrc or LL-MANET-Routers
Entries in RECENT_RERR_MESSAGE table SHOULD be deleted after
their time for deletion.
Add this text at JWD's comment
A new RERR message MUST NOT be generated if it matches the
same destination and the Unreachable Addresses are a subset of the
Unreachable Addresses in an entry of the RECENT_RERR_MESSAGE table.
Thanks for the sketch, I’ve compiled it into the following sections:
4.7. Route Error (RERR) Table
Each sent RERR message SHOULD be recorded in a conceptual table
called the Route Error (RERR) Table. Each entry contains the
following information:
RteMsg.Timeout
The time after which the entry SHOULD be deleted.
RteMsg.AddressList
The AddressList of the RERR to be recorded.
RteMsg.PktSource:
The PktSource of the RERR to be recorded, if any.
RteMsg.MetricTypeList:
The MetricTypeList of the RERR to be recorded.
See section Section 6.9 for instructions on how to update the table.
6.9. Suppressing Redundant Route Error Messages using the Route Error
Table
In order to avoid flooding the network with RERR messages when a
stream of IP packets to an unreachable address arrives, an AODVv2
router SHOULD avoid creating duplicate messages by determining
whether an equivalent RERR has recently been sent. This is achieved
with the help of the Route Error Table (see Section 4.7).
To determine if a received RERR is redundant:
1. Search for an entry in the Route Error Table where:
* RteMsg.AddressList == RERR.AdressList
* RteMsg.PktSource == RERR.PktSource
* RteMsg.MetricTypeList == RERR.MetricTypeList
If a matching entry is found, no further processing is required
and the RERR SHOULD NOT be sent.
2. If no matching entry is found, a new entry with the following
properties is created:
* RteMsg.Timeout := CurrentTime + RERR_TIMEOUT
* RteMsg.AddressList == RERR.AdressList
* RteMsg.PktSource == RERR.PktSource
* RteMsg.MetricTypeList == RERR.MetricTypeList
and I’ve extended 7.4.1. RERR Generation with:
The RERR SHOULD NOT be generated if CONTROL_TRAFFIC_LIMIT has been
reached. If approaching the limit, the message should be sent if the
priorities in Section 6.5 allow it.
The RERR also SHOULD NOT be generated if it is a duplicate, as
determined by Section 6.9.
Some notes:
* should we check if a RERR about to be regenerated in 7.4.3. RERR Regeneration is a duplicate as well? I’m thinking yes, but as a SHOULD. (if you have control over the whole network and you know everyone’s checking they’re not sending streams of RERRs in the first place I guess you can skip this step..)
* I’ve renamed RERR_AGELIMIT to RERR_TIMEOUT because all our other timeouts are called SOMETHING_TIMEOUT
* same thing with the table name: adjusted it to our other naming conventions
* I’ve also added MetricTypeList as a field to be recorded
* any corrections on my grammar etc are very welcome! :D
Add a line to Table 2:
RERR_AGELIMIT | 3 seconds (or whatever you like)
Done. (I’ve used 3 seconds for now)
The full commit illustrating all changes can be found here: https://github.com/Lotterleben/AODVv2-Draft/commit/bbb7a78b8b16bccbe5b2ac3866203d30add32fb0
Regards,
Lotte
Regards,
Charlie P.
On 3/27/2016 6:38 PM, Stan Ratliff wrote:
Lotte,
On Sun, Mar 27, 2016 at 5:56 PM, Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi all,
iirc, our consensus is to get a new Draft out as soon as we can…
In order to get that done, I’ve got a few issues I feel
personally responsible for but I’ll need your help with, so I
thought I’d send a quick reminder since we’re all busy people
and E-mails get lost quickly:
1. Security Considerations TODOs:
There are still a lot of TODOs in our Security Considerations
(see
http://ietf.10.n7.nabble.com/attachment/488740/1/13.%20Security%20Considerations_v3.txt
). I put them there because I either couldn’t figure out the
answer myself, or because I wasn’t sure if my answer was good
enough. If you could have a look at them and send me any
proposals for update (or a yay/nay, for example concerning (- is
this sufficient? Am I overlooking a way to prevent this here?)
in 13.1.1 Denial of Service), that’d be super helpful.
I took a look at the link - BTW, you've done a super job of collecting all of this. I'll need some more time to read & study, but wanted you to know I'm looking at it.
2. Resolving all JWD!s:
The critical issues raised by Justin that I have not resolved
yet are:
/(How does one know which outgoing interface is the neighbor
associated with? This seems like a very LARGE missing piece of
required information JWD!)/
/(How is this done? There is no table with recently sent RERR
messages to check. There needs to be though. JWD!)/
/(AODVv2_INTERFACES isn’t defined before now it should be. Also
what does this configuration consist of? Also is the list empty
if there is only one interface? JWD!)/
These all depend on Text promised by Charlie– I think the first
one is part of a bigger discussion (the „is using MAC addresses
a good idea/super painful“ one, iirc), but we still need to
drill down on the Language that describes the *exact formatting*
of the InterfaceSet (which is currently held in the thread
„Definition for AODVv2_INTERFACES“). That would also resolve the
third issue.
Charlie, did you find the time to write said text yet? I f you
didn’t and won’t please say so, and in this case, does anybody
else have the time? I can try, but I’m not quite sure about the
quality I’ll be able to deliver, so somebody is going to have to
volunteer to proofread that stuff.
I'm in the same boat you are - I can give it a go, but I'm *sure* it will be sliced and diced on a proofreading...:-)
What does the editorial team think about getting a Google hangout setup for this week? I'd really like to see us post a draft version, with a list of items addressed (and items still to be addressed) when the IETF website opens back up on April 4. At least we're not talking about posting on April fools day... :-) (Honest, true story - if you'll go browse http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PTXT&s1=7,353,261.PN.&OS=PN/7,353,261&RS=PN/7,353,261 , you'll see that the U.S. Patent office does *NOT* take the day off issuing patents on April Fool's day.... it kinda puts a sting into something that should be an achievement for a software engineer...) ;-)
Regards,
Stan
Best regards,
Lotte
