Subject: [Sdn] Applicability of web browser architecture to network element management

From: STUART VENTERS <[email-masked]>
Date: Wed, 8 Jan 2014 20:36:44 +0000

All,

(Not sure if this is useful or not, but I'll put it out and see what happens.)

This proposes an evolved (or maybe devolved?) model for an SDN managed network element using another lesson from web browsers, namely the DOM.

With regards to how one might use a network element with an SDN control interface.
One issue is how to deal with things that happen quickly at the forwarding engines.
For example watching a large number of statistics and sifting out a few interesting events.
  (A similar use case might be useful for 50 ms configuration changes after a protection switch.)
(Another use case is what happens when the connection to the controller is lost.)
It would be useful to have code running at the forwarding engine doing the sifting.
To do this, one would have to both specify a programming language and interfaces to the forwarding engine and controller.

A web browser already does quite a bit of this and might be a useful model.

My understanding of how a browser operates is as follows:
    When you choose a page, the browser downloads the xml page to the DOM.
    Certain things in the DOM get rendered on the screen.
    If  JavaScript was included in the page, then it can modify the DOM, causing what is rendered to change.
   The JS can reach back into the network to get other things it needs.
    User events can be captured by the downloaded JS to make an interactive page.

The DOM is basically the programming interface available to JS to make things happen on the screen.
I propose a similar story, except that DOM should cause things to happen in the forwarding engine.
   (And also should be where results from the forwarding engine show up.)

In effect, this moves the SDN control interface from a protocol interface to a programming interface.
   Centralized control becomes user customized distributed control.
   One could support the current SDN model with a default proxy JS program in the NE, but some combination of both seems likely.

Such a model might provide a greater level of functionality to the SDN control interface
   while at the same time requiring less new stuff.  (Web programmers should feel right at home.)

Comments?

Stuart Venters