Internet-Draft Coordination of Nodes in COIN January 2023
Du Expires 20 July 2023 [Page]
Computing in the Network Research Group
Intended Status:
Z. Du
China Mobile

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


This document describes a coordinatable mechanism for the network devices in Computing in the Network (COIN). A Flag filed in the packet header is used in the mechanism. It provides a straightforward way to communicate information among the network devices supporting COIN in the network.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 20 July 2023.

Table of Contents

1. Introduction

In SRv6, network programming on the data plane is supported [RFC8986], 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 [I-D.irtf-coinrg-use-cases] and [I-D.kutscher-coinrg-dir], 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.

2. Problem Statement

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.

 +---------+    +---------+    +---------+    +---------+    +---------+
 | Ingress |----| Router1 |----| Router2 |----| Router3 |----|  Egress |
 +---------+    +---------+    +---------+    +---------+    +---------+

  00101000       00001000       00001000       00000000       00000000

   Figure 1: Topology for the Coordinatable COIN network in which
            the nodes can optionally do the job flexibly

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.

3. Coordinatable Network Devices

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.

4. IANA Considerations


5. Security Considerations


6. Acknowledgements


7. References

7.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, , <>.

7.2. Informative References

Kunze, I., Wehrle, K., Trossen, D., Montpetit, M., de Foy, X., Griffin, D., and M. Rio, "Use Cases for In-Network Computing", Work in Progress, Internet-Draft, draft-irtf-coinrg-use-cases-02, , <>.
Kutscher, D., Karkkainen, T., and J. Ott, "Directions for Computing in the Network", Work in Progress, Internet-Draft, draft-kutscher-coinrg-dir-02, , <>.

Author's Address

Zongpeng Du
China Mobile
No.32 XuanWuMen West Street