NY Times: Time to build a new Internet? from Stanford --

[David Farber <dave () farber net>]

Begin forwarded message:

From: Guru Parulkar <parulkar () stanford edu>
Date: February 26, 2009 10:48:23 PM EST
To: dave () farber net
Cc: "ip" <ip () v2 listbox com>
Subject: NY Times: Time to build a new Internet?


Dave,

I am late in getting into this discussion but want to make a few  
observations especially in the context of our research program (Clean  
Slate Internet Design Program at Stanford) which was mentioned in the  
original NYT article.

Several postings suggest two concerns (among others):

  o efforts aimed at reinventing or rethinking the Internet will make  
the network less open and thus compromise our ability to innovate.

  o research programs such as Clean Slate may require a flag day when  
you turn on the new Internet and turn off the old one which is of  
course very unrealistic.

These concerns are not valid -- at least the way we are approaching  
our research program.

  o Yes the current Internet and its architecture allow innovations  
at "the end hosts" and that has been great and we must preserve this.  
However, if you think about the current Internet (both its  
architecture and the physical artifact), it does not allow innovations  
within the network by a third party or even its owners and users.  
Network equipment and the equipment vendors dictate the behavior of  
the network -- all the functionality is baked into this equipment (in  
ASICs and proprietary software) and they are closed. For example, a  
network operator or users have little control over how routing,  
traffic engineering, access control, or mobility management is done  
within the network unless they work closely with the equipment vendors  
and get their ideas supported. Moreover, the network routers and  
switches are getting more and more complex and represent significant  
barrier to innovations by anyone. Wouldn't it be nice if the Internet  
allowed innovations at the edges AS WELL AS within the network itself?

  o That is exactly what we are trying to do with OpenFlow -- enable  
innovations within the network so researchers, operators, service  
providers, application creators, and other stakeholders can find  
solutions to Internet's problems and keep making it better and better.  
This also means stakeholders can decide how they want to run their  
networks and services. OpenFlow defines a simple protocol which allows  
access to and control of the flow table in a typical switch or router  
from outside -- most switches/routers already have a flow table. A  
controller that manages the flow table (on behalf of the network  
operator,  a service operator, users, or researchers) is implemented  
in software on a PC/server. Once you have access to the flow tables of  
switches/routers of a network, you essentially have control of the  
network. One can create network services on top of a controller to do  
customized routing, access control, mobility management, and even a  
new protocol stack  -- people can try and deploy completely new and  
clean slate ideas in this setting. BTW, OpenFlow hypervisor called  
FlowVisor allows partitioning of a flow table among multiple  
controllers and so one can create multiple virtual networks on the  
physical network -- each managed by its own controller and network  
services on top.

  o OpenFlow is backward compatible with Ethernet and IP in that it  
uses standard TCP/IP/Ethernet protocol headers and end hosts don't  
need to change. Several vendors including Cisco, Juniper, HP, and NEC  
are starting to support the OpenFlow feature in their select products  
and our production network in Stanford's Gates Building is OpenFlow  
enabled and hardly anyone notices it. BTW, this email comes to you  
over an OpenFlow network. Bottom line, one can partition a production  
network into multiple slices or virtual networks. For example, there  
can be a separate slice for legacy production, experimental  
production, and experimental traffic. And as experimental network  
services mature they can handle more and more production traffic  
seamlessly.

  o In 2009 we expect a few more buildings at Stanford to be OpenFlow  
enabled and several other universities are getting ready to deploy  
OpenFlow capability into their production networks. We are also trying  
to see if we can deploy OpenFlow into research networks such as NLR  
and I2 (we have done it in a very limited way just for demo but not at  
scale yet).

  o Bottom line, with OpenFlow we are making the Internet more open  
and enabling more innovations rather than make it closed and curb  
innovations. Also we are not expecting a flag day -- just the  
opposite. One can pursue clean slate ideas and also bring about a big  
change in the networking substrate without requiring a flag day.

   o It is true that using these platforms one can explore different  
design choices: a network that is more secure and potentially less  
open or more secure and more open. We think it is perfectly ok for the  
researchers to explore different design choices and different choices  
may make sense in different settings.

Finally I want just say our program mission is to help reinvent  
Internet infrastructure and services by creating “platforms for  
innovations” in networking, computing, and storage and making them  
available to research and user communities. OpenFlow is our platform  
for innovations for networking. And we are following similar approach  
for computing and data substrates. This is also consistent with NSF  
research programs such GENI and FIND -- they are also seeking  
architectures and mechanisms that would enable more innovations rather  
than less.

Hope this helps and provides more context for our research program and  
approach.

-guru






-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com