idnits 2.17.1 draft-li-coin-oam-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 12, 2020) is 1384 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.liu-coinrg-requirement' is defined on line 330, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-liu-coinrg-requirement-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Computing in Networking Research Group Z. Li 3 Internet-Draft Y. Mu 4 Intended status: Informational C. Zhou 5 Expires: January 13, 2021 China Mobile 6 July 12, 2020 8 COIN Operation, Administration and Maintenance Framework 9 draft-li-coin-oam-framework-00 11 Abstract 13 This document provides reference framework for Operations, 14 Administration and Maintenance (OAM) for Computing in the Network 15 (COIN). 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 13, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Aspects Monitored by COIN OAM? . . . . . . . . . . . . . . . 2 59 2.1. Computing Power Consumer . . . . . . . . . . . . . . . . 2 60 2.2. Computing Contract Management . . . . . . . . . . . . . . 3 61 2.3. Computing Power Provider . . . . . . . . . . . . . . . . 3 62 3. Consultation Mechanism of COIN . . . . . . . . . . . . . . . 3 63 3.1. Register . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.2. Discover/Allocate . . . . . . . . . . . . . . . . . . . . 4 65 3.3. Occupy . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.4. Release/Refund . . . . . . . . . . . . . . . . . . . . . 6 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 6. Normative References . . . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 This document aims to provide a reference framework for Operations, 75 Administration and Maintenance (OAM) for Computing in the Network 76 (COIN). The framework describes a tripartite consultation mechanism 77 which includes consumers/providers registration, resource discovery/ 78 allocation, resource occupation, and resource release/refund. 80 2. Aspects Monitored by COIN OAM? 82 In this framework, the device and platform will be regarded as a 83 consumer or a provider of a computing power. One and the only 84 manager will be responsible for the management of computing power and 85 the contracts between consumers and providers. 87 2.1. Computing Power Consumer 89 Computing Power Consumer (or CPC, for short) is an application that 90 needs computing power from the network. As a consumer, the 91 application instance must register to CCM and be assigned a node id, 92 which is a unique identifier in a COIN system. 94 2.2. Computing Contract Management 96 Computing Contract Manager (or CCM, for short) is an application that 97 is responsible for register administration of all the CPCs, CPPs and 98 the Algorithm Repository. It can connect the consumers of computing 99 power and the providers of computing power. It also signs the 100 contracts for both sides. 102 2.3. Computing Power Provider 104 Computing Power Provider (or CPP, for short) is an application that 105 verifies the system having sufficient computing power available for 106 external applications. As a provider, the application instance must 107 register to CCM and be assigned a node id, which is a unique 108 identifier in a COIN system. 110 3. Consultation Mechanism of COIN 112 3.1. Register 114 CPC and CPP must register to CCM to confirm its role in the COIN 115 system. An application instance can be a CPC and a CPP concurrently. 116 In REGISTER Request message, the role field is a mandatory field. 117 The CCM must assign a unique node id for the application instance and 118 put it in the REGISTER Response message. The CCM has all the records 119 of the CPC and CPP. 121 (1)REGISTER (1)REGISTER 122 req +-----+ req 123 + --------------- > | CCM | < --------------- + 124 | + -------------- +-----+ -------------- + | 125 | |(2)REGISTER (2)REGISTER | | 126 | | resp resp | | 127 | | | | 128 | | | | 129 | | | | 130 | V V | 131 +-----+ +-----+ 132 | CPC | | CPP | 133 +-----+ +-----+ 135 Figure 1: Computing Power Register 137 (1)REGISTER Request message includes: 139 *Role type, identifying the role of the computing power contract. It 140 may be consumer or provider 141 (2)REGISTER Response message includes: 143 *Role type, identifying the role of the computing power contract. It 144 may be consumer or provider 146 *computing node id, unique node id assigned by CCM. 148 3.2. Discover/Allocate 150 When a CPC meets distributed computing task,it seeks for computing 151 power from CCM by DISCOVER Request message,along with the computing 152 power requirements and corresponding algorithm requirements. Now 153 that CCM has all the records of CPPs,it can choose one or more 154 appropriate CPPs and send ALLOCATE Request message to them. The 155 message at the same time contains the computing power requirements 156 and corresponding algorithm requirements. 158 After the CPP has prepared for the necessary computing power and 159 algorithm function, it sends ALLOCATE Response message to CCM with 160 its provider node id and a serial number.After the CCM send DISCOVER 161 Response message to CPC, the contract between a CPC and a CPP has 162 been signed through CCM. 164 (3)DISCOVER (4)ALLOCATE 165 req +-----+ req 166 + --------------- > | CCM | ----------------- + 167 | + -------------- +-----+ < ------------ + | 168 | |(6)DISCOVER (5)ALLOCATE | | 169 | | resp resp | | 170 | | | | 171 | | | | 172 | | | | 173 | V | V 174 +-----+ +-----+ 175 | CPC | | CPP | 176 +-----+ +-----+ 178 Figure 2: Computing Power Discover/Allocate 180 (3)DISCOVER Request message includes: 182 *consumer's computing node id 184 *computing power requirements 186 *algorithm requirements 188 *consumer's serial number 189 (4)ALLOCATE Request message includes: 191 *consumer's computing node id 193 *computing power requirements 195 *algorithm requirements 197 *consumer's serial number 199 (5)ALLOCATE Response message includes: 201 *consumer's computing node id 203 *provider's computing node id 205 *consumer's serial number 207 *provider's serial number 209 (6)DISCOVER Response message includes: 211 *consumer's computing node id 213 *provider's computing node id 215 *consumer's serial number 217 *provider's serial number 219 3.3. Occupy 221 After the contract is signed by both sides, CPC starts using remote 222 computing power. Through OCCUPY messages. 224 +-----+ 225 | CCM | 226 +-----+ 228 (7) OCCUPY req 229 +-----+ -------------------------- > +-----+ 230 | CPC | | CPP | 231 +-----+ < ------------------------- +-----+ 232 (8) OCCUPY resp 234 Figure 3: Computing Power Occupy 236 (7)OCCUPY Request message includes: 238 *consumer's computing node id 240 *provider's computing node id 242 *consumer's serial number 244 *provider's serial number 246 *calculation parameters 248 (8)OCCUPY Response message includes: 250 *consumer's computing node id 252 *provider's computing node id 254 *consumer's serial number 256 *provider's serial number 258 *calculation results 260 3.4. Release/Refund 262 Once CPC finishes a complete calculation,CPC should release computing 263 power via CCM,and CCM should refund the computing power to CPP. 265 (9)RELEASE (11)REFUND 266 req +-----+ req 267 + --------------- > | CCM | ----------------- + 268 | + -------------- +-----+ < ------------ + | 269 | |(10)RELEASE (12)REFUND | | 270 | | resp resp | | 271 | | | | 272 | | | | 273 | | | | 274 | V | V 275 +-----+ +-----+ 276 | CPC | | CPP | 277 +-----+ +-----+ 279 Figure 4: Computing Power Release/Refund 281 (9)RELEASE Request message includes: 283 *consumer's computing node id 284 *provider's computing node id 286 *consumer's serial number 288 *provider's serial number 290 (10)RELEASE Response message includes: 292 *consumer's computing node id 294 *provider's computing node id 296 *consumer's serial number 298 *provider's serial number 300 (11)REFUND Request message includes: 302 *consumer's computing node id 304 *provider's computing node id 306 *consumer's serial number 308 *provider's serial number 310 (12)REFUND Response message includes: 312 *consumer's computing node id 314 *provider's computing node id 316 *consumer's serial number 318 *provider's serial number 320 4. Security Considerations 322 TBD. 324 5. IANA Considerations 326 TBD. 328 6. Normative References 330 [I-D.liu-coinrg-requirement] 331 Liu, P. and L. Geng, "Requirement of Computing in 332 network", draft-liu-coinrg-requirement-02 (work in 333 progress), March 2020. 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, 337 DOI 10.17487/RFC2119, March 1997, 338 . 340 Authors' Addresses 342 Zhiqiang Li 343 China Mobile 344 Beijing 100053 345 China 347 Email: lizhiqiangyjy@chinamobile.com 349 Yan Mu 350 China Mobile 351 Beijing 100053 352 China 354 Email: muyan@chinamobile.com 356 Cheng Zhou 357 China Mobile 358 Beijing 100053 359 China 361 Email: zhouchengyjy@chinamobile.com