[manet] OLSRv2 router restart

[Christopher Dearlove <[e-mail]>]

I would start with the principle that we don’t want to change OLSRv2, create incompatibilities etc. unless we actually have to. And I don’t think we need to.

So what we should start with is advice to restarting routers. Can we solve all our problems that way?

Before addressing that, you might say, what about the case of routers that restart but don’t follow advice, can they mess us up? Possibly (though I think it needs a matching ANSN, not just an expired one). But that’s the nature of OLSRv2 and similar protocols, a poorly behaving router can always mess you up. Worse if it is malicious, but that’s a different problem.

And let’s supposed we managed to come up with a set of really good rules for restarting routers. What to do with them.  Could be an informational RFC, advice on restarting a router. Or a standards track RFC, what you should and what you must do on restarting a router. I could see either. Or a non-RFC approach.

But that’s getting ahead. What advice could we give?

First, if the router remembers its old MSN and ANSN (and if necessary, PSN) there’s no problem. (Obviously you’d include this in an RFC/whatever but it’s a trivial case.)

The second trivial case is that you just wait longer than your data will take to timeout. Often the easiest solution. But if you might have been using long timeouts, might be a problem. Or if you want rapid readmission. But that needs other routers to also act rapidly, and might not be an option.

So let’s assume you want back in, have no idea of your old MSN/ANSN, and there might be data out there that needs replacing, and you can’t just wait.

Handling two sequence numbers (MSN/ANSN) together would be tricky. But fortunately we can do these one at a time. Because to get back in, first we need HELLO exchange (NHDP). That only uses MSN. So first we fix MSN, then we move on to ANSN. (Until we’ve exchanged HELLOs, no one will forward our TC messages.)

So pick a random MSN. If we pick badly, we will be ignored. We could wait, see if we are ignored, if we are, move on. (We might be ignored because messages are lost. I’ll ignore that for now. You might want to send messages more than once before moving on to handle that.)

But maybe we would rather not wait that long. So here’s an approach I think works. Haven’t been able to test it - my former employer has my OLSRv2 code unfortunately and won’t let me have it - but that’s the point of discussion.

So we pick three or four equispaced (or roughly so) numbers. Two won’t work, the case of separation by exactly N/2 is unreliable, where N is 2^16. (The version in OLSRv1 is specified but has strange consequences, so we left it unspecified in OLSRv2.). Four is easiest (0, N/4, N/2, 3N/4).

So we send a HELLO (or more than one) with one of those MSNs. Then, without needing to wait, do the same for the rest of the numbers in order. At first we might be ignored, but at some point we will get past the last one we used. Then we will start overriding ourselves. And the last one we send will be accepted. (We can stop early if we get a response, that tells us we have an MSN we can use.)

Is that ugly? Yes. But we are trying to solve the problem of having no information and not being prepared to wait. There are more efficient solutions if we modify OLSRv2 (e.g. reserve 0 or N-1 as a “forced reset” number) but I don’t want to do that as noted.

Now we have established an MSN, once we have data to send in TC messages we could do the same with the ANSN. Or actually we don’t need to wait, we can do that with empty TC messages. Complete ones. (Note that, unlike OLSRv1, empty messages are recorded.)

Why might this not work? (Apart of course from something I’ve overlooked.) I think there is implicit permission for a router to ignore messages with a big gap of sequence number from last seen as a security measure. We need that not to be done. (That would be firming up behaviour.) But - and as even there will be a security implications section - we really want to be running with authenticated messages anyway.

Is this fast enough? That depends on how long your data would take to expire anyway. This is really for cases where long duration data can be assumed.

If anyone does want to take this further, I’m around.

Christopher