This paper looks at the problem of accessing services on a network which are potentially geographically distributed (for example, the closest server for a particular service). Serval allows the discovery of end-points for services and allows them to seamlessly migrate so ‘‘end-points can seamlessly change network addresses, migrate flows across interfaces… [with] uninterrupted service access." Serval runs on an unmodified network layer. Application communicate with service names (identifying the changing group of hosts providing a service) not addresses and ports. Current solutions in this space can be clumsy because of the host-centric nature of the network stack. For example, load balancers can be used to pretend an IP address refers to a number of hosts (service instances).
The core idea is the Service Access Layer (SAL) – this sits between the transport and network layer. The job of the SAL is to map a service name according to a service table (like a forwarding table). The SAL can be programmed through a user-space control plane and results in a service level data plane.
Application Layer: Applications communicate over active sockets using service names. Because the SAL is below the transport layer then a service name can be resolved in an anycast way to an address as part of connection establishment.
Transport Layer: In standard TCP/IP the transport layer demultiplexes traffic to the correct sockey by using the 5-tuple to deliver to the correct destination and port. In Serval transport protocols deal only with data delivery across one or more flows – demultiplexing is doen with a flow idenifier (flowID).
Network Layer: In standard TCP/IP the heirarchical IP address is used to deliver packets but this makes mobility a problem. In Serval the network layer simply delivers packets between end points using location dependent addresses – flow mobility and migration is handled above this layer in the SAL.
Page generated 2014-01-07, by jemdoc.