This whitepaper proposes OpenFlow: a way for researchers to run experimental protocols in the networks they use every day. OpenFlow is based on an Ethernet switch, with an internal flow-table, and a standardized interface to add and remove flow entries. Our goal is to encourage networking vendors to add OpenFlow to their switch products for deployment in college campus backbones and wiring closets. We believe that OpenFlow is a pragmatic compromise: on one hand, it allows researchers to run experiments on heterogeneous switches in a uniform way at line-rate and with high port-density; while on the other hand, vendors do not need to expose the internal workings of their switches. In addition to allowing researchers to evaluate their ideas in real-world traffic settings, OpenFlow could serve as a useful campus component in proposed large-scale testbeds like GENI. Two buildings at Stanford University will soon run OpenFlow networks, using commercial Ethernet switches and routers. We will work to encourage deployment at other schools; and We encourage you to consider deploying OpenFlow in your university network too.

Despite the large number of papers on network topology modeling and inference, there still exists ambiguity about the real nature of the Internet AS and router level topology. While recent findings have illustrated the inaccuracies in maps inferred from BGP peering and traceroute measurements, existing topology models still produce static topologies, using simplistic assumptions about power law observations and preferential attachment.

There is a growing sentiment among academics in computing that a shift to multicore processors in commodity computers will demand that all programmers become parallel programmers. This is because future general-purpose processors are not likely to improve the performance of a single thread of execution; instead, the presence of multiple processor cores on a CPU will improve the performance of groups of threads. In this article, I argue that there is another trend underway, namely integration, which will have a greater near-term impact on developers of system software and applications. This integration, and its likely impact on general-purpose computers, is clearly illustrated in the architecture of modern mobile phones.

This paper focuses on BGP communities, a particular BGP attribute that has not yet been extensively studied by the research community. It allows an operator to group destinations in a single entity to which the same routing decisions might be applied.

In this article, we discuss the lessons in innovation from the last twenty years of the Internet that might be applied in the cellular telephone industry.

The July 2007 issue of CCR elicited review process horror stories. I expect that everyone has their own vast collection. I certainly do. However, I found that picking my favorite story to be like choosing my favorite offspring. Therefore, rather than focusing on a single tale of woe I have tried to extrapolate some key points from across the suboptimal reviewing I have observed. I write this essay from the perspective of an author who has years of accepts and rejects.1 However, this note is also greatly informed by my refereeing activities over the years (on PCs, reviewing for journals, editorial boards, etc.). My intent is to make general observations in the hopes of contributing to a conversation that improves our overall review processes and ultimately helps us establish a stronger set of community values with regards to what we expect and appreciate in papers. While I strive for generality I do not claim the observations are unbiased or that I have closed all my open wounds in this area.