• Technical Overview

    The Internet is increasingly a platform for accessing services that run anywhere, from servers in the datacenter and computers at home, to the mobile phone in one’s pocket and a sensor in the field. An application can run on multiple servers at different locations, and can launch at or migrate to a new machine at any time. In addition, user devices are often multi-homed (e.g., WiFi and 4G) and mobile. In short, modern services operate under unprecedented multiplicity (in service replicas, host interfaces, and network paths) and dynamism (due to replica failure and recovery, service migration, and client mobility).

    Yet, multiplicity and dynamism match poorly with today’s host-centricTCP/IP-stack that binds connections to fixed attachment points with topology-dependent addresses and conflates service, flow, and network identifiers. This forces online services to rely on clumsy and restrictive techniques that manipulate the network layer and constrain how services are composed, managed, and controlled. For example, today’s load balancers repurpose IP addresses to refer to a group of (possibly changing) service instances; unfortunately, this requires all client traffic to traverse the load balancer. Techniques for handling mobility and migration are either limited to a single layer-2 domain or introduce “triangle routing.” Hosts typically cannot spread a connection over multiple interfaces or paths, and changing interfaces requires the initiation of new connections. The list goes on and on.

    To address these problems, we present the Serval architecture that runs on top of an unmodified network layer. Serval provides a service-aware network stack, where applications communicate directly on service names instead of addresses and ports. A service name corresponds to a group of (possibly changing) processes offering the same service. This elevates services to first-class network entities (distinct from hosts or interfaces), and decouples services from network and flow identifiers. Hence, service names identify who one communicates with, flow names identify what communication context to use, while addresses tell where to direct the communication.

    At the core of Serval is a new Service Access Layer (SAL) that sits between the transport and network layers. The SAL maps service names in packets to network addresses, based on rules in its service table (analogous to how the network layer uses a forwarding table). Unlike traditional “service layers,” which sit above the transport layer, the SAL’s position below transport provides a programmable service-level data plane that can adopt diverse service discovery techniques. The SAL can be programmed through a user-space control plane, acting on service-level events triggered by active sockets (e.g., a service instance automatically registers on binding a socket). This gives network programmers hooks for ensuring service-resolution systems are up-to-date.

    As such, Serval gives service providers more control over service access, and clients more flexibility in resolving services. For instance, by forwarding the first packet of a connection based on service name, the SAL can defer binding a service until the packet reaches the part of the network with fine-grain, up-to-date information. This ensures more efficient load balancing and faster failover. The rest of the traffic flows directly between end-points according to network-layer forwarding. The SAL performs signaling between end-points to establish additional flows (over different interfaces or paths) and can migrate them over time. In doing so, the SAL provides a transport-agnostic solution for interface failover, host mobility, and virtual-machine migration.

    Although previous works consider some of the problems we address, none provides a comprehensive solution for service access, control, dynamicity, and multiplicity. HIP, DOA, LISP, LNA, HAIR, and i3 decouple a host’s identity from its location, but do not provide service abstractions. DONA provides late binding but lacks a service-level data plane with separate control. TCP Migrate supports host mobility, and MPTCP supports multiple paths, but both are tied to TCP and are not service-aware. Existing “backwards compatible” techniques (e.g., DNS redirection, IP anycast, load balancers, VLANs, mobile IP, ARP spoofing, etc.) are point solutions suffering from poor performance or limited applicability. In contrast, Serval provides a coherent solution for service-centric networking that a simple composition of previous solutions cannot achieve.

    For more detailed information, please see our publications about Serval.