| Computing in Networking Research Group | Z. Li |
| Internet-Draft | Y. Mu |
| Intended status: Informational | C. Zhou |
| Expires: January 13, 2021 | China Mobile |
| July 12, 2020 |
COIN Operation, Administration and Maintenance Framework
draft-li-coin-oam-framework-00
This document provides reference framework for Operations, Administration and Maintenance (OAM) for Computing in the Network (COIN).
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.
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 January 13, 2021.
Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document aims to provide a reference framework for Operations, Administration and Maintenance (OAM) for Computing in the Network (COIN). The framework describes a tripartite consultation mechanism which includes consumers/providers registration, resource discovery/allocation, resource occupation, and resource release/refund.
In this framework, the device and platform will be regarded as a consumer or a provider of a computing power. One and the only manager will be responsible for the management of computing power and the contracts between consumers and providers.
Computing Power Consumer (or CPC, for short) is an application that needs computing power from the network. As a consumer, the application instance must register to CCM and be assigned a node id, which is a unique identifier in a COIN system.
Computing Contract Manager (or CCM, for short) is an application that is responsible for register administration of all the CPCs, CPPs and the Algorithm Repository. It can connect the consumers of computing power and the providers of computing power. It also signs the contracts for both sides.
Computing Power Provider (or CPP, for short) is an application that verifies the system having sufficient computing power available for external applications. As a provider, the application instance must register to CCM and be assigned a node id, which is a unique identifier in a COIN system.
CPC and CPP must register to CCM to confirm its role in the COIN system. An application instance can be a CPC and a CPP concurrently. In REGISTER Request message, the role field is a mandatory field. The CCM must assign a unique node id for the application instance and put it in the REGISTER Response message. The CCM has all the records of the CPC and CPP.
(1)REGISTER (1)REGISTER
req +-----+ req
+ --------------- > | CCM | < --------------- +
| + -------------- +-----+ -------------- + |
| |(2)REGISTER (2)REGISTER | |
| | resp resp | |
| | | |
| | | |
| | | |
| V V |
+-----+ +-----+
| CPC | | CPP |
+-----+ +-----+
Figure 1: Computing Power Register
(1)REGISTER Request message includes:
*Role type, identifying the role of the computing power contract. It may be consumer or provider
(2)REGISTER Response message includes:
*Role type, identifying the role of the computing power contract. It may be consumer or provider
*computing node id, unique node id assigned by CCM.
When a CPC meets distributed computing task,it seeks for computing power from CCM by DISCOVER Request message,along with the computing power requirements and corresponding algorithm requirements. Now that CCM has all the records of CPPs,it can choose one or more appropriate CPPs and send ALLOCATE Request message to them. The message at the same time contains the computing power requirements and corresponding algorithm requirements.
After the CPP has prepared for the necessary computing power and algorithm function, it sends ALLOCATE Response message to CCM with its provider node id and a serial number.After the CCM send DISCOVER Response message to CPC, the contract between a CPC and a CPP has been signed through CCM.
(3)DISCOVER (4)ALLOCATE
req +-----+ req
+ --------------- > | CCM | ----------------- +
| + -------------- +-----+ < ------------ + |
| |(6)DISCOVER (5)ALLOCATE | |
| | resp resp | |
| | | |
| | | |
| | | |
| V | V
+-----+ +-----+
| CPC | | CPP |
+-----+ +-----+
Figure 2: Computing Power Discover/Allocate
(3)DISCOVER Request message includes:
*consumer’s computing node id
*computing power requirements
*algorithm requirements
*consumer’s serial number
(4)ALLOCATE Request message includes:
*consumer’s computing node id
*computing power requirements
*algorithm requirements
*consumer’s serial number
(5)ALLOCATE Response message includes:
*consumer’s computing node id
*provider’s computing node id
*consumer’s serial number
*provider’s serial number
(6)DISCOVER Response message includes:
*consumer’s computing node id
*provider’s computing node id
*consumer’s serial number
*provider’s serial number
After the contract is signed by both sides, CPC starts using remote computing power. Through OCCUPY messages.
+-----+
| CCM |
+-----+
(7) OCCUPY req
+-----+ -------------------------- > +-----+
| CPC | | CPP |
+-----+ < ------------------------- +-----+
(8) OCCUPY resp
Figure 3: Computing Power Occupy
(7)OCCUPY Request message includes:
*consumer’s computing node id
*provider’s computing node id
*consumer’s serial number
*provider’s serial number
*calculation parameters
(8)OCCUPY Response message includes:
*consumer’s computing node id
*provider’s computing node id
*consumer’s serial number
*provider’s serial number
*calculation results
Once CPC finishes a complete calculation,CPC should release computing power via CCM,and CCM should refund the computing power to CPP.
(9)RELEASE (11)REFUND
req +-----+ req
+ --------------- > | CCM | ----------------- +
| + -------------- +-----+ < ------------ + |
| |(10)RELEASE (12)REFUND | |
| | resp resp | |
| | | |
| | | |
| | | |
| V | V
+-----+ +-----+
| CPC | | CPP |
+-----+ +-----+
Figure 4: Computing Power Release/Refund
(9)RELEASE Request message includes:
*consumer’s computing node id
*provider’s computing node id
*consumer’s serial number
*provider’s serial number
(10)RELEASE Response message includes:
*consumer’s computing node id
*provider’s computing node id
*consumer’s serial number
*provider’s serial number
(11)REFUND Request message includes:
*consumer’s computing node id
*provider’s computing node id
*consumer’s serial number
*provider’s serial number
(12)REFUND Response message includes:
*consumer’s computing node id
*provider’s computing node id
*consumer’s serial number
*provider’s serial number
TBD.
TBD.
| [I-D.liu-coinrg-requirement] | Liu, P. and L. Geng, "Requirement of Computing in network", Internet-Draft draft-liu-coinrg-requirement-02, March 2020. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |