Re: [OPSAWG] Help with a MANET management draft please

[Juergen Schoenwaelder <[e-mail]>]

Hi,

this is useful input, in particular the description of the various
things NMSes in a MANET context like to do. Concerning the text in the
I-D, I would probably stay away from classifying other protocols as
"simpler" or "less chatty", in particular if they are all kept secret
(note that proprietary does not necessarily imply that a protocol is
secret - there are many proprietary protocols that are documented).

/js

On Thu, Feb 27, 2014 at 03:17:26PM +0100, Thomas Clausen wrote:
> Dear Juergen,
> 
> On 27 Feb 2014, at 08:07, Juergen Schoenwaelder <[e-mail]> wrote:
> 
> > On Wed, Feb 26, 2014 at 11:40:29PM +0000, Adrian Farrel wrote:
> > 
> >> Could any of you find time to review and comment (on this list, on
> >> the MANET list, direct to the authors, channelled through me)? All
> >> contributions will be gratefully received.
> > 
> > Out of curiosity, I would like to understand what the background
> > behind these statements is:
> > 
> >   "protocols such as SNMP (or possibly other, less "chatty",
> >    protocols)."
> > 
> >   In some deployments, the NMS communicates with individual routers by
> >   way of SNMP - and, more commonly, by way of "proprietary" simpler,
> >   less verbose and (often) less secure protocols, and over UDP.
> > 
> > Any pointers to such proprietary protocols? I am just wondering what
> > the network management communication patterns are that take place in
> > MANETs.
> 
> I would love to be able to provide a pointer, but that's unfortunately the nature of "proprietary": I can't. I actually do not believe that there's any "de-facto standard" or "commonly used proprietary protocol" out there, more a matter of each implementer of OLSR (v1 and v2, both) set out realising the need for interacting with a running OLSR instance, and coming up with his/her own approach depending on ad-hoc needs.  Heck, I don't think I've actually seen a written documentation of these "proprietary" protocols, except for their code....
> 
> Initially, what we saw was in the numerous OLSR interop's we've held, where we saw a remarkable number of visualisation tools, for example, depicting the evolution of the network topology (caveat: routers in a MANET are likely to move about), or tools permitting to temporarily provoke a "failure-like event" in a router to be able to observe how the surrounding network behaves - with instrumenting routers to record and reflect their behaviours. Tools, that is, communicating with the protocol instance in whatever way the implementer saw fit to build, since there was no commonly agreed-upon, documented, way.
> 
> But, you do make a good point which is - I think - that it might be helpful to document what the (management) communications patterns may look like in an operating (post-startup) network. I think that that probably is a good idea, so we'll definitely see about that in a coming revision of the document, thank you for that suggestion!
> 
> I'll throw a few thoughts - without claiming to be exhaustive - out below as what I see in the networks that I know of and know very well,  that happens "often" - note, this is just in what *I* see, not what *everybody* sees or what everybody may wish to see happen:
> 
> 	a)	Inquire the state (complete topology graph, link states, local links even if not part of topology graph) of a router
> 		Often, this is getting "up to a few KB worth of data" back
> 		It's not a very common operation.
> 
> 	b)	Inquire the history/statistics of a router
> 		This is typically something tiny, like "how many local link changes have you seen within the past n minutes/seconds/hours"
> 		This may be very rare, or it may be several times per minute per router for a while: if my NMS is trying to "tune" message 
> 		intervals and timers, it may be a case of "doing this to a group of topologically close routers" - until, that is, the NMS decides
> 		that it's happy with what it sees and will ease up
> 
> 	c)	Change the configuration of a router
> 		Other than in the above case (tuning) this really happens only when somehow I get a new uplink to an external network,
> 		and I either need to throw a new gateway into the network, and/or I need to get a new prefix out to the routers.
> 
> 	d)	Visualising the network as a router sees it.
> 		Note that as in a MANET, routers do move about, this may mean that the topology changes frequently. In a naive way, this would
> 		essentially be the NMS setting up a connection to the router in question, and "getting a copy of all routing protocol
> 		control messages" to construct its own topology graph as would have done that router. Typically, it consists of the router sending a 
> 		notification to the NMS when a topological change happens, i.e., when either of its information bases change. Even better, it
> 		consists of these notifications being "filtered" to only send for those changes that actually impact the usable topology.
> 
> 	e)	Rekeying - we do not actually have a (standard) mechanism for AKM, and I maintain that it probably is not possible to come
> 		up with a single such that will satisfy the requirements for all the different deployments, but it's still something that we do play with.
> 		I'm actually doing that as part of a management operation and schlepping it around as I would any configuration parameter
> 		(not saying that it's the right thing to do, though, just what I'm playing with). The particularity of this is, that it often is a "broadcast
> 		configuration operation" where you want to get new material to everybody, and not just a single device.
> 
> Some of the proprietary stuff that has been done (and which I have done) in the past, can be explained easily by the above, and by the fact that in OLSR (v1 and v2) we have really efficient flooding operations in place. This can (and has) be used to do e) much much more efficiently (& reliably) than a bunch of unicasts. For b), too, in case we want to configure a "group of topologically close routers": unicast to one of them (topologically as central as possible) and then use scope-limited optimized flooding to reach the surrounding routers. As for d), the opportunities are endless for thinking up ways to do that...
> 
> Moving towards standardized data representations, such as the MIBs, as well as some of the interesting developments by Bob Cole (REPORT-MIB - http://tools.ietf.org/html/draft-ietf-manet-report-mib  - yes, it is expired, but we need to revive that, I think) are steps that we're trying to take to exit the world of "ad-hoc" management solutions.
>  
> Not sure if that's a useful answer to your question? I am sorry that I can't point to some neatly written up whitepaper, which clearly would have been a better answer.
> 
> Either way, your question is good and it might make sense to mull a bit on that and try to capture a more complete answer to it than what I provided in the above in the document?
> 
> Tschüß,
> 
> Thomas
> 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> > Fax:   [phone]         <http://www.jacobs-university.de/>
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>