Software-defined internet architecture: decoupling architecture from infrastructure

Authors: 
Barath Raghavan, Martin Casado, Teemu Koponen, Sylvia Ratnasamy, Ali Ghodsi and Scott Shenker
Published: 
HotNets
Year: 
2012

Paper advocates decoupling of network architecture from network infrastructure – Software Defined Internet Architecture (SDIA). Problem is to allow new architectures without falling back to a “clean slate” deployment.

Defintions:

  • Architecture: “the current IP protocol or any… convention on how packets are handled”.

  • Infrastructure: “physical equipment… (routers, switches, fibre, cables etc)”

Solutions like OpenFlow do not work as they are limited on what they can match in packets.

Note deviations from “standard internet design”:

  • MPLS – routers are not looking at IP label.

  • SDN – separates control plane from data.

  • Middleboxes – as numerous as routers in enterprise nets.

  • Software forwarding – normal in middleboxes and hypervisors.

Claim: these deviations applied systematically deploy architecture from infrastructure. Design core using internal addressing scheme and edge which uses software forwarding to map from internal to external addressing.

Connectivity from host X domain A to host Y domain B is following tasks:

  • Interdomain – carry packets from A to B possibly between multiple domains.

  • Intradomain transit – carry packets from domain ingress to domain egress.

  • Intradomain delivery – carry packet from X to edge of A and from edge of B to Y (also between two hosts in same domain).

Propose interdomain routing carried out using domain IDs without reference to host X or Y addresses. Now interdomain changes only involve changing software in edge routers (though this still seems a big ask!). Software forwarding allows a quite general “match” against addresses and if properly written could allow any address structure using a general “Match” function. Change from (say) IPv4 to IPv6 could be done domain by domain (although this might require that domain to buy new infrastructure).

Propose intradomain routing using edge/core architecture as described above. Only edge needs to understand interdomain so design is modular. Claim is that software forwarding at domain edges is feasable by parallel PCs using (for example) Valiant load balancing. “Interdomain Service Model” is the delivery service agreed between all domains. Deployment of new ISM requires:

  • Distributed algorithm among edge controllers.

  • Forwarding actions which can be sent to edge routers from edge controllers.

  • Measures to cope with partial deployment

Three examples are given to show how deployment might work:

  1. “Pathlets” – (unicast best effort packet service)

  2. ICN – content routing implemented interdomain supporting any naming scheme.

  3. Middlebox services – references Sherry et al “ Netcalls: End Host Function Calls to Network Traffic Processing Services”

Claim: In SDIA, edge routers are software allowing flexible protocol deployment. This means that intradomain infrastructure need only be bought to work with protocols if protocols achieve wide adoption.

Show bibtex
Page generated 2014-01-07, by jemdoc.