Project Overview

Network-layer innovation has proven surprisingly difficult, in part because a few protocols dominate, which enables layer violations that entrench technologies. These layer violations support the policies that were not explicitly designed for within the existing architecture. For example, few policy goals, such as privacy, accountability, and even performance, are supported by explicit mechanisms. Disruptions such as denial of service attacks, spoofing, and routing outages expose imperfections in the architecture every day. The research community has identified many problems in the Internet architecture and proposed solutions, most of which are constrained because they aim for some backward-compatibility.

Many shortcomings of today’s internetwork layer result from its inflexibility with respect to the policies of the stakeholders: users and service providers. The consequences of these failings are well-known: various hacks, layering violations, and overloadings are introduced to enforce policies and attempt to get the upper hand in various “tussles”. The result is an Internet that is increasingly brittle, hostile to innovation, vulnerable to attack, and insensitive to concerns about accountability and privacy.

We propose to design, implement, and evaluate through daily use a minimalist internetwork layer and auxiliary functionality that anticipates tussles and allows them to be played out in policy space, as opposed to in the packet- forwarding path. We term this design a postmodern internetwork architecture because it is a reaction against many established network layer design concepts. The overarching goal of the project, and the motivation for choosing a minimal networking layer, is to make a larger portion of the network design space accessible without sacraficing the economy of scale offered by agreeing on a common set of protocols. The primary tenets of our postmodern design are (i) strict separation of concerns, and (ii) inclusion of explicit mechanisms in support of all foreseeable policies influencing network-layer behavior.

These principles lead to a design with the following novel characteristics:

• We separate path determination from forwarding to allow users greater control over the paths followed by packets through the network. At the same time, providers may, if they desire, retain control over transit paths through their networks for traffic engineering purposes. We also enable users to amortize the cost of determining a path from a source to a destination over multiple packets (if they choose to do so) via a caching mechanism.

• We eschew hierarchical identifiers (i.e., anything like IP addresses); components in the topology can thus be added and rearranged without concern for allocation of scarce resources (topology-based addresses) and without consulting a global authority.

• We capture an unforgeable record of the path traversed by each packet to provide the accountability that would curtail denial of service, spam, and other forms of abuse. At the same time, we attempt to provide complete control to providers over the “opacity” of their network topologies and policies. The portion of the recorded path inside their network can be used to reconstruct internal topology only with the provider’s cooperation and as controlled by the provider’s policy. We thus isolate the concern of path selection from that of topology disclosure.

• On the other hand (and to some extent in compensation for this isolation), our architecture requires transparency of the top-level interconnection of realms. We believe the desire for providers to hide peering relationships is an artifact of existing protocols (BGP) and the fact that realm-level customer-provider relationships are largely constrained by topology today.

• We separate the customer-provider relationship from topology by providing an explicit mechanism for expressing why each router should forward a packet. A user might be a customer of several transit providers; explicitly motivating routers to forward packets enables customer-directed routing that would choose among them.

• We support information flow from the network to the user (for example, about traffic conditions or path availability), and policy flow from the user to the elements of the network (for example, preferential drop policies) via cross-layer “knobs and dials."

PoMo Wiki

A wiki with additional information and the most recent developments on the PoMo project can be found here.

People

Faculty	Graduate Students
Bobby Bhattacharjee	Onur Ascigil
Ken Calvert	Randolph Baden
Jim Griffoen	Adam Bender
Neil Spring	Abdul Jabbar Mohammad
James P.G. Sterbenz	Justin P. Rohrer
	Song Yuan

Publications

• Pomo Proposal
• K. Calvert, J. Griffioen, L. Poutievski, "Separating Routing and Forwarding: A Clean-Slate Network Layer Design", In the proceedings of the Broadnets 2007 Conference, September 2007
  

Sponsor

National Science Foundation (NSF)