TCP/IP networking relies on IP addresses mapped to a machine to facilitate routing through the Border Gateway Protocol ( BGP). This mapping is usually done through the DNS, which maps human-readable names ("cats.com") to IP addresses. Service centric networks are an alternative/extension to DNS, where the host maintains their own table of mappings from service names to tuples of IP address and port number, but with additional capabilities to control the routing of data. This additional flexibility is usually referenced in the literature as separating the control plane and data plane. The key advantage provided by this is additional flexibility in dynamically modifying the service table compared to DNS. Our discussion of service centric networking is based on the Serval paper here.
In service centric networks, the control plane is the mechanism used to configure routes in the network, and also to configure the path that a payload may take through the network. Once the route for a payload has been established through the control plane, the payload is said to move through the data plane to the target based on the established configuration. The reason for this separation is that control and configuration of the network is itself distributed, and requires communication channels of their own.
One way this control/data plane split is achieved is to use a host maintained service table as an intermediary between the control plane and data plane: routing decisions in the data plane are made using rules that are listed in the service table, but the value of these routing rules is managed independently by a local daemon running on each node in the network.
Something that we can do with this control/data plane split is called 'late binding'. In DNS any peer that is looked up must already have a bound IP address in the DNS table. This is called early binding, because the IP address of the peer is explicitly written in the DNS table. With the service table, when a connect is called, the IP address of the peer can actually be discovered dynamically, by routing the initial packet of the connection through the network, to find a peer that supports the service. After the peer is found, the peer can open a connection directly to the host, and the connection is now established. This approach, for example, allows us to implement a load balanced network without a load balancer.
Payloads moving in the data plane have an additional layer of encapsulation between the addressing headers used to facilitate network forwarding, and the headers use to identify the protocol that is being communicated. This additional information consists of a source and destination 'flow' identifier, the transport protocol that is being used, a series of sequence and acknowledgement numbers, and a service identifier for communication. We can distribute a payload over multiple flows to and from the peer as necessary.
Our use case for service centric networks is to allow for finer control and addressing in a microservice infrastructure (more so than in DNS), and being able to change the location of such services on the fly. We would also like to make use of features implicit in the transport protocol that is chosen for a flow, that allow us to migrate live peers to a new location, and reattaching any open flows in a way that is transparent to the end user.