30 | | Online services, replicated on multiple servers in different datacenters, have |
31 | | (at best) a loose, and often transient, association with specific end-hosts or |
32 | | locations. Yet, today, these services rely on host-centric networking |
33 | | primitives designed decades ago, retrofitted with various "hacks" (e.g., ARP |
34 | | spoofing and DNS with small TTLs).[[BR]] |
| 30 | Historically, Internet services provide clients with access to the |
| 31 | resources of a particular host. However, today's services are no |
| 32 | longer defined by a single host or confined to a fixed location. Yet, |
| 33 | the network architecture continues to impose an unfortunate coupling |
| 34 | between hosts and services by binding connections to |
| 35 | topology-dependent addresses---complicating everything from server |
| 36 | replication, load balancing, and virtual-machine migration, to client |
| 37 | mobility and multi-homing. [[BR]] |
36 | | This project proposes a network architecture |
37 | | that meets the needs of these online services. SCAFFOLD (Service-Centric |
38 | | Architecture For Flexible Object Localization and Distribution) moves from |
39 | | human-readable host names to machine-readable service identifiers, from |
40 | | individual packets to flows, and from unicast communication to anycast. |
41 | | SCAFFOLD hides network addresses from applications to enable dynamic remapping |
42 | | as end-points change, (e.g., due to virtual-machine migration, failover, or |
43 | | device mobility), and directs traffic based on successively-refined identifiers |
44 | | to scale routing and limit churn. While SCAFFOLD can be viewed as a |
45 | | clean-slate Internet architecture, we primarily investigate how a single |
46 | | organization can apply our solution today to host online services at multiple |
47 | | datacenters. This project entails the design, implementation, and evaluation of a socket |
48 | | API and network stack for end-hosts, and a network infrastructure built using |
49 | | OpenFlow and NOX.[[BR]] |
| 39 | In this project, we propose a new service access layer that redefines the |
| 40 | interaction between the network and transport layers. This layer |
| 41 | provides the "thin waist" needed to enable direct communication on |
| 42 | topology-independent service names, decouple service connections from |
| 43 | network identifiers, directly support multi-homing and mobility, and |
| 44 | enhance the network's awareness of service availability. [[BR]] |
51 | | SCAFFOLD will be a distributed service on GENI that serves as a |
52 | | platform for deploying other user-facing services, thereby lowering the |
53 | | barrier for others creating new distributed services. SCAFFOLD will |
54 | | leverage GENI-related prototyping efforts such as !OpenFlow switches, |
55 | | the NOX controller, the VINI backbone, the BGP multiplexer and the |
56 | | PlanetLab control framework. The project will also use the resulting SCAFFOLD prototype itself to build |
57 | | several services for GENI, in order to demonstrate its utility. |
| 46 | We investigate Serval, a complete architecture built around this new layering that |
| 47 | handles server replication, network dynamics, and diverse service |
| 48 | discovery techniques, while ensuring scalability, security, and the |
| 49 | efficient handling of churn. By running squarely above the network |
| 50 | layer, Serval is backwards compatible with today's IP networks.[[BR]] |
| 51 | |
| 52 | Serval is an experiment to be deployed on top of GENI aggregates, as well |
| 53 | as provide a platform for future GENI experimenters to more easily deploy |
| 54 | mobile and distributed services. |
| 55 | |