Data-driven Coordination of Network Devices in Computing in the Network

In SRv6, network programming on the data plane is supported , in which a packet can contain a list of instructions. Each instruction contains a LOC and a FUNCT, which enables the packet get to a specific node related to the LOC, and implement a specific function related to the FUNCT. In COIN (Computing in the Network) as mentioned in and , a more general scope of network programming is described, whose usecases include privacy protection, intrusion detection, network monitoring, etc. If the mechanism of COIN is implemented in a distributed system, the coordination is a key aspect. In this document, we introduce a preliminary mechanism to coordinate different network devices supporting COIN to complete a job which does not appoint a specific node to do it.

In Figure 1, we assume that the Ingress, Egress, and the three Routers all support COIN. For example, they can detect the DDos attack by analyzing the characteristics of the flows, and drop packets of the suspect flows. In this situation, the detecting job can be done in any node, so some coordination methods are needed here.

On one aspect, for a specific flow, only one pass of processing for the job is needed. We do not need every node along the path to do the job again and again. On the other aspect, if a node is busy, for example with a high load on forwarding, it is not suitable to occupy computing resource to do the optional analysis job. However, we do not know exactly when the interface of the node is too busy to do the job. The traffic in an IP network is quite dynamic. Hence, we propose a method to make some coordination on the data plane.

In the proposed mechanism, we assume the packet can carry a Flag field that can be obtained by every node along the path. Each bit stands for a specific job needed to be done, but no specific node is appointed. For example, we assume two jobs are needed to be done in the network, so that we have two bits set to "1" in the Flag field in Figure 1. The Ingress does the first job, and cleans the third flag. The Router2 does the second job, and cleans the fifth flag. Every node along the path can see the Flag field, so that they will only do the job once for a specific flow. Meanwhile, if it is busy, it can choose not to analyses the flow, and just do the normal forwarding. Comparing to the SRv6 network programming, the proposed mechanism is more flexible in some scenarios. The reason is that we do not need to appoint a specific implementing node, and the nodes can make a local decision about whether to do the job according to its status.

TBD.