| Internet-Draft | Coordination of Nodes in COIN | January 2023 |
| Du | Expires 20 July 2023 | [Page] |
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.¶
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].¶
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 https://datatracker.ietf.org/drafts/current/.¶
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.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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.¶
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.¶
TBD.¶