• An End-host Stack for Services

    Serval is a modification to the Internet architecture that adds better support for modern, dynamic network environments where service access is central. Such access involves connecting to potentially replicated services directly on service names (“connect to Google”), picking a replica based on, e.g., location and load, and then robustly maintaining connections across physical mobility at clients or virtual-machine migrations in datacenters.

    To this end, Serval identifies flexible service-centric naming abstractions as key to supporting modern service access. Unfortunately, today’s host-centric abstractions restrict the support for mobility, migration, multi-homing, anycast, load balancing, and failover. Serval instead treats services and connected data flows as first-class primitives by naming them explicitly—something achieved only implicitly today through the overloading of port numbers and IP addresses. Serval’s new naming abstractions enable a wide range of functionality in a coherent, clean architecture, previously handled by clumsy, management-intensive point solutions. Even so, Serval can be incrementally deployed on the existing Internet as it sits on top of IP. In fact, this website itself runs Serval.

    The centerpiece of the Serval architecture is a new Service Access Layer (SAL) that sits between the IP Network Layer (Layer 3) and the Transport Layer (Layer 4), where it can work with unmodified network devices. The SAL is a service data plane that establishes and maintains connectivity to replicated services. With Serval, end-points can seamlessly change network addresses, migrate flows across interfaces, or establish additional flows for efficient and uninterrupted service access. A separate service control plane gives potentially centralized control over service access and resolution, greatly reducing the complexity of managing replicated services.

    With Serval, the IP network can keep doing what it’s best at: delivering packets between hierarchically-aggregatable, topology-dependent network addresses. The need to build large layer-2 networks for VM migration, to extend subnets across layer-3 domains by various encapsulation and tunneling means, and to use on-path NATting load balancers, all disappear.

    More information can be found in our overview, peer-reviewed publications, or FAQ, including answers to: