Skip to content

Architecting for Innovation from an Infrastructure Perspective.

September 10, 2011

We have a paper club every second week at which we discuss in detail a  paper of interest. This week we discussed Architecting for Innovation written by a long list of very well known authors Teemu Koponen, Scott Shenker, Hari Balakrishnan, Nick Feamster, Igor Ganichev, Ali Ghodsi, P. Brighten Godfrey, Nick McKeown, Guru Parulkar, Barath Raghavan, Jennifer Rexford, Somaya Arianfar and Dmitriy Kuptsov. The paper received a mixed reaction at the paper club. The reason I mention it here though is that it contained some concepts that resonate very much with the CTVR research programme.

The paper essentially deals with the challenge of designing a clean slate Internet architecture. Many of the authors have a serious track record in this field. The authors discuss how difficult it is to design for an unknown future and suggest a way forward that they believe is highly evolvable. Designing for Change is a theme of the CTVR research programme and we have a big interest in evolvable networks. Hence I was interested to read the Architecting for Innovation paper. The authors suggest that the best way forward is to identify a small number of architectural anchors – interfaces that need to be tied down – and let everything else around these evolve and change. In this way we don’t need to know what lies ahead.

In the paper they suggest three interfaces for these architectural anchors. The first is the interdomain routing interface, the second is the interface between the network and the application and the third relates to a primitive for interdomain distributed denial of service attacks.

This paper is not about the physicality of the network. The authors work at higher layers. Much of our work relates to the network infrastructure that lies underneath these layers. A lot of people think that once the higher layers are abstracted from the infrastructure and technology underneath, it kind of doesn’t matter what really happens ‘down there’. In making this statement I am in no way suggesting the authors of this paper believe that – they make no such comments. But it is a general view.

For us the evolvability of the network has to be examined in terms of infrastructure and the physicality of the network. We use a very similar vocabulary when discussing the challenges we face. We want to understand where the anchors in the networks should be. What are the minimum number of things that must be tied down and what things can remain flexible enough to evolve and move in whatever direction is necessary?

With this in mind I am actually more interested in some additional suggestions by the authors beyond the three interfaces that I mentioned already. The authors suggest that, ‘There are three other minor primitives that must also be built into FII, mainly to cope with the architectural heterogeneity that FII enables‘. BTW FII stands for Framework for Internet Innovation.

These extra primitives they suggest are meta-negotiation, bootstrap interface and interface query.

Obviously the authors have very specific Internet Architectural ideas as to what these three functions are. However these resonate with me, particularly on the wireless side of the world and I think could form the basis of a minimum set of definitions that might be used for networks of the future.  So I am going to borrow the terminology and redefine it in a way that suits me.

I will start with the bootstrap interface. The kinds of networks we currently use, avail of predefined, mostly static resources. For networks of the future that may be much more dynamic (such as those that seek out and scavenge spectrum, use different resources in the Cloud as and when needed etc.) some kind of bootstrapping process will be needed that is very generic and not tied to a specific technology or which does not call for specific hardware. The bootstrapping process would allow nodes to freely associate with any service provider entity that (dynamically or otherwise) finds resources to offer a service. Or to self-organise into an independent entity.  Network infrastructure will be performed into existence much more dynamically.

We have to stop labeling spectrum for specific uses. We need to allow different networks to coexist side-by-side spectrally or geographically without having to dictate in advance what kinds of neighbours are allowed. The only way to do this completely flexibly, in my opinion, is to support negotiation between neighbours. If two neighbouring networks choose not to negotiate then the networks must operate cautiously and conservatively (i.e. limited power, restricted use of available spectrum to avoid adjacent channel interference).  If they do negotiate they optimise their operating parameters to make the most of  the available resources without disrupting each other.  Hence a simple meta-negotiation interface would allow networks to decide ‘how to communicate with each other’ in a manner that best suits them.

Finally the interface query idea in terms of physical infrastructure maps to the concept of a device or component in the network being able to describe it’s capabilities. This would mean a very big change in how things are standardised. A standard would no longer specify,  for example, waveform, modulation technique, etc., but instead standardise the process of how entities describe themselves. This may be necessary in the bootstraping process for the infrastructre, during negotiation between neighbouring networks or during normal communications processes to decide how best to use the entity.

These are very raw initial thoughts. The Architecting for Innovation paper definitely helped me articulate these more than I had been doing so far … (not much more you might say).

The Architecting for Innovation paper also evaluated the solution to see how well it could deal with changes – using some kind of information flow analysis. It was quite qualitative in nature. I think the issue of evaluating ‘how evolvable’ something is is very tricky. Too tricky for now.

Advertisements
Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: