RFC7939 – the final piece to the OLSRv2 puzzle

OLSR Logo

RFC7939 has just recently been approved: and published. This is, to some extend, the final piece of the core OLSRv2 (the Optimized Link State Routing Protocol version 2) puzzle – which is also therefore the final piece of a 10+ years adventure of protocol development and standardization. OLSRv2 is the standardized routing protocol for mobile, wireless, ad-hoc mesh network.

Final piece of a 10+ years adventure” is, of course, not to say that OLSR/OLSRv2 is dead, and that there’s nothing more to do – far from it. It is to say that the core protocol specification is now complete, and it’s time to engage in exploring and developing protocol extensions.

Anyways, behind the cryptic label RFC7939 hides a document title of “Definition of Managed Objects for the Neighborhood Discovery Protocol” which – of course – is not a whole lot less cryptic, except for those happening to know what a MIB module is (a Management Information Base module), and who know that “the Neighborhood Discovery Protocol” is one of the constituent parts of OLSRv2.

So, let’s start from the beginning. Simplifying things to the extreme, a protocol really is a triple:

protocol = (an algorithm, a data set, and a message exchange)

A protocol specification is, therefore, a specification of the message exchange allowing construction of the data set, upon which the also specified algorithm can operate.

To give a simple example, the protocol triple for a classic “link state routing protocol”:

A Link State Routing Protocol = {Dijkstra’s algorithm, A Graph, Link State Flooding}

So, given a bunch of routers running “A Link State Routing Protocol” deployed somewhere, running – it’d be fantastic to be able to inspect how well each of the routers are performing. This could be something like “how big is the routing table in router X” or “how many packets does router X discard because it doesn’t have a routing table entry to the destination“. It could also be fantastic to be able to tune router parameters – for example, tune the frequency at which a given router initiates a LSA flooding, or after how long time of inactivity a neighbor is no longer considered a neighbor.

Each router vendor could build a tool allowing inspecting and tweaking that sort of stuff for its routers, using a special (proprietary) interface in, and protocol to communicate with, its routers. Of course, a network (and, in particular, the Internet) is not made up by routers from just one router vendor – and for a network operator to use 50 different tools for querying 50 different routers in the same deployment would just be mad … as would be having to merge and consolidate data from said 50 tools for understanding “the state of the network”.

….enter MIB modules.

In a (again, simplified to the extreme) nutshell, a MIB module is a specification of “the internal bits and pieces that a router implementing a given protocol is expected expose to the rest of the world“.

In a certain way, a MIB module is to a networking protocol implementation a wee bit like .h-files are in C, or how Interface specifications are for Java classes: a programmer may not know how a given C-function or Java class is implemented, but does know the signature and how it is supposed to behave – what (types and semantics) its arguments and return values are. And, it allows him to invoke these as “library functions”, without knowing (and without caring) about their actual implementation.

To be a bit more complete, MIB modules specify the structure of the data sets and values exposed, and such – their access (across the network) is then typically by way of a protocol called SNMP (Simple Network Management Protocol). To return to our “bunch of routers running A Link State Routing Protocol”, if they all implement the appropriate MIB modules + the same network management protocol (e.g. SNMP), they can all be queried and “managed” in the same way, by the same tool, and provides homogenous (or, at least, homogenously looking) data and configuration knobs, regardless of if they are from the same, or from different, vendors.

Indeed, this allows for generic management tools by specialist tool developers, and tools which present aggregate information from all routers in a deployment, etc. And a properly specified MIB module follows a very strict syntax, allowing to automatically “compile” it into these tools.

Of course, in an ideal world, a revision of a protocol does not require a revision of “the interface for management tools” – although sometimes, it does. This RFC7939 is really a new version of RFC6779 (of the same name) which was made necessary by an update to RFC6130 (the MANET Neighborhood Discovery Protocol) which was caused by RFC7466 (An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)).

RFC6130 is, by the way, one of the constituent parts of OLSRv2. Specifically, RFC6130 is a protocol which, by way of periodic HELLO message exchange, discovers bi-directional links between neighboring routers (with special attention to multiple interfaces/addresses in a wireless and non-transitive connectivity environment).

But why the update? In short, RFC6130 would “throw information away really quickly”, in some situations – whereas RFC7466 notices that “keeping that information a bit longer, but flag it to be of a specific tentative type, may allow faster error recovery in some situations” and specifies changes to the RFC6130 protocol sets to this effect. Changing the protocol sets, and adding data element types, required an update to the MIB module exposing data to management tools. Well, this is that update.

The bottom line of all this is, that OLSRv2 is now baked and complete: MANETs can be implemented, deployed, managed, by way of OLSRv2. And used, for operational networks.

And as an academic, more importantly, OLSRv2 provides a flexible, extensible, and stable platform for further experimentation and innovation. More on that in a later blog entry.

Of course, I would be greatly amiss if I claimed that MIB modules and SNMP was the be-all-end-all of network management and configuration. Indeed, Netconf/YANG is widely considered to be where the future lies for network management: YANG is an XML-based data modeling language used to model configuration and state data manipulated by the Netconf protocol.

So why did we do MIB modules for OLSRv2 and its constituent parts, and not YANG modules? As with many-things-networking, the answer is “legacy“. We’d simply started to encounter deployments (pre-dating Netconf/YANG reaching maturity) which were using MIB modules, and where it was desired to continue to use tools and protocols known and deployed.

I’d be very supportive of someone suggesting to dig in, and develop YANG modules for OLSRv2 and its constituent parts – would make for a nice (and, non-trivial) student project, for example. Do not hesitate to reach out to me if interested in this challenge.

RFC7939 was co-authored by Ulrich Herberg, Ian Chakeres, Bob Cole, and myself, and the standardisation process was shepherded by Christopher Dearlove (who is also co-author of OLSRv2 and most of its constituent parts)